Posts by riawie

    sollte das helfen, und sich das Phänomen nur bei im extra Fenster geöffneten Nachrichten zeigen, nicht aber in der Vorschau im Hauptprogramm lässt es sich für empfangene Mails in den Einstellungen unter Editor > Optionen > "Nachricht im Bearbeiten-Modus öffnen" beeinflussen.
    Sobald die Option nicht mehr aktiv ist kann auch wieder direkt geklickt werden.

    hihi, das ist der Grund warum ich "und" und "oder" inzwischen nicht mehr gemeinsam in einer Regel einsetze. entweder "und", oder "oder"

    a) hab ich keine Lust das jedes mal vorher zu testen
    b) weiß ich nie wann wer anderes eine Regel verändern wird.

    Und um zum Fall oben zurückzukommen.
    Es ist halt recht wahrscheinlich das solche Regeln später noch mal angefasst und erweitert werden, weil eben neuer SPAM auftaucht, der sich mit dieser Regel nicht fassen lässt und dann kommen da oft Wünsche auf eine zusätzliche Bedingung mit einem oder aufzunehmen und ab da geht es schief, weil da noch ein und drin steht.
    Daher bevorzuge ich in solchen Fällen den Weg das lieber sauber getrennt zu halten und bei der Gelegenheit dann solche Systemmeldungen, die bei eintreffen auch bearbeitet gehören gleich in einen extra Ordner zu verfrachten, wo der neue Nachrichten Zähler (Ordner überwachen lassen) dann auch ein schöner Indikator ist das da neben den normalen Mails noch Arbeit wartet ;)

    Kleine Anmerkung noch dazu:

    Alle 3 hier beschriebenen Wege - auch der von mir beschriebene - haben ein gemeinsames Problem:

    Wenn es aufgrund der längeren Verwendung des ehemaligen Benutzerarchivs als Gruppenordner Verknüpfungen von anderen Stellen zu Inhalten des betreffenden Archivs geben sollte, dann gehen die bei jeder der drei Vorgehensweisen mehr oder weniger stark kaputt.

    Nach meiner Kenntnis wird nur bei dem von mir beschriebenen Weg zumindest der Fall von einzelnen Nachrichten die in anderen Ordnern Dubletten haben, welche sich gemeinsame Datendateien aus diesem Archiv Baum teilen, berücksichtigt und durch den Servicelayer automatisiert bereinigt.

    Was in keinem Fall behoben wird sind Verknüpfungen einzelner Nutzer welche auf Archivordner in diesem Archiv zeigen, oder Verknüpfungen welche direkt auf einzelne Mails oder andere Dokumente in diesen vielen Archiv Ordnern zeigen.

    Auch wenn es irgendwo Regeln gibt welche Mails automatisch in dieses Archiv oder in eines seiner Unterarchive verteilen werden diese Regeln nach jeder der 3 Varianten zur Umbenennung oder Verschiebung brechen.

    In so einem speziellen Fall kann es daher fast sinnvoller sein das Archiv einfach weiter dort liegen zu lassen, den Nutzer mit dieser eMail Adresse neu einzurichten und ihm den alten Archivbaum, bzw. die relevanten Teile davon schlicht als Verknüpfung in sein neues Profil zu verknüpfen und die alte Struktur auch weiterhin als Ablage zu nutzen, ganz gleich ob man die Rechte zum Zugriff auf diesen Archivbaum nun anschließend auf den neuen Nutzer beschränkt, oder auch nicht.

    Ein Nutzermail Archiv mal als Gruppenarchiv hergenommen zu haben ist halt leider schon ein sehr spezieller Fall, wo man bei Beantwortung der Frage wie man das User-ID Problem löst dann auch nicht zwingend direkt an jedes dabei mögliche Problem denkt was im Laufe der Aktion auftreten kann.

    Sollte sich tatsächlich für die Umbenennung entschieden worden sein muss im Anschluss daran auf jeden Fall das Protokoll der nächtlichen Bereinigung - so nicht eh bereits aktiv - aktiviert und vor allem alle darin auftauchenden Fehler beseitigt werden.

    Das Beheben aller Fehler die dann bei den nächtlichen Bereinigungen auftreten kann in Abhängigkeit davon wie viele Nutzer sich in der Vergangenheit Verknüpfungen zu Ordnern oder Dokumenten aus dem Archivbaum angelegt haben leider bisweilen sehr aufwändig werden.
    Es sollte aber in jedem Fall direkt und sehr gründlich erledigt werden um sich späteren noch schwieriger zu beseitigenden Ärger zu ersparen.

    Ich sehe da keinen Weg die alte David Server User ID zu reaktivieren, welche aber Bedingung für die erneute in Besitzname der Benutzer Archiv Struktur ist. Denn der David Server vergibt die Benutzer ID halt aufsteigend.

    Allerdings sollte ein gangbarer Weg sein den Nutzer neu anzulegen und dann als Nutzer mit Administrativen Rechten auf dem David Server über den David Client alle Unterarchive außer die von System angelegten Archive (die müssen auf Dateisystemebene zwingend ihre Namen behalten) in die neue Archiv Struktur des neu angelegten Nutzers hinein zu verschieben.
    Damit bleiben dann nur noch die Nachrichten welche direkt im Ein und Ausgang das alten Nutzers liegen, welche beim manuellen Verschieben einige Zustandsinformationen - die man vielleicht erhalten möchte - verlieren würden. Da kann man zu einem kleinen Trick greifen und einfach im jeweiligen Ordner (Eingang/Ausgang) über Eigenschaften > Dienste > automatische Ablage aktivieren > erweitert das jeweilig passende Archiv des neu angelegten Nutzers eintragen, Einträge verschieben nach 1 Tagen auswählen, alle anderen Optionen auf der Seite abwählen, eine Nacht warten und zack sind alle Mails mit ihren Zustandsinformationen im neuen Archiv gelandet.

    Damit hat man einen sauberen Umzug, das verbraucht keinen nennenswerten Mehrplatz auf dem System und erfordert keine lange Bastelei.

    Man könnte das zwar auch auf Verzeichnissebene machen, das würde dann aber Anpassungen der Archive.Dir Dateien erfordern und wäre wirklich sehr viel Arbeit, die ich nicht auf mich nehmen wollen würde.

    Den oben von mir beschriebenen Weg hingegen habe ich bereits mehrfach erfolgreich durchgeführt.

    ja, die Lösung kann so einfach sein, so lange man nur "und" Verknüpfungen von Bedingungen hat.

    Ich habe das aber nicht so einfach vorgeschlagen, weil ich nicht sicher sein konnte das es wirklich bei nur einer weiteren Bedingung bleibt.
    Denn sollte da noch eine Erweiterung der Bedingungen um ein oder nötig werden würde das halt schlicht nicht mehr funktionieren.
    Daher baue ich lieber alle Filter immer so, das sie immer auch dann noch funktionieren wenn ich sie später mal erweitere, mich aber nicht mehr an alle Details und Randbedingungen ihrer ursprünglichen Entstehung erinnern kann ;)
    Leider kann man im David Server ja sowas nicht mit Kommentaren versehen...
    Und dann sind hier bei mir die meisten solcher SPAM Behandlungsregeln auch noch mit eine oder versehen und spätestens dann kann man sowas nicht mehr in einem Schritt zusammenführen.

    Wie nordtech schon schrieb brauchst Du zu dem Zweck mehrere Regeln. Diese können durchaus alle in einem Archiv liegen, da immer alle zu einer Mail passenden Regeln beachtet und abgearbeitet werden. Zumindest wenn Du bislang die Nachrichten nur in den Papierkorb verschiebst und nicht etwa dauerhaft löscht klappt das so auch.
    Alternativ zu zwei Regeln im gleichen Eingang könnte man auch eine weitere Regel im Papierkorb erstellen, welche die dort per Regel hin verschobenen Nachrichten noch mal auf die doch erwünschten Nachrichten prüft und diese dann in einem eigenen Ordner für diese Nachrichten verschiebt.
    Zu beachten ist dabei das die Anwendung einer Regel immer eine automatische Aktion darstellt, das bedeutet, einerseits das man eben im Zielordner der ersten Verschiebung durch eine Regel weitere Regeln abarbeiten lassen kann, aber es bedeutet auch das man die Nachricht dabei auf keinen Fall in den Ursprungsordner der ersten Regel zurück verschieben darf, da die Nachricht ansonsten quasi Karussell fahren würde. Daher ist der extra anzulegende Zielordner für die doch erwünschten Nachrichten Pflicht.

    die Menge der Mails an sich ist kein Problem für den David Server.

    Problematischer ist eher:

    Ich vermute: wenn man die feste öffentliche IP des David Servers leicht ändern kann, dann könnte man im Blacklistfall ggf. gut intervenieren.

    Mit derart leicht änderbarer IP Adresse wirst Du nicht unbedingt bei allen Empfängern gern gesehen sein.
    Wenn es Dir aber gelingt ausreichende Reputation für die IP-Adresse des David Servers aufzubauen, steht Deinem Vorhaben technisch auf Seiten des David Servers nichts im Wege.
    Zum Vertrauen welches die IP-Adresse braucht gehört allerdings bei sehr vielen empfangenden Mail Servern das die IP-Adresse nicht aus einem Dialup Pool stammt.

    Das erste Ziel muss auch sein ein blacklisting von vornherein zu vermeiden und nicht dann bei Bedarf drauf zu reagieren.

    Ich hatte vereits versucht, die TLD.exe manuell zu starten, konnte aber den Parameter für den Monitor-Modus nicht finden. Kannst Du mir da weiterhelfen?

    Da muss ich echt selbst erst mal wieder graben...

    Das hier sollte helfen:

    Quote

    Wird der Port auf dem Remote Server mit folgender Syntax gestartet :

    • Beispiel:

      Code
      D:\DAVID\TLD\CODE\CAPI\TLD.EXE 001 PATH=\\DAVID-SERVER\DAVID -CONSOLE

    öffnet sich bei einem korrekten Start ein DOS-Fenster (Wirkung des Parameter-CONSOLE), in dem der Port läuft.

    Quelle:


    Tobit.Software

    Ja, den RemoteTLD hatte ich gestoppt, wenn ich das richtig verstehe greift das RemoteTLD ja über den Serverpfad auf die TLD.INI des David-Serves zu.

    Meiner Erinnerung nach ist das nicht zutreffend.
    Für den Betrieb eines remote TLD gilt ja unter anderem folgende Voraussetzung:

    Quote

    Kopieren Sie vom David Host Server aus dem Verzeichnis »DAVID\TLD\CODE« alle Unterverzeichnisse und Dateien in die entsprechenden Verzeichnisse des Remote Servers.

    Welche halt nur Sinn ergibt wenn die Konfigurationsdaten lokal liegen.
    Ich weiß noch genau das ich auf dem David Server damals ein Script hatte welches bei jeder Konfigurationsänderung an einem remote tld den remote tld gestoppt, das tld Verzeichnis auf den remote Server kopiert und den remote tld wieder gestartet hat.

    Das Server Verzeichnis wird meiner Kenntnis nach nur zum ablegen der eingehenden und zum lesen der zu sendenden FAX und sonstigen Daten verwendet, nicht aber bezüglich der Konfiguration.

    In der VM kann ich bei dem TLD eingeben was ich will, es wird nicht übernommen.

    Wenn Du an einem ausgelagerten TLD Änderungen direkt im David Administrator auf dem David Server vornimmst werden die nur wirksam wenn Du den ausgelagerten TLD stoppst und die geänderten Dateien des TLD erneut auf den Server wo die TLDs ausgelagert sind kopierst.

    Alternativ kannst Du die TLDs auch auf dem Server wohin sie ausgelagert wurden im Monitor Modus starten und dann dort die gewünschten Änderungen vornehmen bzw. nachvollziehen, dann werden sie direkt wirksam.

    Zum Rest Deines Setups kann ich jetzt direkt nichts sagen.

    Also bitte einfach mal alle Argumente außen vorlassen und als Partner bei Tobit anrufen und die Sachlage klären, was nun ist.

    Nun, ich bin da eh nicht angesprochen, weil kein Partner, sondern nur Kunde.
    Dennoch.
    Wenn was von der Tragweite geklärt werden soll, dann sollte das schriftlich und nicht per Telefon erfolgen.
    Und angesichts des inkonsistenten Kommunikationsverhaltens von Tobit würde ich in dem Fall dringend dazu raten Papier zu nutzen und das ganze direkt an die richtigen Adressen zu schicken.

    Wenn Du da anrufst bekommst Du ständig wechselnde Aussagen von Leuten deren Position im wesentlichen davon bestimmt wird ob man sie fürs telefonieren abstellen mag oder sie nicht eher wichtigeres zu tun haben.

    Aber hey, ist nur ein gut gemeinter Rat ;)

    Überschreiben nach 1 Tag

    Das erscheint mir etwas merkwürdig, wenn Du doch Vollbackups nur 1 mal die Woche machst und 2 Images aufhebst, da sehe ich dann eher überschreiben nach 7 Tagen (gerechnet ab letztem inkrementellem Backup im jeweiligen Set)

    Grundsätzlich bringt einem Deduplikation bei StrongBoxen halt die nötige Luft um Backups länger aufbewahren zu können.

    Ich würde in so einem Setup wohl nicht jede Woche ein neues Image anfangen, sondern nur 1 mal im Monat und davon 2 aufheben.

    Die Rechnung ist dabei simpel.
    Den größten Teil der Datenmenge eines StrongBox Images erzeugt das initiale Vollbackup am Anfang.
    Die inkrementellen Backups erzeugen nur noch wenig Zuwachs, die Deduplikation auf Dateisystemebene sorgt dafür das dieser Zuwachs tatsächlich nur aus neu hinzugekommenen oder veränderten Daten besteht und einfach nur innerhalb der Archive verschobene Daten sich kaum noch im Speicherbedarf der StrongBox Images auswirken.

    Denn das ist leider ein riesen Problem bei der StrongBox Sicherung des Tobit David Servers.
    Jede einfach nur innerhalb der Archivstruktur verschobene Mail mitsamt ihren Anhängen wird beim darauf folgenden inkrementellen Backup gesichert als ob sie neu im System wäre und das verursacht die oft unerklärlich großen täglichen Zuwächse der StrongBox Images.
    Würde Tobit das besser organisieren, die StrongBox Images intern deduplizieren und in solchen Fällen nur die veränderten Metadaten ins StrongBox Image schreiben wäre der ganze Thread hier gar nicht entstanden ;)

    Also, seltener Vollsicherungen, Deduplizierung, täglich inkrementelle Backups und dem Server täglich ausreichend Zeit zur Deduplizierung geben.

    Bei uns ist das Zeitfenster für die Deduplikation mit höchster Priorität so gelegt, das es Nachts immer etwa dann beginnt wenn die StrongBox Sicherung gerade fertig ist. Zusätzlich darf spät Nachmittags, wenn die meisten schon im Feierabend sind noch mal mit höchster Priorität dedupliziert werden, ansonsten darf der Server das rund um die Uhr it niedrigster Priorität tun.

    0-0.stbox 465GB - Datenauslastung auf dem Laufwerk "nur" 200GB

    Das ist doch auch schon mal ein schönes Ergebnis. Da kann man doch was mit dem dadurch gewonnenen Platz anfangen und Sicherungen länger aufbewahren :)

    Ja daher ja meine Frage ob die Sicherungen oder eben David Ordner dedupliziert wurde

    Die David Archivstruktur ist bei uns ebenfalls dedupliziert.
    Um die ging es hier im Thema aber ja aktuell nicht ;)
    Doch rein zur Befriedigung der Neugier ;) haben wir da stabil eine Deduplizierungsrate von 65%
    Ob man allerdings die Archivstruktur dedupliziert oder nicht ändert halt nichts daran wie groß Strongbox Images werden.

    Hab aber nun von deinen Aussagen verstanden, dass deduplizieren bie NAS nicht geht

    Das hab ich so nicht geschrieben, sondern das Deduplizierung beim NAS halt davon abhängt was das NAS kann.
    Manche NAS Systeme können deduplizieren, andere können es halt nicht.
    Wenn man mag kann man da aber halt gucken ob das NAS auch iSCSI kann und dann die Deduplikationsfunktionen des Windows Servers verwenden. Bei eher kleinen Datenvolumen kann das schon noch sinnvoll nutzbar sein.

    Hast du dafür einen eigenen Server für Software Backups etc. ?

    Ja, für Backups gibt es hier mehrere Server die sich ausschließlich um dieses Thema kümmern.
    Ist halt schon ein anderer Scale hier, wir produzieren halt täglich mindestens 2 stellig GB neue Daten, die langfristig gespeichert, gesichert und auch archiviert werden müssen.

    Am Ende muss halt jeder gucken was für ihn passt.

    Deduplizierung auf dem Windows Server kann aber halt auch denen helfen welche mit kleineren Setups fahren.
    Ich würde allerdings davon absehen Deduplizierung so zu verwenden das bei einem irgendwann eventuell mal nötigen Restore nicht ausreichend Speicher für eine nicht deduplizierte Wiederherstellung zur Verfügung steht.
    Ich nutze Deduplikation im David Archiv System daher vor allem um die SSDs zu schonen, die leben nämlich länger wenn große Bereiche unbenutzt bleiben und belegte Bereiche sich möglichst selten verändern. Entsprechen kann unser Server das komplette Volumen halt auch ohne Deduplikation halten und hat noch Raum für Wachstum. Die SSDs werden halt getauscht wenn sie zu klein werden und wandern dann in andere Server wo sie grad besser passen. Hier wird jedes Laufwerk aufgebraucht, aber keines erreicht das ende seiner Lebensdauer in dem Server für den es ursprünglich mal angeschafft wurde. Die meisten sterben nach Jahren dann ihren Tod in einem Client System, wo das nicht weh tut, sind bis dahin aber halt mehrfach durchgereicht worden. Dafür sind hier seit Jahren bis auf die langsamen Langzeit Backup Server alle Speichermedien nur noch SSDs, auch in den Clients.

    So, genug Off Topic, zurück zum Fragesteller ;)

    lycra wir reden gerade nicht von einem NAS, sondern von deduplizierten Volumes auf einem Windows Server.

    Dedupliziert wird hier also das gesamte Volume, bzw. eben letztlich die darin gespeicherten Dateien, was in diesem Fall relevanter Weise die StrongBox Images sind.

    Wenn du auf Deinem NAS deduplizieren möchtest, dann musst Du Dich mit den Fähigkeiten Deines NAS das zu tun beschäftigen.

    Alternativ lässt Du Dein NAS Blockstorage bereitstellen und bindest diesen auf dem Windows Server beispielsweise via iSCSI oder Fiberchannel ein. Dann kannst Du auch dort die Deduplizierung im Windows Server mit dessen Bordmitteln steuern.

    Meine Strongboxen fressen hier Terrabytes und das erstellen eines Basisimage von aktuell halt 3,7 TB dauert trotz SSDs ein Wochenende, entsprechend werden die hier nicht alle Nase lang neu erzeugt, sondern länger für inkrementelle Backups genutzt.

    Für die Fragen von Ammermueller tut das allerdings grad wenig zur Sache, da ich bewusst nur die Deduplizierungsrate eines erst 20 Tage alten Images beschrieben habe.

    Gute Deduplizierungsraten erzielt man bei Strongboxen übrigens auch mit den oben von mir genannten Einstellungen nur dann wenn diese Einstellungen vor dem erstellen eines Images vorgenommen werden.
    Also Volume erstellen, Deduplizierung konfigurieren, dafür sorgen das auch ein Zeitplan zur Deduplikation mit ausreichend Zeit definiert ist. Erst dann das Volume zum erstellen eines neuen StrongBox Images verwenden und zuschauen wie dieses nach 24 Stunden langsam weniger Platz frisst als es das beim erstellen noch getan hat. so nach 3 Tagen sieht man dann deutliche Effekte. besonders deutlich werden die Effekte dann wenn Ereignisse eintreten welche in dem Fall welcher hier den Thread auslöste plötzlich zu deutlich größeren inkrementellen Backups führen als das rein durch die an dem Tag eingegangenen oder selbst versandten Mails zu erklären wäre, z.B. weil ein Nutzer große Mengen an Daten von einem Archiv in ein anderes verschoben, oder kopiert hat. In solchen Fällen glänzt die Deduplizierung dann halt richtig.

    Da ich einen David Server mit großer Datenbasis betreibe werden halt auch bei der nächtlichen automatischen Ablage gerne schon mal eine zweistellige Zahl an GB Daten in Ablagearchive verschoben und zack wächst auch meine StrongBox schnell mal um zweistellig GB an Daten.
    Das kann ohne Deduplikation schnell sehr viel physischen Platz auf den SSDs belegen, reduziert sich aber halt mittels Deduplikation schon drastisch.

    Auch bei der Datensicherung außerhalb des Servers macht sich das dann positiv bemerkbar, da Image basiert gesichert wird und diese Images dann halt entsprechend kleiner sind, als das Filebasiert oder eben ohne Deduplikation der Fall wäre.

    Noch mal, das einzige was Tobit bislang schriftlich kommuniziert hat ist das Neusysteme, Neueinstiege in SiteCare über Updates, sowie neue zusätzliche Lizenzen keine Dauerlizenzen mehr sein werden.

    Wer eine laufende Sitecare hat und Sitecare kündigt hat laut allem was Tobit bislang geschrieben hat weiterhin Dauerlizenzen.

    Das halte ich aktuell auch für klar einklagbar wenn es sich technisch anders verhalten sollte.

    Ob das sinnvoll ist oder nicht, steht auf einem anderen Blatt.

    Die Frage ist nur: Was zum Geier willst Du damit?

    Ein David Server ohne Sitecare ist halt geschäftlich nicht verantwortbar zu betreiben.

    Die einzige Situation in der ich mir so ein System vorstellen kann hatte ich auch bereits beschrieben, nämlich vom Netz entkoppelt zu Archivzwecken um Aufbewahrungsfristen und während dessen auch Abrufbarkeit und Transferierbarkeit der aufbewahrten Daten zu gewährleisten. Für was anderes ist so ein nicht gewartetes System nicht verantwortlich zu betreiben.

    Was also will man real damit und warum will man da real jetzt ein Fass konstruieren?

    Und ja, natürlich kommen sie deswegen mit dieser Änderung durch, eben weil sie damit faktisch nichts weiter herbeiführen, als einen Zustand den man eh herbeiführen sollte. Solche Systeme sollten - Prinzipien hin oder her - eh nicht ohne Softwarepflege betreiben dürfen.

    Closed Source Systeme kannste halt nicht ohne Herstellersupport updaten und Hersteller wollen für solche Updates halt gern regelmäßig Geld sehen.

    Wer das nicht will muss zu freier Software greifen und sich dort auf jene beschränken welche regelmäßig gepflegt werden, was dann letztlich auf die begrenzt ist, welche ausreichend viele oder große Sponsoren gefunden haben.

    Also, im Prinzip steht Dir Deine Dauerlizenz zu und laut allem was ich von Tobit an schriftlichen Äußerungen finden kann und konnte bzw. mir geschickt wurde hast Du die auch weiterhin.

    Verzeih mir bitte da sich auf telefonisch oder sonst mündlich getätigte Äußerungen schlicht nichts gebe.
    Und so lang Tobit uns als Kunden nichts anderes schreibt und sich unser Einverständnis dazu wirksam erklären lässt hat sich auch nichts relevantes geändert.

    PS: Ich hab zwischenzeitlich mal mit unserm Hausjuristen gesprochen. Rein prinzipiell ist es durchaus möglich im Rahmen eines bestehenden Software Wartungsvertrags auch die Lizenzbedingungen für künftige Updates zu ändern. Damit das aber rechtlich klar geht muss das dann deutlich kommuniziert und mit einem Sonderkündigungsrecht einhergehen. Nichts davon ist bislang passiert. Es gab also keine Änderung der Bedingungen für uns als Bestandskunden.

    Wieso wenn man migriert reicht das neue System nicht für die Aufbewahrungspflichten aus?!

    kommt halt drauf an ob man sich das antun will in so einem Fall auch alle Altlasten mit zu migrieren, welche man zu dem Zeitpunkt eh schon nur noch der Aufbewahrungsfristen wegen im System hat.
    Klar kannste alles mit ziehen, aber wer räumt dann später auf?
    Wir halten es immer mal wieder so, das in bestimmten Situationen nur das migriert wird von dem von vornherein klar ist das es vermisst würde.
    Alles andere wird nur und erst auf Anforderung migriert und was nach 10 Jahren nicht angefordert wurde kann dann auch einfach mal weg.
    Im jeweils neuen lebenden System sammelt sich auch so ganz sicher wieder viel Zeug an ;)
    Die Strategie erfordert aber halt das man auch für mindestens die 10 Jahre noch nachträglich Daten raus migrieren kann, was bei Mail Systemen, welche sich an Standards halten - was bei David halt trotz aller böser Zungen noch immer der Fall ist - ja normal kein Problem darstellt.