Beiträge von nordtech

Bei einem Kunden haben wir das gleiche Problem: SQL-Server läuft, die User haben passende Rechte, in der Auswahl der Teilnehmer werden die Benutzer auch als aktiv angezeigt. Wenn man aber eine Nachricht auf den Weg bringt, geht die einfach ins Nirvana.

In den Ereignissen wird kein Fehler protokolliert, auch in den Windows-Protokollen keine Beschwerden.

Ich hab' schon im SSMS geschaut, da sieht nach meinem Empfinden ebenfalls alles schick aus: Der SL läuft mit dem lokalen Systemkonto, und jenes ist sowohl den David-DBs zugewiesen als auch als sysadmin + public hinterlegt.

Hat noch wer eine Idee?

Hmm, das kann ich mir spontan nicht erklären. Habt ihr in der Systemkonfiguration eure Domain korrekt hinterlegt? Wobei - die vollständigen Absenderadressen müsste David trotzdem korrekt erkennen und zuweisen, wenn ich es richtig weiß.

Aber egal, als Workaround würde ich vorschlagen, dass ihr im Ausgangsarchiv des DSU passende Verteilregeln erstellt: WENN Absender = xyz, DANN verschiebe nach xyz/Ausgang. Nicht elegant, funktioniert aber (machen wir hier mit Sendeaufträgen aus der Warenwirtschaft genau so).

Dass der David System User nicht unter Benutzer auftaucht, ist normal. Es handelt sich um einen internen User, der quasi direkt dem Service Layer "gehört". In dessen Ausgangsbuch erscheinen z. B. Aufträge, die über die Weiterleiten-Funktion des Postman versendet wurden, also ohne einem spezifischen Benutzer zugeordnet zu sein. Denn bei denen weiß David ja nicht, wo sie einzusortieren sind. Wenn man das ändern möchte, kann im Ausgang per Verteilregel eine passende Umleitung angelegt werden.

Die User-ID des David System User ist, wenn ich mich nicht täusche, immer 00000000. Löschen würde ich nicht empfehlen, da wie beschrieben eine Systemfunktion.

Wenn versendete Nachrichten beim DSU im Ausgang landen, ist die Frage, wie genau diese auf den Weg gebracht werden. Verlassen sie ggf. mit einem generischen Absender (info@...) euren David? Falls ja, muss ggf. zusätzlich z. B. mittels einer Include-Datei ein benutzerbezogener Absender ergänzt werden.

Moin zusammen,

ein Kunde beschreibt folgendes Problem mit dem Team-Client auf einem Windows 2019 Terminal Server (RDS): Er erstellt eine Mail oder antwortet auf eine, fügt einen Anhang hinzu und klickt auf "Senden" - und nichts passiert. Eigentlich sollte die Nachricht abgeschickt werden oder noch das Bestätigungs-Fenster erscheinen, aber bei ihm tut sich schlichtweg gar nichts. Der Editor bleibt geöffnet, es kommt keine Meldung, der "Senden"-Button reagiert nicht.

"Natürlich" war das Phänomen in einer Fernwartungs-Sitzung nicht reproduzierbar. Ich glaube aber auch nicht, dass der Kunde sich das ausdenkt.

Rahmenbedingungen:

• Tritt offenbar nur zutage, wenn mit Anhängen gearbeitet wird.
• Der anzufügende Anhang ist lokal auf dem System oder im Netzwerk vorhanden, Leserechte ebenfalls. Es handelt sich um nicht besonders große Daten, z. B. PDF-Dokumente von 2-3 MB.
• Virenscanner spukt nicht rein.
• Das Problem tritt nur bei diesem einen User auf, andere auf dem System sind nicht betroffen. Spezielle David-Rechte, die ihn von anderen Usern unterscheiden, konnte ich aber nicht ausmachen.
• Lt. Aussage des Kunden war das alles mit dem alten David-Client kein Problem, tritt erst seit der Umstellung auf Team auf. Sein Workflow habe sich nicht geändert.

Hat da wer eine Idee, wo man stöbern könnte? Wir haben aus Verzweiflung z. B. mal die Ansichten umgestellt, so dass die Nachricht in eigenem Fenster statt in einem Tab dargestellt wird, aber das brachte erwartungsgemäß nichts. Blöd ist halt, dass der Fehler nicht dauernd auftaucht, manchmal funktioniert es auch einfach.

