Beiträge von nordtech

    Moin,

    ein Kunde mit einem "antiken" David (Version 12.00a 2714, müsste so 2013/2014 sein) bekommt plötzlich keine Mails mehr via Grabbing Server. Kurios dabei ist, dass ich in der Kommunikation keinen Fehler zu erkennen vermag, mir sieht das so aus, als mache Strato die Verbindung einfach wieder dicht.

    Geprüft wurden Verbindung und Zugang, soweit alles OK. Wenn wir die Zugangsdaten bei uns in einen anderen (aktuellen) David eintragen, klappt's. Testweise wurde auf dem betreffenden Server auch ein Thunderbird Portable eingerichtet und für POP konfiguriert, das klappt auch. Somit sollten Account- oder Verbindungsprobleme eigentlich ausgeschlossen sein.

    Wenn ich in den Eigenschaften des Kontos auf "Testen" klicke, kommt: "Es konnte keine Verbindung zum Server aufgebaut werden". Was in der Form nicht ganz stimmt, denn plaudern tun die beiden ja miteinander:

    ...und dann ist er durch damit. :(

    Schon klar, alles uralt, kein Support, usw. Aber bis vor einigen Tagen lief das so ganz brav, und Verschlüsselung (Port 995, SSL/TLS) konnte der alte David auch schon.

    Jemand eine Idee?

    Wie beschrieben, es handelt sich um die App "RD Client" auf dem iPad - da sind die Optionen spärlich. Man kann maximal "Maustasten vertauschen" aktivieren und Soundübertragung an-/ausschalten.

    Seltsam ist halt, dass die Tastatur überall sonst funktioniert, nur mit dem David-Client nicht. Was macht David diesbezüglich anders als der Rest?

    Moin zusammen,

    ein Kunde berichtet Folgendes: Er hat ein iPad mit angeschlossener Bluetooth-Tastatur. Via VPN + RDP-App (der Microsoft-eigene "RD Client") greift er auf einen Terminal Server auf Basis von Windows Server 2019 zu. Klappt soweit auch alles.

    Jedoch: Eingaben mit der zugesteckten Tastatur gelingen ihm nicht, über die Bildschirm-Tastatur klappt's. Und dieses Phänomen tritt NUR im David-Client auf, in allen anderen Anwendungen incl. Word & Co. geht's auch mit der Tastatur einwandfrei.

    Ich kann das Problem lokal dummerweise nicht reproduzieren und würde nun auf Verdacht andere RDP-Clients ausprobieren. Vorher aber die Frage in die Runde: Hattet ihr das schon einmal? Bzw. ähnliche Konstellationen laufen, wo's auch im David sauber funktioniert? Ich bin gerade ein wenig ratlos. :(

    Ein Kunde hatte heute früh exakt dieses Problem - habe die betreffende Datei (Teams-Besprechungsanfrage) aus dem \apps\\dvgrab\in gefischt und an Tobit geschickt, schon nach 20 Minuten kam Antwort, dass das Problem bekannt sei. Scheint also tatsächlich häufiger vorgekommen zu sein.

    Bei uns glücklicherweise nichts dergleichen. Nach Jörgs Beitrag hatte ich gestern Abend stichprobenartig auf einige Kundensysteme geschaut, aber dort lief nach dem Update alles an Diensten wieder ganz brav. Und heute hat bislang auch noch niemand gemeckert. ;) Server 2012 / 2016 / 2019.

    Kleiner Tipp, falls nach Rollout 334 bei euch obige Meldung erscheint, obwohl "HTML-Inhalte mit Chromium darstellen" aktiv ist: Bei mir war das Feld "Max. Cache-Größe" (ebenfalls im Dialog Einstellungen -> HTML) leer. Nachdem ich dort einen Wert eingetragen und den Client neu gestartet habe, ist die Warnung nun weg.

    Wobei es insbesondere bei der Webbox sinnvoll sein kann, das über die Dienste-Konsole zu erledigen und dann die Startart statt "Automatisch" auf "Automatisch (verzögert)" zu stellen. Zumindest vor einigen Jahren hatte das Modul ansonsten öfter mal Probleme, korrekt in die Hufe zu kommen. Bin allerdings nicht sicher, ob das noch immer so ist, hab's lange nicht ausprobiert.

    Uuuups :) So kann's gehen.

    Gutes Design ist das trotzdem nicht: Was hat die Funktion, ein Zusatzfenster zu öffnen, in einem drop-down zu suchen? Früher[tm] gab's mal sowas wie GUI-Styleguides bzw. einheitliche Bedienlogik. Naja, aber wenn sich der Hersteller des OS schon selbst nicht daran hält, bekommt man halt solche Auswüchse.

    Dieser Thread ist jedenfalls ein Beweis dafür, dass die aktuelle Ausführung nicht sonderlich intuitiv umgesetzt wurde. ;)

    Dass man dort manuell keine Ordner mehr auswählen kann, war mir schon aufgefallen, ja. Dass nur die Systemvorlagen auftauchen, nicht. Immerhin bleibt eine bestehende Vorlage aus einem anderen Archive erhalten, daher hab' ich's bislang nicht bemerkt.

    Workaround: Im David-Admin gibt's bei der Benutzerkonfiguration noch den alten Dialog, incl. freier Archive-Auswahl.

    Optimal ist das in der Form allerdings tatsächlich nicht.

    Wie gesagt, ich habe keine Möglichkeit DNS-Einträge beim DynDNS-Anbieter zu machen

    Auch nicht den AAAA-Record einfach manuell rauslöschen? So mache ich das bei einem Kunden, der über dyndns.org läuft.

    Wenn das nicht klappt, würde ich ebenfalls eine Variante meiner beiden Vorschreiber empfehlen: Entweder für schmales Geld ein eigenes Zertifikat kaufen oder bei z. B. Strato eine Domain reservieren, dort eine Subdomain mit dynamischem Host einrichten und jenen in deiner Fritz!Box hinterlegen. Dann klappt's auch wieder mit Let's Encrypt.

    Das Wesentliche steht schon in der Meldung: "Failed to validate DNS-records (AAAA)", also passt die IPv6-Adresse nicht zum DNS-Eintrag.

    Bei dnynds-Adressen habe ich die besten Erfahrungen damit gemacht, den AAAA-Record zu löschen, da er von Let's Encrypt bevorzugt gezogen wird. Gibt's keinen AAAA-Eintrag, sucht LE nach dem A-Record, und dann ist alles gut.

    Alternativ konfigurierst du IPv6 so, dass es tatsächlich auf deinem David-Server ankommt - ob und wie das mit dynamischen Adressen klappen kann, steht auf einem anderen Blatt. Mir fällt spontan nicht ein, wie - aber um IPv6 habe ich mich offen gestanden auch bislang noch ziemlich herum gedrückt...

    Danke für euer Feedback! Den debug-Mode müsste ich ja permanent mitlaufen lassen, bis der Fehler wieder auftritt, richtig? Da habe ich ein bisschen Bedenken, da das Problem sich wie gesagt nur sehr sporadisch mal zeigt. Oder ist das nach eurer Erfahrung arm an Nebenwirkungen (im alten KB-Artikel zum Thema steht was von "erhöhter Systemauslastung")?

    An Krücken mit erzwungenem Neustart habe ich auch schon gedacht, oder aber den SL zu Beginn der Datensicherung anhalten und anschließend wieder starten. Elegant ist das natürlich nicht. Zumal nach der Schilderung von graef-edv fraglich scheint, ob wirklich das Backup eine Rolle spielt.

    An einer alten Server-Version liegt's bei uns nicht, das ist Server 2016 Standard incl. aktueller Patches (unter Hyper-V). Was uns wurmt, ist dass wir unsere Installationen i. d. R. sehr ähnlich gestalten, dieser Kunde aber der einzige ist, bei dem das Phänomen auftritt.

    Eine Besonderheit gibt's allerdings: Das System lief eine ganz Weile problemlos, bis irgendwann der Platz knapp wurde. Wir haben daraufhin fürs David-Datenvolume die Windows-eigene Deduplizierung eingeschaltet und so auch jede Menge Speicher eingespart, aber einige Zeit später trat obiges Problem auf. Inzwischen wurde der Server erweitert, das virtuelle Volume ausgedehnt und die Deduplizierung rückgängig gemacht - weil wir das Feature in Verdacht hatten. Brachte nur leider nichts. Es kann sich also auch hier um Koinzidenz statt Korrelation handeln... Zumal graef-edv die Deduplizierung unter 2008R2 vermutlich nicht aktiviert hat (gab's die da überhaupt schon?)

    Hallo Gemeinde,

    wir haben bei einem Kunden einen Fehler, der uns bei noch keiner anderen Installation untergekommen ist. "Freundlicherweise" tritt er auch nur sporadisch auf. Alle 3-6 Wochen einmal.

    Das Symptom ist stets identisch: Wenn man auf den Server schaut, sieht eigentlich alles gut aus. Alle David-Dienste laufen, keine Probleme im System. Startet man allerdings den David-Client, passiert nichts. Keine Fehler, keine Server-Auswahl. Wir haben daher bislang immer den Service Layer neu starten wollen.

    Der Service Layer aber bleibt beim Beenden im Status "Wird beendet" hängen. Man muss manuell den Task abschießen, dann den SL neu starten - und plötzlich rennt wieder alles wie gewohnt, ohne Probleme, ohne Fehler.

    Bisherige Untersuchungen und Erkenntnisse:

    • Keine Fehler im Windows-Eregnisprotokoll
    • Keine Fehler im David unter System -> Ereignisse
    • Es wurden kürzlich keine Updates eingespielt und der Server auch nicht neu gestartet
    • Eine Bereinigung temporärer Dateien gem. Tobit-KB haben wir jedes Mal durchgeführt, dort gab's aber keine "angesammelten" Dateien
    • Virenschutz ist unschuldig, es läuft nur der Defender, und David ist komplett ausgeklammert. Funde gab's auch keine.

    Bisher machte sich das Problem immer am Morgen bemerkbar, der Kunde konnte also an Tag X normal arbeiten, machte Feierabend, und am nächsten Morgen hing's. Da Updates und Neustart inzwischen ausgeschlossen wurden, bleiben eigentlich nur Datensicherung und Datenbereinigung als Ursache übrig. Das auszuschließen ist problematisch, wenn der Fehler so selten auftritt. Es gibt aber eine gewisse Korrelation zwischen der gestern zuletzt eingetroffenen Mail (23:02 Uhr) und dem Start des Backups der David-Daten-Partition (23:03 Uhr). Wobei das auch nicht 100% akkurat ist, da über Nacht wenig Mail eintrudeln - genau so gut könnte der Aufhänger um 03:30 Uhr aufgetreten sein. Das Backup erfolgt mittels Drive Snapshot (auf Basis der MS-Schattenkopien), das Tool ist uns bisher immer nur als extrem pflegeleicht untergekommen. Fest steht auch, dass die Sicherung um 01:30 fertig war, sich also nicht mit der David-Datenbereinigung (03:00) überschneidet.

    Hat jemand von euch eine Idee, wo wir noch suchen könnten? Irgendein anderes LOG, eine andere Überwachungs-Methode? Blöd ist halt, dass wir nicht einmal z. B. den Status des SL per Monitoring überwachen können, denn der Dienst läuft ja (er macht nur nix). Ich würde vermutlich testweise mal die Art des Backups ändern, aber das wäre schon ziemlich unschön, da "Sonderlösung".

    Bin wie immer für jeden Tipp dankbar! :)

    Jup, das ist auch die offizielle Antwort von Tobit: Chromium Haken da, dann klappt's auch mit dem PDF. Ohne nicht.

    Der betroffene Kunde ist einer der (bei uns) wenigen, der mit Rollout 333 Darstellungsprobleme hat, daher hatten wir zur Deaktivierung von Chromium geraten. Ist dann halt blöd, wenn ausgerechnet dieser Kunde auch einer der wenigen ist, die regelmäßig das PDF-Speichern benutzen. ;)

    OK, die 32/64-bit-Theorie ist vom Tisch: Wenn wir auf einem unserer Rechner den Client komplett entfernen und dann die 64-bit-Version neu installieren, ist das PDF-Speichern nach wie vor vorhanden (und funktioniert auch).

    Ich hab's mal an Tobit gemeldet.

    Ulkig - bei einem Kunden ist seit Rollout 333 im Editor die Option "Speichern unter..." -> "PDF" verschwunden. Es werden ihm nur noch .eml und .html als Möglichkeiten angezeigt, PDF ist komplett weg - und das auf allen Clients der betroffenen Installation (auch auf dem Server)

    Build 3328 incl. Hotfix 332802 sind installiert, die Clients auf aktuellem Stand.

    Kann das jemand von euch bestätigen? Bei uns intern ist die Option nach wie vor vorhanden.

    EDIT: Es scheint an der Edition zu hängen - bei 32 bit ist die Auswahl vorhanden, bei 64 bit nicht. Aber der Kunde ist sehr wahrscheinlich schon lange auf der 64-bit-Schiene, da wir dort zu Jahresbeginn alles neu installiert haben. Also gab's die Option bis vor einiger Zeit auch dort...

    also bei uns hat jeder eine eigene Vorlage.

    Bei mir klappt es, bei dem anderen Client nicht.

    Und wie sehen die Vorlagen "unter der Haube" so aus? Handgeklöppeltes HTML, oder durfte der David-Editor sich austoben? ;)

    HTML-Interpretation ist ja keine exakte Wissenschaft - je nach Engine erscheint der Output unterschiedlich. Wenn ihr individuelle Vorlagen benutzt und es in Sachen Darstellung bei den Usern Unterschiede gibt, würde ich (auch) dort einmal einen Blick drauf werfen. Tobit bastelt momentan viel, allerdings ist das in meinen Augen eben auch nötig (bzw. lange überfällig), da der Internet Explorer ja nun ziemlich konkret in Rente geht...

    Ich schreibe das deshalb, weil wir inzwischen fast alle Kunden mit "sauberen" (sprich: händisch erstellten) Vorlagen versorgt haben und bislang niemand Probleme mit dem aktuellen Rollout meldete. Auch bei uns intern ist nichts aufgefallen, obwohl wir zumindest eine Zeitlang sogar ohne den Hotfix gearbeitet haben.

    Wenn ich das korrekt erinnere, werden ferner seit einiger Zeit die Archiv-Einträge nicht mehr auf Dateisystem-Ebene verschoben, wenn man sie in den untergeordneten Papierkorb legt! Es erfolgt lediglich ein entsprechender Verweis in der Datenbank.

    Ich bin da neulich selbst drauf hereingefallen: Kunde macht "Großaufräumen" in seinem Posteingang, lässt nur 20 Einträge stehen, aber im Dateisystem liegen trotz Purge-Lauf 10000e Dateien. Er hatte halt die Daten in seinen Papierkorb geschoben. Erst nach dem Leeren und manueller Bereinigung über den SL war das Archiv "IN" sauber.

    Beim Unverteilt könnte das ähnlich laufen. Die Verweise gehen dann vermutlich an den persönlichen Papierkorb des Users, der gelöscht hat.