Beiträge von riawie

ist der Client eigentlich nur bei uns schnarchnasiger geworden?

Zitat von t.meyer

Strongbox macht bei uns tatsächlich nur alle 30 Tage ein Backup. Die Daten der Strongbox sind leider zu alt. Ein Tägliches Backup des gesamten Servers wird von BackupChains auf eine NAS übertragen.

Da kann ich nur dazu raten das dringend zu ändern und zwar nicht täglich ein Vollbackup, sondern täglich ein inkrementelles Backup.
Alle 30 Tage ein Vollbackup kann dabei durchaus bestehen bleiben, wobei das dann halt doch recht viel Speicher braucht, da machen größere Intervalle durchaus Sinn, Hauptsache es werden täglich alle neu hinzugekommenen Mails gesichert.

Zitat von t.meyer

Ein Tägliches Backup des gesamten Servers wird von BackupChains auf eine NAS übertragen.

Was halt wenig hilfreich ist wenn man die Notwendigkeit bemerkt einzelne Mails wiederherstellen zu müssen.

Zitat von t.meyer

Angenommen wir wollen die Backups auf der NAS aktivieren, der gesamte Server würde also zurückgesetzt werden, könnten wir die neuen Mails irgendwie übertragen, sofern sie zuvor gesichert wurden?

lass eine aktuelle Strongboxsicherung erstellen und leg die auf Deinem NAS ab, dann hast Du anschließend die Möglichkeit alles was seit Deinem wiederhergestellten Backup und der aktuellen Stronboxsicherung aufgelaufen ist aus der Strongbox wiederherzustellen und zwar mit allen Status Informationen.

Wenn Ihr das tatsächlich tun wollt, schalte nur unbedingt vor dem erstellen des aktuellen Stronbox Images den Grabbing Server aus, sonst kann es passieren das später noch mails abgeholt werden, die nicht mit in der Strongbos landen.
Je nach Datenmenge die zu sichern ist kann das erstellen der Strongbox aber recht lange dauern.
In dem Fall kannst Du den Grabbing Server auch erst mal laufen lassen, eine Vollsicherung machen, dann den Grabbing Server ausschalten, eine inkrementelle Sicherung erstellen - das geht dann deutlich zügiger - und anschließend den David Server aus dem Backup wiederherstellen.
Nach dem der Server wiederhergestellt ist kannst Du dann die Nachrichten seit erstellen der Sicherung bis zum erstellen der Strongbox aus eben dieser Stongbox wiederherstellen.
Aber vergiss nicht die Strongbox mit auf das NAS zu legen

Es gibt mehrere Wege das Problem zu lösen.

ARC Util ist eine davon, allerdings sollte man vorher eine Kopie des jeweils zu behandelnden Archivs irgendwo sicher ablegen.

Die einfachste Variante wäre allerdings die fehlenden Mails aus der hoffentlich vorhandenen Strongbox Sicherung wieder herzustellen.

Sollte die Stronbox an dem Tag nicht mehr befüllt worden sein, wäre die nächste Methode der Weg ohne ARC Util auch diese wieder herzustellen.

Falls auf den Server in den Einstellungen des Postman auf dem Reiter Erweitert das speichern der Original Nachricht eingeschaltet ist kann man auch im jeweiligen Archiv genau diese Original Nachrichten suchen - das ist jeweils die größte Datei einer Gruppe von Dateien mit gleichem Namen, aber unterschiedlichen Endungen. Diese Datei kann man dann in Dateiname.eml umbenennen und am David Client einfach in das jeweilige Archiv ziehen, sie wird dann dort als eingegangene Mail eingefügt, es sind allerdings nicht alle Status Informationen (Gelesen, beantwortet, weitergeleitet usw.) erhalten die man sonst kennt.

Ein vollständiges deistallieren des Clients und entfernen aller von ihm hinterlassenen Dateien und Einstellungen ist doch gar nicht nötig.

Einfach den Inhalt des AutoSave Ordners löschen und für die Zukunft den Haken bei "Auto-Wiederherstellung abgebrochener Nachrichten" rausnehmen, damit er nicht wieder gefüllt wird.