Bin für jede Anregung (und/oder Praxis-Erfahrungsberichte zum Team-Client in RDS-Umgebungen) dankbar.

Schau mal bei Strato in die DNS-Verwaltung der Subdomain. Was ist da bei AAAA-Record eingetragen?

Bei netstat ist wimre nur die erste Spalte relevant - in der zweiten ist bzgl. 443 auf unserem System auch jede Menge los, z. B. Teamviewer und ServerEye. Das beißt sich aber nicht zwingend mit der Webbox. Hast du auch einen 443 in der ersten Spalte, direkt hinter der lokalen IP?

Dein Problem besteht vermutlich darin, dass Port 443 bereits von einem anderen Programm belegt ist. Öffne mal im Browser https://127.0.0.1 - antwortet da was? Oder per cmd: netstat -ano | find "443" - über die Process ID lässt sich anschließend im Taskmanager heruasfinden, welches Programm dahinter steckt. Es gibt da eine ganze Reihe von Kandidaten, z. B. den Dienst "Routing & RAS", einen IIS usw.

Du kannst entweder das andere Programm vom 443 "verjagen" oder du weist David an, für die Webbox https-Verbindung einen anderen Port zu nutzen, z. B. 8443 -> \\david\apps\webbox\code\webbox.ini um diese Zeile ergänzen: HttpsPort = 8443

Das externe Portforwarding kann unabhängig davon ja weiter laufen, indem du den externen Port 443 an den internen 8443 weiterleitest.

Ergänzung: Die Meldung "Failed to validate DNS-records (AAAA)" deutet darauf hin, dass für die verwendete Subdomain ein AAAA-Record existiert, dieser wird von Let's Encrypt bevorzugt gezogen, dann muss aber natürlich auch IPv6 entsprechend auf den lokalen Server weisen. Ist das nicht der Fall, solltest du den AAAA-Record löschen und so "klassisch" auf den A-Record verweisen.

Was für eine Adresse nutzt du für den David-Zugang? Subdomain mit Dyndns oder fester WAN-IP?

Kann ich bestätigen, die Suche nach "Tobit" oder "Tobit.Team" wirft keine Ergebnisse im Apple AppStore aus. Auch der Link auf die App-Verknüfung läuft ins Leere.

Die App selbst scheint unter iOS aber wie gewohnt zu funktionieren. Das Update auf Version 1.043 ist hier ebenfalls angekommen.

Bei mir kommt das auch bei neuen Mails noch, trotz deaktiviertem "Sidekick Service" im Admin. Allerdings verwende ich auch eine digitale Signatur, und die Option, diese manuell für eine Mail zu deaktivieren wird ja im gleichen Fenster eingeblendet. Liegt das daran? Ich kann's leider gerade nicht testen.

Meinst du die Favoriten- oder die Symbolleiste? In letzterer müsste das per Rechtsklick und das Einblenden von "Volltext- und Internetsuche" funktionieren.

Zitat von AdminDV

Bestätigung beim Senden von Sidekick noch vorhanden ?

Ja. :-/

Wie das mit dem Migrations-Tool aussieht, weiß ich offen gesagt nicht: Standard-Szenario ist, dass der Ziel-David komplett "nackig" vorliegt, also ohne jegliche Konfiguration oder User-Archive. Was mit Einträgen passiert, die bereits existieren, kann ich mangels Erfahrung nicht sagen. Ich würde im Zweifel mal davon ausgehen, dass die überschrieben werden. Generell stoppt das Migrationstool alle aktiven David-Dienste sowohl auf Quell- als auch Zielserver, von daher ist das mit dem "Livebetrieb" so eine Sache.

Ja, das ist quasi das klassische Einsatz-Szenario für das Migrationstool. Sollte klappen, kleinere unkritische Nacharbeiten sind mitunter erforderlich.

Wichtig zu erwähnen: Das Programm ist keine Rakete, schnelle Systeme und Verbindungen sind also sehr hilfreich, wenn es um immerhin 60 Postfächer geht. Falls du, wie bei unseren Kunden oft der Fall, 2-3 "heavy users" mit Unmengen von Archiven hast, kann es auch sinnvoll sein, diese separat per Strongbox-Sicherung oder sogar manuellem Umkopieren (incl. Nachbearbeitung mit arcutil) zu migrieren und im Tobit-Tool auszunehmen.

