Bei uns kommen da auch keine KI Avatare. Wir haben die KI Funktionen allerdings auch nicht nur einzelnen Nutzern verweigert, sondern Systemweit abgeschaltet
Ist bei uns auch:
Bei den Usern ist "Sidekick AI Services erlauben" ebenfalls leer. Die Avatare kommen trotzdem:
Per Kontextmenü und auch über die Eigenschaften geht glaube ich gar nicht mehr.
Abhilfe: Einstellungen -> Ansicht -> Vorschau -> "Tabs mit erweiterten Eintragsinformationen anzeigen" aktivieren, dann erscheint im Vorschaubereich(!) ein neuer Reiter "HTML-Inhalt". Dort kann man direkt editieren, und beim Wechsel des Reiters (oder Drücken von Strg + S) wird gespeichert.
Ich finde das sehr holperig und unintuitiv, aber vermutlich möchte Tobit nicht, dass man im Quelltext herumwühlt. Was wiederum seltsam wäre, denn das ist der einzige Weg, wirklich saubere Vorlagen hinzubekommen. Naja, immerhin existiert obiger Workaround.
also scheinbar wird bei uns über smarthost geschickt. dann brauchen wir das nicht einstellen?!
So verstehe ich das, ja. Geh doch versuchsweise mal auf https://www.mail-tester.com/ und schick eine Nachricht an die dort generierte Zufalls-Adresse. Dann siehst du direkt, wie die Nachricht beim Empfänger ankommt und ob dieser ggf. daran noch etwas zu meckern hat. 
Wir haben die Lösung gefunden, es scheint sich nicht um ein generelles Problem mit dem Rollout zu handeln, sondern um die lokale Einstellung eines spezifischen Clients. Dort war unter Editor -> MAPI die Einstellung auf "individuell" gesetzt. Nach Zurückstellen auf "Standard" tritt das Phänomen nicht mehr auf.
Warum es bei diesem einen Client und erst mit dem Einspielen von Rollout 523 zum Fehler kam, konnte nicht nachvollzogen werden. Aber vielleicht hilft die Info, falls mal jemand anderes darüber stolpert.
Hört sich so an, als wenn der Provider das fragliche Feld nicht mehr übergibt oder sich dieses geändert hat - kommt durchaus mal vor.
Wenn es aber nur diesen einen User betrifft, handelt es sich ggf. um einen Bug auf Seiten des Providers. Entweder den Eintrag im Auszuwertenden Adressfeld löschen, oder wie Wizzard sagte: In die Details einer eingegangenen Mail schauen und prüfen, welches Headerfeld wirklich ankommt.
Wenn schon im Eingangsprotokoll das "falsche" Zielarchiv angezeigt wird, dann würde ich zuerst mal direkt im David Admin schauen, unter "Verteilung" -> Verteilregeln und Verteilvorgaben.
Ansonsten testweise das Zielarchiv in den Eigenschaften des Kontos überschreiben mit einem eigens angelegten Test (z.B. Ziel = server\testarchiv) und mal schauen, ob das korrekt gezogen wird.
Nein, ONS32 von Opti-Net ( https://opti-net.de/ )
Das läuft in Zusammenspiel mit David eigentlich recht gut. Zumindest hebt der Support nicht gleich kreischend die Hände, wenn man erwähnt, dass ein anderer Mail-Client als Outlook zum Einsatz kommt.
Gibt es das nicht mehr? Hatten wir des Öfteren unter Hyper-V im Einsatz
Hmm. Bei Primux selbst finde ich keinen Hinweis mehr, und auf der von dir verlinkten Seite ist als letzte unterstützte Server-Version 2016 angegeben. Das scheint mir alle nicht wirklich weiter supportet zu sein, ebenso wie die CAPI-Lösungen von Shamrock Software.
Aber so wie's jetzt rennt, rennt's ja. Zumindest so lange ich noch eine FritzBox mit ISDN habe und danach sehen wir weiter: Entweder Cloud-Telefonanlage oder Rente. 
Ich hol den Thread mal wieder hervor, um die abschließende "Lösung" zu präsentieren. Die besteht tatsächlich aus einem PrimuX-USB-ISDN-Adapter(!) von Gerdes, der nun wieder am zum Glück noch vorhandenen S0-Anschluss der FritzBox hängt.
Das ganze Thema VoIP habe ich mit Fritz und David nicht zum Laufen bekommen. Die Wählhilfe mit Verbinden zum Tischtelefon komplett gar nicht, so dass ich dann dachte: Na gut, gehste halt aufs VoIP im Client und telefonierst da über Headset. Das klappte auch im Prinzip, aber immer wieder mal baute David einfach keine Verbindung auf - das Headset blieb stumm, es passierte schlichtweg nix. Sowohl beim Hinterlegen der Daten direkt im Client als auch bei "Einstellungen vom David-Server laden". Besonders oft hatte ich das, wenn das Notebook aus dem Standby aufwachte.
Kurzum, die gesamte Konstellation lief nicht zufriedenstellend, und da man vorher nicht sehen konnte, ob David sich per VoIP gerade korrekt unterhalten möchte, war der Nerv-Faktor hoch.
Mit dem "klassischen" ISDN-Port ist wieder alles schick und läuft stabil und problemlos, und das, obwohl wir ja eine Frickel-Lösung gewählt haben. Denn der USB-Adapter kann nicht ohne weiteres in die Hyper-V-VM durchgereicht werden. Daher hing der zunächst an einem SEH UTN USB-LAN-Server, was auch gut funktionierte. Aber in so einer kleinen Umgebung noch ein extra Kästchen im Netzwerk schien mir komisch, daher suchte ich nach passender Software. Ganz oben bei Google bekommt man immer wieder (unter verschiedenen URLs) eine Lösung aufgedrückt, die es nur im Abo gibt. War keine Option. Letztlich wurde es "USB redirector" von incentivespro.com - kost' US$75 für 2 Devices und rennt ebenfalls klaglos. Ein Dienst auf dem Hyper-V-Host, einer in der VM, Verbindung vollautomatisch.
Dies also nur als meine 2 Cent, falls später jemand mal vor ähnlichen Fragestellungen steht.
Moin zusammen!
Mal Frage in die Runde: Ein Kunde nutzt David im Zusammenspiel mit einer Warenwirtschaft - letztere sendet eine Mail mit PDF-Anhang, allerdings nicht direkt, sondern es geht das David-Editor-Fenster auf, so dass noch zusätzliche Texte etc. eingefügt werden können. Das Abschicken passiert dann manuell.
Der Kunde berichtet, dass nach dem Einspielen des aktuellen Rollouts als Empfänger plötzlich nicht mehr "john.doe@unternehmen.invalid" eingetragen wird, sondern "SMTP:john.doe@unternehmen.invalid" - drückt man ohne Änderung auf "Senden" bleibt der Auftrag dann hängen, weil David das vorangestellte SMTP nicht deuten kann. Der Hersteller der Warenwirtschaft beteuert, dass von deren Seite nichts geändert wurde (ist auch plausibel).
"Leider" konnte ich das Phänomen in unserer Installation nicht reproduzieren. Auch auf anderen Clients des Kunden wurde es bislang nicht gemeldet, da kann's allerdings sein, dass der Client nach Update noch nicht überall neu gestartet wurde.
Bevor ich jetzt einen Fall bei Tobit aufmache, mal die Frage, ob es sich um einen Einzelfall oder ein bekanntes Phänomen handelt. Habt ihr ähnliches beobachtet?
Moin zusammen,
Rollout 523 ist da, Release Notes wie üblich unter https://david.tobit.com/ReleaseNotes
Was mir als erstes auffällt und schon wieder ein gewisses "Kunden fragen an/sind genervt"-Potential hat: "Neues Eingabefeld für Chat-Nachrichten und SideKick-Anfragen - Ein neues Eingabefeld mittig in der Titelleiste des Client-Hauptfensters ersetzt die bisherigen Chat-Elemente in den Symbolleisten. Sind die KI-Funktionen im David.Administrator aktiviert, ist es außerdem möglich, über das neue Eingabefeld auch KI-Anfragen zu stellen. Dazu stehen dann hier neben den üblichen Chat-Partnern sowohl die von SideKick bereitgestellten als auch möglicherweise individuell eingerichtete intelligent Agents zur Verfügung."
Sieht so aus:
Problematisch finde ich dabei, dass die KI-Avatare offenbar auch dann erscheinen, wenn der User das Recht "Sidekick AI Services erlauben" NICHT hat. Im drop down werden zuerst die KI-Avatare gelistet, dann ganz unten die Benutzer in der eigenen David-Umgebung.
Wie die Funktion den Chat ersetzen soll, erschließt sich mir derzeit noch nicht ganz: Nach dem Absenden einer Nachricht passiert irgendwie gar nichts - egal, ob an einen KI-Agent oder einen internen Benutzer. Fehler kommt auch keiner.
Welche EInstellung ist es denn? Grad blind scheinbar?!.
Einstellungen -> Editor -> Optionen -> ganz unten "Texte generell formatiert einfügen", diese Option ist erst neulich (mit einem der letzten Rollouts) ergänzt worden.
Ich persönlich finde den Default "ohne Formatierung einfügen" sehr angenehm, aber die Geschmäcker sind verschieden.
Hat jemand eine Idee warum der nicht versendet wird?
Vielleicht ganz trivial: Ist der "Administrator" im David Admin korrekt festgelegt? System -> Rechtsklick -> "Konfigurieren" -> oberstes Feld "David Administrator"?
Gut das wir noch auf 517 sind
Da habe ich keine EAS Probleme bisher.
Das Problem besteht clientseitig in der GMail-App für Android. Einer unserer Kunden ist noch auf Stand Pre-500 und ebenfalls betroffen. Wir intern (aktuelles Rollout, nur iOS-Clients) hingegen nicht.
Es gibt ja auch immer noch im David-Client "Werkzeuge -> Outlook-Import". Ich hab' den allerdings lange nicht benutzt, vor ein paar Jahren war das Tool mal relativ "wählerisch" bzw. hat mitten im Import abgebrochen. Aber einen Versuch ist es ggf, wert.
Ich bin wohl blind. Finde ich nicht, wo stellt man das ein?
Sorry, war aus dem Gedächtnis; ich meine nicht "Ziel", sondern die Spalte "User". Da erscheint bei Nachrichten, die David direkt zuordnen kann, der entsprechende Username. "David Archive" deutet darauf hin, dass kein passender User gefunden wurde, und dann sollte der Eintrag in "Unverteilt" wandern.
Es schaut so aus, dass die Nachrichten unter dem alten Windows User (schon lange nicht mehr im Einsatz, wegen defekten Profil) abgelegt werden und nicht unter dem aktuellen.
Das habe ich nicht verstanden.
Hm, könnte ein Rechte- oder Darstellungsproblem sein. Irgendwelche Regeln, die in Unverteilt verschieben oder automatisch löschen, sind definitiv nicht vorhanden? Auch hier die Verzeichnisrechte beachten - gibt es in david\archive\common eine archive.urt? Entsprechende Probleme, die mit dem neuen Rollout zusammenhängen, sind mir nämlich spontan nicht bekannt.
Schau auch mal im David Admin nach, was im Eingangsprotokoll bei "Ziel" steht, dort sollte für den Unverteilt-Ordner "David Archive" eingetragen sein.
Sofern auf Dateisystemebene aktuelle Einträge existieren, die aber trotz korrekter Rechte auf den Clients nicht angezeigt werden, hilft evtl. ein Neuaufbau der archive.dat. Dazu den Service Layer beenden, von der david\archive\common\archive.dat eine Sicherheitskopie erstellen, und dann mit dem Tool David\Util\Windows\ARCUTIL\arcutil.exe die Datei neu aufbauen lassen (Pfad angeben, Haken setzen bei "ARCHIVE.DAT herstellen"). Anschließend SL neu starten und gucken.
und EAS deshalb nur bei aktivem Sitecare aktivierbar ist
Das Gerücht hält sich harnäckig, stimmt aber nicht.
Wir haben einen Kunden, der schon vor über einem Jahr zu Exchange umziehen wollte, aus Gründen verzögert sich die ganze Aktion aber immer wieder. Sitecare wurde damals gekündigt, die Anbindung der (insges. 18) Mobilgeräte via EAS läuft dennoch unbeeindruckt weiter.
Moin! Mein Team-Client hat mich gerade mal wieder ungewollt ausgeloggt, aber wenn ich auf das User-Icon oben rechts klicke, erscheint im Browser nur eine höchst unvollständige Webseite:
Auf dem Handy via Mobilfunknetz ausprobiert, auch hier z. B. auf https://tobit.team nur eine Seite mit kaputter Grafik, auf der sich beim Klicken von "Anmelden" nix tut.
Könnt ihr das bestätigen? Hat Tobit gerade ein paar Server-Probleme? (18.11.2025 - 14:17 Uhr)
Ah, ich sehe gerade: Cloudflare ist down. https://www.borncity.com/blog/2025/11/1…own-18-11-2025/
Hängt evtl. damit zusammen?
Bzgl. unklarer Sende-Probleme habe ich mir irgendwann mal notiert:
Temp. Verzeichnisse aufräumen gem. KB UND die Rechte auf Verzeichnissen unterhalb von DAVID\APPS prüfen. ALLES muss für SYSTEM (und ggf. Admins) frei sein, ABER der Ordner \David\apps\faxware\out\api zusätzlich für die David-User! Das geht manchmal z. B. beim Clonen verloren.
Du schriebst zwar, dass die Rechte nicht verändert wurden, aber insbes. \David\apps\faxware\out\api zu kontrollieren, schadet ja nicht.
Am Postman selbst scheint es zumindest nicht zu liegen - ich hatte mal den kuriosen Fall, dass der sich nicht an Port 25 bindet, aber gem. Log ist das bei dir ja der Fall.