Man muss halt nur auch hartnäckig genug nach dem AutoSave Ordner suchen und nicht aufgeben bevor man ihn gefunden hat

Mit ein wenig Mühe kannst Du Dir das mit ChatGPT als PowerShell Job mit Ordnerüberwachung über die David API selbst bauen.

Das ist letztlich dank ChatGPT kein monströses Hexenwerk mehr.

Lohn der Mühe ist dann das Du etwas bekommst, was tatsächlich genau das macht was Du möchtest und auf Deinen konkreten Bedarf zugeschnitten.

Ansonsten ist auch mir nur das Tool von Karley bekannt.

Zitat von Strategister

Ich hab bei meiner Recherche nun auch diese zwei Haken rausgemacht, leider auch ohne Erfolg.

Die beiden haben auch nichts mit der Geschichte zu tun.
Du kannst diese beiden Haken also auch wieder setzen.

Zitat von Strategister

Hat leider auch keine Wirkung gezeigt, ich werde mal das Logfile auswerte vom macOS und hier posten, falls es da etwas zu analysieren gibt.

Das löschen der Haken bei Auto-Wiederherstellung abgebrochener Nachrichten hat auch erst Wirkung, nach dem Du den oben genannten Ordner bzw. dessen Entsprechung auf den MACs gefunden und seinen Inhalt gelöscht hast. Der Haken sorgt nur dafür das er auch nicht wieder gefüllt wird.

Ich hab leider keinen MAC im Zugriff, kann also nicht für Dich gucken, aber die Lösung Deines Problems ist verbindlich die alten abgebrochenen Nachrichten zu löschen. Erst wenn die Weg sind hört der Ärger auf.

Der Pfad aus Deinem Log ist im übrigen nur der Pfad wo die Application selbst liegt, nicht der Ort an dem sie ihre lokal gespeicherten Daten des jeweiligen Nutzers ablegt.

hast Du denn den Pfad auf den MAC Geräten identifizieren und die Dateien löschen können?

Zusammen mit der Einstellung von Wizzard (Einstellungen > Editor > Optionen > ) sollte danach eigentlich Ruhe sein.

Falls die Einstellung keine Folgen zeigt oder sich am Client nicht ändern lässt, gibt es die gleiche Option auch im David Administrator unter:
System > Benutzer > rechtsklick auf einen Benutzer, oder auch eine markierte Menge an Benutzern > Eigenschaften > Benutzerdaten > David Client konfigurieren > Editor > erweitert >
Falls die Option dort aktiv ist und wohlmöglich der Haken unten bei fehlt kann man das am Client nämlich gar nicht ändern

Lass bitte eine Rückmeldung hier wenn Du das Problem gelöst hast, dann können das später auch andere mal finden

ist das eine Unterordnerstruktur mit Aufteilung nach Monaten?
Fallas ja, kann es sein das Ordner älterer Monate den Status ausgeblendet haben?
Ausgeblendete Ordner werden nämlich nicht indexiert.

unter Windows reicht es wenn man in so einem Fall den Ordner:

C:\Users\<Benutzer>\AppData\Roaming\Tobit\David\<NAME>\AutoSave\

einmal leer macht.

Sicher gibt es dazu auch eine passende Entsprechung unter MAC OS, vermutlich irgendwo unterhalb von ~/Library

Insbesondere da gerade wieder Interesse an dem Thema aufgekommen ist noch ein Nachtrag zum aktuellen Verhalten von David.

Im aktuellen David kommt es zu seltsamen Fehlfunktionen wenn ich eine include mit dem David Editor bearbeite.
Anschließend erhält nur noch der letzte NRL Eintrag eine Kopie der Mail.
Beheben lässt sich das indem man den gesamten Text der include nach dem man sie bearbeitet hat aus der include ausschneidet, das Format der Nachricht wieder auf nur Text umstellt und anschließend den Text wieder als ganzes einfügt.
Anschließend bekommen dann auch wieder alle gewünschten Empfänger ihre Kopie.