Sollte die Datenmenge insgesamt eher überschaubar sein, klappt's mit dem Tool in aller Regel ziemlich unkompliziert.

Moin zusammen,

langsam bekomme ich schlechte Laune, wenn es um das Thema KI im Zusammenhang mit Tobit geht... Nicht nur, dass beim Senden von E-Mails die Funktion auch dann angezeigt wird, wenn sie im David Admin deaktiviert wurde, jetzt ist bei mir eben mitten im Beantworten einer Mail ein Chatfenster von "Maya" (offenbar ein KI-Bot) aufgeploppt und preist irgendeine neue KI-Funktion an. Wohlgemerkt, nicht etwa eine Benachrichtigung oben rechts neben dem Chayns-Icon, sondern ein eigenes Fenster, das sich über den Team-Client legt.

War das jetzt ein Ausrutscher, bzw. hat die KI da halluziniert, dass ich mich mit ihr unterhalten möchte, oder kam das bei euch auch schon einmal vor?

Also echt, das ist ja nicht mehr "Anpreisen wie Sauerbier", sondern schon fast Drückerkolonnen-Stil.

OK, danke, ich hab' mich mal getraut, und die neu erstellte archive.dir ist tatsächlich 1 kb kleiner als die alte (jene sichert Arcutil immer automatisch als archive.di_).

Bin gespannt, ob morgen (nach der nächsten nächtlichen Bereinigung) der Spuk nun vorüber ist. Trotzdem seltsam, das alles: Es hat sich bei der Installation wie beschrieben nichts geändert, schon gar nicht im Root-Archiv... Naja.

Moin zusammen,

"aus heiterem Himmel" erhalten wir bei einer Installation die 3x Meldung "Circular ARCHIVE.DIR Entry" im Zuge der nächtlichen Datenbereinigung:

Parent \\server\david\archive\
Child A
RecNo 10

Parent \\server\david\archive\
Child C
RecNo 12

Parent \\server\david\archive\
Child D
RecNo 13

Es gibt einen alten Foren-Eintrag dazu, den offenbar auch früher mal vorhandenen KB-Artikel Q-102.643 (in diesem Beitrag erwähnt) kann ich aber leider nicht mehr finden.

Was mich verwirrt, ist die Anzeige hinter "child" - sollten da nicht nähere Angaben zu den betroffenen Unter-Archiven stehen? Ich hab' mal mit einem Hex-Editor in die archive.dir im Root geschaut, da ist nichts zu finden von A, C oder D...

Das Problem ist auf einem Server 2016 ohne erkennbaren externen Auslöser aufgetreten - keine Abstürze, auch kürzlich keine Windows-Updates oder andere Reboots.

Hat jemand eine Idee? Einfach mal mit arcutil die \\server\david\archive\archive.dir neu aufbauen lassen?

Die beiden genannten Optionen sind definitiv die richtigen, das ist mittlerweile bei unseren Kunden eine "FAQ"

Zitat von riawie

Grundsätzlich werden die Daten für den Reiter SMTP-Header vom David überhaupt nur dann bereitgestellt, wenn auf den Server in der Konfiguration des Grabbing Server die Option Original Nachricht speichern aktiv ist

Das kann ich so nicht bestätigen, bei uns ist diese Option inaktiv, und ich habe den Reiter "SMTP-Header" bei externen E-Mails trotzdem.

Einstellungen -> Ansicht -> Vorschau

"Editor in Vorschaufenster öffnen"

bzw.

"Editor in Vorschaufenster unter Eintragsliste öffnen"

Ach so, und... eine Firewall, die ggf. in TLS-Verbindungen reingrätscht ist nicht zufällig installiert? Da hatte ich mal was bei einem Kunden und einer Sophos (nicht von uns geliefert)... Dort ging der Versand allerdings sporadisch gar nicht oder lief in Fehler.

Spannend... Mittelfristig kann dir diese Einstellung allerdings wieder auf die Füße fallen; die meisten mir bekannten Providern erfordern inzwischen eine TLS-Verbindung. Was passiert denn, wenn du die Option "Erzwingen" verwendest?

EDIT: So wie bei lycra sieht es bei uns im Abschnitt TLS(SSL) auch aus. Als Provider haben wir Strato.