Danke, das probiere ich mal.
Momentan arbeite ich remote, und es hakt und zwackt ab und zu mal im neuen Client, allerdings gab es bislang keine längeren Aufhänger.
Was mir schon positiv aufgefallen ist: Filtert man per Quickfinder in einem großen Archiv (z. B. Postausgang), geht das jetzt VIIIIEL schneller. Früher: 60 Sekunden, jetzt: 2 Sekunden.
Vielleicht ist ja doch nicht alles schlecht am neuen Client. 
Sind ggf. die Prozessnamen geändert worden? Ich habe jetzt mal msedgewebview2.exe als Prozess-Ausnahme ergänzt und teste damit.
Inzwischen läuft nebenan auch ein PC mit lediglich MS Defender als Virenschutz. Da ist das Verhalten bislang tatsächlich nicht aufgetreten...
Bei uns keine Probleme in der Richtung. Allerdings beobachte ich schon seit einer Weile, dass der Service Layer sich bei einigen Kunden schwer tut, nach einem Reboot sauber zu starten. Wir haben daher als Workaround ein Script in der Aufgabenplanung, das 3 Minuten nach Systemstart noch einmal ein NET START DAVIDSERVICELAYER abschickt. Nicht hübsch, aber funktioniert.
Warum der SL so zickt, konnten wir bislang nicht herausfinden. Temporäre Dateien etc. sind alle sauber bereinigt worden, und bei einem manuellen Start klappt es auch jedes Mal ohne Fehler und zügig. Nur beim Reboot halt nicht.
Ich hab' mal das Rollout 415 zum Anlass genommen, mich zum neuen Client zu zwingen. Und bekam prompt das gleiche Problem. Im Eingang alles ganz normal, ich gehe in der Liste auf eine Mail, klicke auf "Antworten" -> das Antworten-Fenster öffnet sich, aber nix ist drin. Man wartet ca. 40 Sekunden, dann erscheint plötzlich der Nachrichtentext.
Neue Mail erstellen: Leeres Fenster geht auf. 40 Sekunden warten, dann erscheint endlich die eigene Signatur.
Mail geschrieben und mit Status "warten" abgeschickt -> Eintrag erscheint im "in Transit", aber in der Vorschau sieht man nichts. Auf "Freigeben" klicken, 40 Sekunden warten, dann kommt die Nachfrage "Soll der Wartezustand aufgebhoben werden?"
Das erinnert mich an das sporadische Verhalten des alten Clients, wenn man z. B. über eine Internetfreigabe direkt von Unterwegs gearbeitet hat. Da hat sich der Client dann aber nach 30-40 Sekunden berappelt und lief anschließend OK.
Das Problem ist auch nicht wirklich reproduzierbar. Mal läuft lange alles wunderbar, dann hängts. Mit dem Classic Client keinerlei Schwierigkeiten auf der gleichen Maschine. Domain, DNS etc. ist alles sauber.
Securepoint AV kommt zum Einsatz, ich habe leider gerade keine andere Maschine zum Ausprobieren greifbar. Ich habe C:\Program Files\David Client vom Scan ausgeschlossen, zusätzlich die Prozesse msedgeview2.exe und dvwin4.exe.
Wenn das bei den Kunden auch so auftritt, können wir uns echt warm anziehen... :-/
Nach 5 Stunden Laufzeit erscheint ein Hinweis im Classic Client, dass es in wenigen Wochen einen neuen, frischen Look gibt
Ah ja, Microsoft-Style: Statt die berechtigte Kritik an der Optik aufzunehmen und den neuen Client benutzbar(er) zu machen, zwingt man den Kunden einfach zu seinem Glück. Ganz großes Kino.
Da werden wir uns von den Kunden wieder einiges anhören müssen. 
Schön regelmäßig Sitecare dafür zahlen, dass man sich gängeln lassen muss.
Moin zusammen,
ich hatte bisher nur in diesem Zusammenhang mit dem Verzeichnis "temp" im Archive von Usern (\\server\David\Archive\USER\xxxxxxxx\temp) zu tun. Das Verzeichnis scheint ulkigerweise nicht bei allen Usern zu existieren, und es taucht nicht als Archive im David-Client auf (die Aussage hier ist wohl fehlerhaft). Offenbar also ein Systemverzeichnis, in dem David Dinge tut.
Hintergrund der Anfrage ist, dass bei einem Kunden auffiel, dass sich in diesen temp-Verzeichnissen mitunter größere Datenmengen anhäufen: Da liegen PDFs, Grafiken, teilweise auch ganze Ordner. Viele relativ aktuell, manche schon Jahre alt.
Bei unserer hauseigenen Installation sind alle temp-Ordner leer. Daher tun wir uns gerade etwas schwer, das zuzuordnen. Auf den ersten Blick würde ich aber sagen, es handelt sich um Anhänge, die entweder versendet oder empfangen wurden. Die Frage ist natürlich, ob man die einfach weglöschen kann, denn im Einzelfall ist der Platzbedarf schon erheblich.
Habt ihr diesbezüglich Ideen? Eine Foren-Suche brachte leider nichts zutage.
Bei ca. 20% unserer Kunden war heute morgen ebenfalls der SL inaktiv. Ließ sich aber manuell anstoßen.
Über Nacht war bei vielen ein "hotfix 358701" installiert worden. Ich hab' leider keine Ahnung, was es damit auf sich hat, auf unserem eigenen Server ist dieser Hotfix bislang nicht eingetroffen.
Die Meldungen liegen auch noch einmal im Archiv "System -> David -> Ereignisse". Da kann man direkt erkennen, welches Konto den Fehler wirft.
OK, also irgend eine Art von Schluckauf gab es - das Problem war bei Tobit bekannt ("wir sind an dem Thema dran"), gestern Abend kam dann aber via Chat die Nachricht, dass es nun nicht mehr auftreten sollte.
Wir hängen immer noch mit obiger Fehlermeldung fest und bekommen wegen des "RateLimit reached" kein neues Zertifikat ausgestellt. Werden mal ein paar Tage abwarten. Bei den Kunden gibt es zum Glück keine derartigen Auffälligkeiten.
übernimmt man gewisse Einstellungen ja gern auf alle von einem betreuten und hinreichend ähnlichen Systeme
Könnte aber natürlich auch ein Problem mit einem gemeinsamen Upstream gelegenen Provider sein...
"Leider" nicht, ich habe zum Testen extra den Kunden ausgewählt, der von uns geographisch am weitesten entfernt sitzt. Anderer Provider, anderer Router (beim Kunden nur eine simple Fritz!Box ohne besondere Firewall-Beschränkungen), anderer Subdomain-Host (einmal dyndns, einmal A-Record auf feste IP). Außer einer weitgehend identischen David-Installation kann ich derzeit keine potenziell Problem-verursachende Übereinstimmungen erkennen.
Aber du hast natürlich Recht, bei Let's Encrypt selbst gibt es keine Störungsmeldungen und auch keine passenden neuen Einträge im Forum. Wäre schon seltsam, wenn eine Störung bei so einem großen Dienst nicht auch anderen Benutzern auffällt.
Für heute ist eh erstmal Pause angesagt:
Error: Error order certificate
StatusCode: 500
Description: Failed to create challenge
Reason: RateLimit reached
Ich schaue mir das morgen noch einmal an. Unser Zertifikat gilt ja noch bis 13.12. ...
OK, ich denke nicht, dass es an unserer Konfiguration liegt, bei einem Kunden ist das Problem soeben identisch aufgetreten. Die letzte automatische Aktualisierung funktionierte noch reibungslos.
Also: Fehler bei Let's Encrpyt? Oder Bug in Rollout 414?
Moin,
bei uns wäre heute die Erneuerung des Webbox-Zertifikats via Let's Encrypt dran. Es kommt aber nur:
(AC) Certificate Order Error
Code: 1008
Error: Order certificate request failed
StatusCode: 500
Description: Failed to complete challenge
Reason: Request failed
An der Konfiguration hat sich nichts geändert, Port 80 ist offen, Webbox läuft. Porttest OK. Ich kann unsere öffentliche Adresse problemlos ansprechen, sowohl über den Hostnamen als auch über die IP.
Problem bei LE? Oder was kann das sonst sein? Hat jemand von euch schon ein neues Zertifikat angefordert bzw. erhalten, seit Rollout 414 draußen ist?
Moin,
zu a) hat mir Tobit vor Kurzem geantwortet, dass das nicht möglich sei. Ich würde mir ebenfalls eine entsprechende Option oder einen Reg-Key wünschen, mit dem die Meldung unterdrückt wird. Aber der neue Client soll wohl "gepusht" werden.
Für den Einsatz des (durchaus sehr guten) in David eingebauten SPAM-Schutzes, bei Tobit MIS genannt, wird afaik eine aktuelle Version benötigt, also david.3 - mit der alten fx.12 kommt man an der Stelle nicht weit.
Es gibt allerdings einige Drittanbieter-Lösungen, die an die Plattform keine so strengen Anforderungen stellen. Spontan fällt mir DvSPAM von SyntaX ein. Oder ihr arbeitet mit einem SPAM-verdauenden Proxy, einer Firewall, oder, oder... Möglichkeiten gibt es da viele.
sicher das es keine signierten Nachrichten sind?
Da wäre das ändern nämlich verboten und sollte auch unmöglich sein...
Leuchtet ein, aber das kann ich ausschließen. Es sind bei mir alle Nachrichten betroffen, sogar die Script-generierten plain-text-Meldungen der Datensicherung...
Mail markieren, rechte Maustaste, Eigenschaften, Betreff ändern
Ulkig: Das funktioniert in der Tat einwandfrei. Danke, ist ein guter Workaround.
ich mach das zwar meist in der Eintragsliste mittels F2
Das klappt ebenfalls. Komplett öffnen + ändern + speichern hingegen nicht.
Ulkig 2: Stelle gerade fest, im Modern Client tritt das Problem nicht auf... Da der Classic Client nicht mehr weiter entwickelt wird, bringt eine Nachfrage bei Tobit vermutlich nix.
Naja. Mit der Lösung/den Lösungen kann ich leben, es geht in 99% der Fälle eh nur um den Betreff.
Danke euch!
Moin zusammen,
ich sehe vermutlich gerade mal wieder den Wald vor lauter Bäumen nicht. Bis vor einiger Zeit habe ich gerne Einträge in meinem persönlichen Eingangsarchiv angepasst. Da kommt zum Beispiel eine Mail von der Fritzbox mit dem Betreff "Nachricht von 12345 98765" - wenn das etwas ist, auf das ich später antworten wollte, habe ich die Nachricht geöffnet, den Betreff geändert (z. B. hinten dran gehängt: "Herr Müller Rückruf am Donnerstag") und die Sache mit Strg+S gespeichert.
Seit neustem funktioniert das nicht mehr. Statt dass der Eintrag direkt gespeichert wird, erscheint eine Abfrage, wo ich speichern will, und dort legt David dann eine Kopie des Eintrags ab. Was blöd ist, da damit auch die zeitliche Sortierung nicht mehr stimmt.
Mache ich irgendwas falsch? So ganz zeitlich einordnen kann ich es leider nicht, denke aber, dass es so vor ungefähr 6 Monaten noch problemlos funktioniert hat. Ich benutze nach wie vor den Classic Client (aktuelles Rollout). Hat jemand ne Idee?
Der SQL-Server ist bei David eher "Beiwerk", da sind bzgl. Usern, Konfiguration etc. keine relevanten Sachen gespeichert. Wenn du noch keine Chats hast, die erhalten bleiben müssen, kannst du die Datenbanken im SSMS einfach weglöschen und dann den Service Layer neu starten - auf diesem Wege werden die DBs automatisch neu erzeugt (Disclaimer: AFAIR. Wenn du unsicher bist, mach vorher eine Sicherheitskopie der Datenbanken).
Dazu muss natürlich trotzdem die prinzipielle Kommunikation mit dem SQL vom Service Layer her möglich sein. Was mir spontan dazu einfällt:
14.0.x ist SQL-Server 2017, ja. Das aktuelle kumul. Update müsste dieses sein: https://www.catalog.update.microsoft.com/Search.aspx?q=KB5016884 (über Windows Updates sollte ebenfalls klappen, ggf. die Option "weitere MS-Software über Windows Updates aktualisieren" aktiv schalten).
So sollte das ungefähr aussehen:
Wurde der SQL-Server im Rahmen des David-Setups automatisch eingerichtet, oder hast du das manuell gemacht? Verpass dem mal die aktuellen Patches (wenn Standard Tobit-Installation: Auf Sprache "Englisch" achten), lade dir das MS SQL Server Management Studio herunter und schau, ob eine Verbindung möglich ist und in der Instanz DAVID bereits Datenbanken existieren.
Generell kannst du dort auch die DB zurücksetzen, allerdings sieht mir das oben eher so aus, als ob gar keine Kommunikation mit dem SQL möglich wäre. Grätscht evtl. die Firewall dazwischen? Klappt die Anmeldung via SSMS?