Strategister besonders für Dich, der Du Dir das hier gerade die Tage angeschaut hast, nicht das Du damit verzweifelst, nur weil der Editor da gerade Mist baut

Bei uns gibt es bislang keine Beschwerden über verschwundene Mauszeiger, weder unter Rollout 529, noch unter Rollout 535

selbst wenn es keine Verknüpfungen auf den Ordner oder Elemente darin gibt ist es recht unschön die Inhalte von Hand zu verschieben, denn es versaut einem die "Antwort/Weiterleiten an" Historie und bewirkt das alle Objekte einmal als aktuell manuell angefasst gekennzeichnet werden.

Außerdem löst das verschieben von Nachrichten je nach Nachrichtentyp und dort eventuell vom Absender angefordertem Tracking, sowie den lokalen Tracking Einstellungen unter Umständen jeweils eine Tracking Nachricht aus, was gerade beim neu organisieren großer Archive sogar zu großer Serverlast führen kann.
Ich hatte zu dem Thema mal einen eigenen Beitrag hier im Forum, weil ein Nutzer zehntausende von Mails umsortiert hatte und weitere zehntausende plante, nach dem ich dann wusste was los war hab ich den Rest seiner Ordner für ihn wie unten beschrieben umsortiert und so konnte unter anderem auch dieses Problem komplett umgangen werden.


Also besser:
alten Ordner im Client Umbenennen, so das man ihn klar als alten Ordner erkennen kann,
neuen Ordner mit auf Dateisystemebene korrektem Namen anlegen,
Eigenschaften des alten Ordners öffnen,
Dienste > Automatische Ablage aktivieren,
Einträge verschieben nach auf 1 Tag einstellen
Jahres-, Monats-, Tagesunterteilung und "Nur ungelesene Einträge" abwählen
Erweitert anklicken
dort dann den neu angelegten korrekt benannten Archiv-Ordner auswählen.
Alles mit OK bestätigen

1 bis 2 Tage warten bis der alte Ordner leer ist.
Der alte Ordner kann nun gelöscht werden

Lohn der Mühe:
Die verschobenen Objekte behalten alle Eigenschaften inklusive des letzten Zugriffs der "Antwort/Weiterleiten an" Historie und auch die native Eintragsreihenfolge wie im Ursprungsordner und es werden keine Tracking Informationen im System erzeugt.
Beim von Hand verschieben großer Objektmengen kann sich nämlich auch die Eintragsreihenfolge bisweilen ungewollt verändern.

edit: es sollten doch dann jetzt eigentlich 4,65 € je Nutzer sein

Anpassung der Lizenzierung  

Die Nutzung von SideKick bleibt auch künftig optional, die User-Lizenz wird für TeamDavid-Kunden aber deutlich günstiger. Wurden bislang monatlich pauschal 28,50 € pro User berechnet, sind es künftig 4,65 € pro User zzgl. verbrauchsabhängiger Credits für die Nutzung der Modelle. 

gucken wir mal wie sich das entwickelt...

Nach 4 nicht öffentlichen Rollouts ist es nun also so weit, Rollout 535 bringt den SideKick Server für alle SiteCare Nutzer ohne zusätzlichen Kaufpreis mit.

Weiterhin bringt dieses Rollout eine neue Variante der Kalender Synchronisation für Microsoft 365 Kalender mit, welche nun nicht mehr nur gucken, sondern echte Synchronisation in beide Richtungen erlaubt.

Ich bin gespannt wie gut das alles funktioniert.

Das Problem ist halt oft auch schlicht vom wirtschaftlichen Umfeld getrieben.

Die Kunden und Partnerfirmen wollen via Teams kommunizieren und Mail gerät zusehends an den Rand.

Eine vollständigen Einbindung von Teams ins Kommunikationssystem einer Firma ist halt letztlich nur mit Microsoft Exchange machbar.

Das man sich dabei auch eine Tonne an Sicherheitsproblemen einhandelt wird selbst nach ausführlicher Erläuterung bestenfalls als nebensächliches (aber halt zu behandelndes) Problem gesehen.

