ikar ich denke zwar das dies keine Auswirkungen haben sollte, weil die Datendateien vom SQL Server eigentlich so oder so nie die nötigen Kriterien für eine Deduplizierung aufweisen, dennoch würde ich empfehlen deren Pfad noch aus der Deduplizierung auszuschließen.
Der Pfad sollte bei einer Standardinstallation stets wie folgt lauten:
\programme\david\code\database
Beiträge von riawie
-
-
Als erstes würde ich mal das Windows Ereignisprotokoll nach Meldungen zum SQL Server durchsehen.
Anschließend würde ich dann wohl den SQL Server neu starten.
Je nach dem was sich im Ereignisprotokoll findet auch den ganzen (virtuellen) Server auf dem der David läuft. -
baer derart viel Plattenplatz hätte ich in einem 21 Jahre alten Novell Server allerdings nicht vermutet.
ikar man sollte zwar den folgenden Pfad aus der Deduplikation ausnehmen:
\Programme\david\code\database
(eventuell ist dabei der Teil vor \david\ an die eigene Installation anzupassen)
Aber wenn man es nicht tut sollte das allenfalls etwas mehr Rechenlast zur Folge haben, jedoch keinen Ausfall der chat Funktion.
Ich würde das für eine zufällige zeitliche Koinzidenz halten -
Es startet zu den von Dir eingestellten Zeiten, berücksichtigt dabei aber bei der Einstellung des Mindestalters der Dateien nur solche die mindestens 3 Tage alt sind. Da auf einem David Server allerdings zu jeder Zeit - außer er wäre gerade frisch installiert oder frisch umgezogen - ausreichend Dateien liegen sollten die bereits 3 Tage oder älter sind sollte da folglich auch gleich nach dem er das erste mal gelaufen ist ein Effekt zu sehen sein.
Die einzige Konstellation in der ich mir vorstellen könnte das man da bei einem gewählten Mindestalter (fast) keinen bzw. nur einen sehr kleinen Effekt sieht wäre das man konsequent in allen Ein uns Ausgangsarchiven die Automatische Ablage schon nach weniger als 3 Tagen aktiv hat und ebenso konsequent alle Ablagearchive auf zusammenfassen eingestellt hat, denn dann gibt es ja quasi nichts was die Deduplikation noch als Duplikate erkennen könnte.
Ich habe mich bislang aber nie damit beschäftigen müssen das die Deduplikation nicht sofort Wirkung zeigt und kann daher nicht aus dem Stehgreif mit Rat dienen wie man prüfen kann was da warum gerade nicht wie gewünscht passiert.
Aber schau doch mal in die Windows Ereignisanzeige und dort unter:
Anwendungs und Dienstprotokolle > Microsoft> Deduplikation
Ob dort irgendwas interessantes zu Tage gefördert wird. -
baer das dürfte allerdings vermutlich nicht unbedingt eine besonders große Installation mit besonders vielen Nutzer, eMails und GBs an verbrauchtem Platz sein, oder?
-
Haha, ja, Zeitplan hatte ich wohl unterschlagen, sieht bei mir so aus:
Man sollte halt drauf achten die Durchsatzoptimierung nicht unbedingt zur gleichen Zeit laufen zu lassen zu der Datensicherung oder Bereinigung des David Servers läuft oder im Betrieb der Bär steppt.
Ach und falls du es oben übersehen haben solltest:ausgeschlossen wird nur der Ordner \programme\david\code\database
-
Sorry riawie es kam noch eine EDIT NAchfrage
Hast du nach dem Like wahrscheinlich nicht gesehen?! D:Allgemeiner Dateiserver ist richtig.
Ansonsten habe ich nur noch bei "Alter (in Tagen), ab dem Dateien dedupliziert werden sollen:" 3 eingetragen.
Mit kleineren Werten hat der Server mehr zu tun, es bringt aber bei uns keinen wesentlichen langfristigen Gewinn. deswegen die 3 Tage. -
ein sicheres Indiz ist wenn eine winmail.dat dran hängt
-
ikar da solltet Ihr dann ja auf jeden Fall mal eine Weile Luft für weiteres Wachstum haben
baer nvme braucht man sicher nicht für einen David Server, sie machen allerdings Sinn in einem Virtualisierungs Host auf dem mehr als nur der David Server betrieben wird. für einen David Server würde ich da allerdings - soweit überhaupt was anderes neben den nvme möglich ist - keine rotierenden Platten, sondern ein redundantes Pärchen SATA SSDs rein stecken.
Das wichtigste ist ja aber nun eh das ikar geholfen werden konnte und er nun wieder Luft hat ohne sich einen Schuss ins Knie einzufangen -
grundsätzlich wäre es sauberer das neue Bild auch mit einem neuen Namen im Textbaustein zu verankern. Schließlich gilt im geschäftlichen Verkehr das einmal versandte Dokumente (wozu auch eMails gehören) Ihr Aussehen nicht mehr verändern dürfen. Damit wäre dann auch das Cache Problem vom Tisch.
Ansonsten nutzt der David mittlerweile je nach Einstellung die Chromium Engine bzw. ist im Begriff auf die Chromium Engine des neuen Edge zu wechseln.
Wenn die chromium Engine verwendet wird sollte es im Im Grunde reichen bei vollständig beendetem David InfoCenter den Pfad:
%Appdata%\Tobit\chromium\#####-#####-########\Cachezu löschen bzw. zu leeren.
Bei anschließender Verwendung des David InfoCenter füllt sich dieser dann wieder. -
Uh, da fragste mich was...
Ich weiß das der David Client den Funktionsumfang je nach Einstellung einschränkt bzw. erweitert um mit dem vorhandenen Netz flüssig arbeiten zu können, aber was genau er in welcher Stufe abschaltet bzw. freigibt kann ich auch nicht mehr sagen :o -
Es könnte Sein das Euer Kunde Mails in seinem Exchange an externe Empfänger im Rich Text Format versendet, dann kommt es zu solchen Problemen.
In dem Fall sollten die mal ihr Nachrichtenformat für den externen Versand auf HTML umstellen, dann klappt das auch mit den Terminanfragen.
Das Problem entsteht so oder so auf der anderen Seite und lässt sich von Euch nicht beeinflussen... -
auf dem nas wird auch nichts dergleichen gemacht. wie kommst du drauf, dass sowas auf dem nas gemacht wird?
Weil nahezu jedes NAS was seinen Plattenplatz auch per iSCSI exportieren kann es anbietet die gewünschten GB/TB entweder thin oder thick zu provisionieren.
Das ist nichts besonderes und für low Performance Anwendungen ist thin provisioning dann auch völlig o.k. für das hier gebrauchte Szenario jedoch nicht, entsprechend hatte ich davor noch warnen wollen.
Das Du zur gleichen Zeit - während ich meinem Nachtrag schrieb bereits geantwortet hattest das Euer NAS kein iSCSI kann, hatte ich nicht gesehen, sonst hätte ich den Nachtrag nicht mehr abgeschickt.
NoHopeNoFear Ja, mit mklink kann man auch auf UNC Pfade linken.
Einem David auf diese Weise ein NAS unterzujubeln ist aber nicht nur ein Knieschuss mit Anlauf und Vorsatz. Das entspricht eher dem Strick am Firstbalken dessen Schlinge sich jemand umlegt bevor er aus dem Fenster im 10 Stock springt. Selbst Wenn das Seil lang genug ist endet das eindeutig... -
PS: mach da besser auf dem NAS kein Thin Provisioning Device von, sondern weise von vornherein ausreichend Speicherplatz für das Wachstum eines Jahres zu und erweitere das dann lieber jedes Jahr um einen ausreichend großen Happen, sonst fliegt Euch das wegen schlechter Performance mit an Sicherheit grenzender Wahrscheinlichkeit um die Ohren.
-
Wenn der keine großen Datenmengen auf seinem privaten Rechner liegen haben will/soll, aber eine halbwegs taugliche Internetanbindung hat, würde ich gar keine Synchronisation einrichten.
Einfach nur den David Client installieren, Zugangsdaten eingeben (Servername muss dann der von seinem Homeoffice aus erreichbare Servername sein, was entweder per VPN oder mit öffentlich erreichbarem Port 267 erfolgen kann) und ihn arbeiten lassen.
Bei uns hat Niemand von den über 50 mobilen Nutzern eine Synchronisation aktiv.
Synchronisation mit lokal gespiegelten Daten macht eigentlich nur dort Sinn wo es darum geht das Datenübertragungsvolumen bei echter mobiler Nutzung zu minimieren und statt dessen eben die Daten lokal auf dem Endgerät vorzuhalten. -
Die Archive auf ein Netzlaufwerk zu legen wird schiefgehen.
Der David Server geht davon aus das sie lokal liegen und wird die Archive auch beschädigen wenn da bei den Zugriffen Unterbrechungen auftreten.
Wenn Dein NAS iSCSI kann könntest Du vom NAS ein iSCSI Laufwerk für den David Server exportieren und dort dann als iSCSI einbinden. anschließend ließe sich dieses Laufwerk dann im Windows Server statt als Laufwerk als Verzeichniss im Pfad "c:\Programme\David\Archive" (Standardinstallation vorausgesetzt) einbinden. Für den David Server wäre das dann transparent.
Allerdings sollte man nicht vergessen das solch ein NAS dann tunlichst ordentlich Performance bieten und auch Netzwerktechnisch auf beiden Seiten gut angebunden sein sollte, sonst wird das bei den Datenmassen neben einer verlängerten Zeit für die Datensicherung auch lahme Zugriffszeiten für die Nutzer des Servers zur Folge haben.
Generell kann man bei so einem David Server übrigens ordentlich Plattenplatz sparen wenn man die Möglichkeiten des Windows Servers nutzt und für das Laufwerk auf dem die David Archive liegen NTFS Deduplizierung aktiviert.
Wir machen das mit der Einstellung "Alter in Tagen ab dem Dateien dedupliziert werden sollen: = 3" und sparen so aktuell auf unserem David Laufwerk 54% Speicherplatz ein, was eine Einsparung von aktuell 973 GB entspricht. -
Nun, wenn man bedenkt was viele Provider heutzutage noch immer als groß ansehen hab ich ohne Postlagernd viel zu häufig das Problem die Anwender dann zu Filetransfer Diensten zwingen zu müssen.
Das ist ersten Zeitraubend, nervt die Anwender und die nerven dann die Geschäftsleitung, welche wieder mich fruchtlos nervt, was dann ein Kreis ist in dem man sich noch viel mehr dreht.
Davon abgesehen trainiert man damit auch nur wieder jede Menge Anwender auf beiden Seiten der Kommunikation dazu Dinge zu tun die potentiell noch problematischer sind.
Wenn es nach mir geht hat ein UMS Server heutzutage auch Gigabyteweise Daten sicher und zuverlässig ans Ziel zu übermitteln und das eben nicht als Anhang, sondern vielleicht ein wenig Komfortabler und auf jeden Fall gern noch ein wenig sicherer als das mit dem Postlagernden Versand beim David aktuell der Fall ist, aber auf jeden Fall so das der Anwender nicht dazu gezwungen wird darüber nachzudenken wie er seine daten nun ans Ziel bekommt.
Aber das ist ein völlig anderes Thema.
Hier ging es um mobiles Arbeiten mit dem David am mobilen Desktop bzw. im Home-Office und was dafür nötig ist. -
Ich hab es wieder was da nicht funktioniert wenn die mobilen David.InfoCenter Clients keinen Zugriff auf Port 443 haben
Wir nutzen vielfach den postlagernden Versand bei Mails mit Scans an Externe Empfänger und wenn man dann noch mal nachschauen will was man da eigentlich versandt hat braucht es natürlich zwingend Zugriff auf Port 443 und die Webbox
Aber ja, Ihr habt natürlich recht, rein für den mobilen Einsatz des David.InfoCenter Clients reicht Port 267 aus. -
Das kommt drauf an was Ihr eingestellt habt.
Wenn Ihr da das gleiche Kennwort verwendet wie in der Domäne, dann ja, wenn Ihr für Remote Access ein anderes Kennwort eingetragen habt, dann nicht.
Wenn Ihr den gleichen Nutzernamen für den Remote Zugriff eintragt wie in der Windows Domäne, dann ja, sonst nicht.
Ich denke Du verwechselst das damit, das der David Server bei EAS oder IMAP Zugriff auch die eMail-Adresse statt des im Remote Access Feld angegebenen Benutzernamen akzeptiert.
Beim Kennwort wird stets das verlangt was man im Remote Access Feld im David für den jeweiligen Benutzer oder das jeweilige Archiv Eingetragen hat. -
Ich habe auch eine Mail erhalten, der Mail-Betreff stammt jedoch aus einer ca. 12 monate alten Emaildiskussion.
Waren an der Diskussion nur interne Nutzer auf Eurem Mailserver beteiligt?
In den Fällen welche ich bislang mitbekam war das Leck jeweils auf der anderen Seite und meist waren Outlook Nutzer auf der anderen Seite.
Mails die angeblich von unseren Nutzern kommen haben schon viele bekommen, aber nie über unsere Systeme, sondern stets über gehackte Konten oder offene Relays dritter.
Unsere autorisierten Mailserver würden solche Mails nicht annehmen und auch nicht weiterleiten.
Die Mail Adressen haben sich die Absender stets bei irgendwelchen Kommunikationspartnern von uns besorgt, oder aus anderen Quellen wie gekauften Adresslisten.
Oft steht der angebliche Absender von uns auch gar nicht als From: im Header der SPAM Mails, sondern als angezeigter Name einer gänzlich anderen Absender email Adresse.
Ich mach mir da keinen mehr Kopf drum, weil jede solche Mail vor dem öffnen als solche erkennbar war und ich das den Empfängern auch stets so erkläre.
Ich kann sowas auch nicht verhindern, denn schließlich ist keines unserer Systeme daran beteiligt.