Das viele von Microsoft versprochene Fähigkeiten dann trotz eines durchgängigen Microsoft Systems nicht wie erhofft funktionieren wird schlicht als Problem einer unzulänglichen IT und nicht in der unzulänglichen Erfüllung der Versprechen durch Microsoft angesehen.

Ich kenne diese ganzen Diskussionen rauf und runter nur zu gut.

Leider hat Tobit es in den vergangenen Jahren versäumt einige grundlegende Probleme besser anzugehen.

So gibt es z.B. nach wie vor Probleme mit Terminen zu welchen von außen eingeladen wurde.
Hat man so eine Einladung angenommen und ändert der Einladende den Termin später ist es ein Glücksfall ob man den Termin nach Annahme der Änderung noch im Kalender hat.
Tobit hat es leider nie verstanden das es egal sein sollte ob es den ursprünglichen Kalender Eintrag noch finden und aktualisieren kann, oder nicht.
Nimmt man die Änderung an, dann hat der Eintrag im Kalender aufzutauchen und fertig.
Bei Tobit hingegen verschwindet so ein Eintrag immer mal wieder sang und klanglos.
Das hat im Hintergrund zwar nachvollziehbare Gründe, aber diese sollten eben wie bei Microsoft Outlook schlicht abgefangen werden und nicht in einem verschwinden des Termins den man gerade als Änderung bestätigt hat gipfeln.

Microsoft Outlook oder auch Microsoft Temas schicken bei einer Änderung grundsätzlich genug Informationen mit, das man auch aus der Änderung allein einen neuen Kalendereintrag bauen könnte, wenn man den alten nicht zum ändern findet.
Hat man den zu ändernden Termin zuvor bereits gelöscht, ist bei Team David auch die anschließend angenommene Änderung im Ergebnis weg.
Bekommt man die gleiche Änderung in Outlook und nimmt sie an, nach dem man den eigentlichen Termin bereits gelöscht hat, wird der geänderte Termin einfach mit dem nun gültigen neuen Datum neu im Kalender angelegt, als ob nichts gewesen wäre.
Kommt später noch eine Änderung rein wird auch das unter Outlook fehlerfrei behandelt und der nun ja im eigenen Kalender doch wieder vorhandene Termin bei Annahme der Änderung korrekt verschoben.
Passiert das gleiche unter Team David bekommt man nicht mal eine Fehlermeldung wenn man die Änderung annimmt, aber eben auch keinen Eintrag im Kalender für den Termin.

Was ich mich über dieses Thema schon habe ärgern dürfen geht auf keine Kuhhaut.
Ja, formal hat Tobit recht, ein nicht mehr vorhandener Termin kann nicht verschoben werden.
Doch faktisch sollte das schlicht egal sein.
Alle nötigen Informationen um den Termin einfach neu anzulegen sind in der Änderungsnachricht vorhanden.
Es sollte also eine Meldung kommen:
"Der Ursprungstermin konnte in ihrem Kalender nicht gefunden werden. Möchten Sie das der Termin mit neuem Datum neu angelegt werden?"
So einfach ließe sich das lösen.
Macht Tobit aber schon seit Jahren nicht.
Das Problem besteht seit vielen Jahren, wurde oft gemeldet und nie gelöst.

Und leider ist das halt nicht das einzige Interoperabilitätsproblem.

Zitat von stylistics

Es kam gerade Rollout 531...

---

Habe es drauf, jetzt kommt das R531 drauf

Und was hat 530 Deinen Erkenntnissen nach an Veränderungen gebracht?

also hier funktioniert der Link von lycra noch

...oder wieder? keine Ahnung, aber aktuell funktioniert er

danke für den Link, aber ohne Release Notes spiele ich das eh nicht ein und der erste bin ich dabei generell nicht gerne
Kannst ja mal berichten wie es läuft und was es mitbringt, falls Du das herausfinden willst / kannst, ohne Release Notes

also mein gerade neu gestarteter Service Layer findet nix neues zum Download und sagt die VIntern 3900 sei aktuell, was Rollout 529 ist