Posts by nordtech

    Das mit der Reihenfolge von Regel-Abarbeitungen und Bedingungen ist hier ein beliebtes Thema. :)

    Mein letzter Stand ist der, dass auch nach dem Greifen der ersten Bedingung die Nachricht noch unangetastet bleibt, eben damit weitere Bedingungen abgefragt werden können. Leg mal zusätzlich zur Lösch-Regel folgende an:

    WENN Absender (bzw. Verteilkennung) = "MAILER-DAEMON@smtp.strato.de" DANN verschiebe in Archiv "Mailbounces"

    Das sollte nach meinem Empfinden funktionieren, weil David die Nachricht vor dem Löschen noch liegen lässt, bis alle Regeln abgearbeitet wurden. Am besten, ihr probiert's mal aus

    Auch hier wären ein paar mehr Infos hilfreich. Versendet ihr direkt, oder per Provider-Postfächern? Wenn letzteres, über einen Smarthost und für alle User gleich oder gibt es Unterschiede bzgl. Versand bei den Usern?

    Generell ist bei Sende-Problemen immer ein passendes Log des Postman nützlich, da sieht man meist recht genau, was dem Provider oder dem empfangenden Server nicht gefällt. Die Meldung im Ausgangsprotokoll (David Administrator) kann auch schon einen Hinweis geben.

    Nur zur allgemeinen Info: Wir haben inzwischen den Verdacht, dass das Problem hauptsächlich auf Geräten auftritt, die den Advanced VPN-Client von Lancom (NCP IPSec) einsetzen. Testweise Umstellung eines kleinen Kunden auf WireGuard mit einer aktuellen FritzBox ergab, dass keine "Bockigkeiten" bei der Anmeldung in Team mehr gemeldet wurden.

    Blöd halt, dass mutmaßlich keiner der beiden Beteiligten (Tobit/Lancom) die Schuld bei sich suchen wird, sondern auf der jeweils anderen Seite. Und, um das nochmal zu betonen, mit den alten David-Clients ist die Verbindung auch via Lancom-VPN sehr schön stabil.

    Wir werden das jetzt mal weiter beobachten und, sofern sich der Verdacht bestätigt, einen neuen Support-Fall incl. Logs und Co. aufmachen. Vielleicht kommt ja doch was dabei heraus.

    Wo denn rum geschickt? An alle Nutzer /admins oder an Partner?!

    Gute Frage. Und ich bin kein Anwalt, aber: Bei der derzeitigen Kommunikations-Strategie, dass wichtige Sachen mal nur im proprietären Chat und mal nur dem im David-Admin zugewiesenen Administrator-User zugestellt werden, wäre das gleich die erste Stelle, an der eine mögliche Unwirksamkeit lauert. Ich muss allerdings gleichzeitig gestehen, mich nicht im Detail durch die Lizenzbedingungen gewühlt zu haben. Vielleicht steht da seit Jahren eine passende Klausel drin.

    Im Zweifel geht's halt darum: Würde wirklich jemand nach dem Abbestellen von Sitecare klagen wollen? Für ein Produkt, dass bei kleinen Installationen nur ein paar tausend Euro kostet? Prozesse können schnell kostspielig werden.

    Trotzdem ein spannendes Thema. Ich bin versucht, bei einem Kunden testweise Sitecare zu kündigen und zu schauen, was passiert. Kandidaten dafür gibt es, denn die Anfragen bzgl. Umstellung auf M365 mehren sich gerade mal wieder. :-/

    Da wären ein paar Details hilfreich, z. B. ob ihr per Provider-Postfach oder direkt sendet. Bekommt ihr eine E-Mail an den Absender zurück, in der die Fehlermeldung enthalten ist? Und sonst steht da nichts?

    Schau mal im Log des Postman nach, welche Meldungen der empfangende Server (Provider oder Zielsystem) noch so von sich gibt. Oft wird zumindest die verwendete Liste oder auch ein Link mitgeteilt, über den man Einzelheiten erfahren kann.

    Andere Programme / Protokolle sind da toleranter, weswegen sie auch über richtig grottige VPN Verbindungen noch sauber laufen. Deine Beispiele SQL und SMB sind perfekte Beispiele dafür selbst mit richtig grottigen VPNs noch gut klar zu kommen.

    Da habe ich bei SQL-Servern aber auch schon andere Erfahrungen gemacht. Manche verhalten sich sogar im LAN geradezu "divenhaft".

    Wir haben die VPN-Verbindung auf Herz und Nieren geprüft, die läuft absoult stabil. Keine Paketverluste im Dauertest, super Latenzen. Es handelt sich um einen Glasfaser-Anschluss mit Gigabit Up- und Downlink; die meisten Clients verfügen im HomeOffice ebenfalls über Glasfaser. Der Lancom-Support sagt anhand der Logs, das "alles optimal" funktioniert, und abgesehen vom Team-Client fühlt es sich auch so an.

    ich würde die Probleme dann doch im VPN selbst suchen

    Haben wir, allerdings ohne Ergebnis. Wie erwähnt läuft der Betrieb aller anderen Programme stabil und reibungslos, incl. SQL-Zugriff der Warenwirtschaft, SMB-Freigeben etc. Die Verbindung wurde bereits früher für den Zugriff auf den Teminal Server verwendet und lief mindestens 5 Jahre ohne Mucken. Und, am wichtigsten, sowohl Classic Client als auch "Modern Client" funktionieren ebenfalls problemlos.

    Es kann doch aber grundsätzlich nicht am VPN liegen, wenn man im Starfenster des Team-Client mit SERVERNAME ans Ziel kommt und beim nächsten Mal plötzlich nur noch mit SERVERNAME.LOKALEDOMAIN.LOCAL - ein PING auf beide Adressen funktioniert durchgehend und reproduzierbar zuverlässig. Nochmal im Detail: Ich beende den Team-Client, der mit Verbindung zu SERVERNAME brav funktionierte, starte ihn dann neu (OHNE dass sich an der VPN-Verbindung irgendwas ändert) und plötzlich mag Team SERVERNAME nicht mehr, obwohl er bis eben über diese Verbindung kommuniziert hat.

    wenn man im DNS des internen Netzes einen Eintrag für den externen Namen eines sowohl intern, als auch extern verfügbaren David Servers mit der internen IP einrichtet müssen sich die Leute generell nur noch einen Servernamen merken.

    Bei dieser Konstellation haben wir bei mehreren Kunden reprouzierbar das Phänomen, dass sich der Client nach längerem Nicht-Benutzen weghängt. Das Fenster wird "blass", der Mauszeiger zum Kringel, und man muss 30 Sekunden warten, bis sich wieder etwas tut. Dieses Problem wurde hier im Forum immer wieder mal in Einzelfällen berichtet, und Tobit hat es nie in den Griff bekommen. Ebenfalls so eine "Kleinigkeit", die in der Praxis tödlich nerven kann. Man hat jemanden am Telefon, sagt: "Warte, ich schau schnell im Kalender nach" - und dann kommt der Kringel.

    Na gut, wir machen mal einen Fall bei Tobit auf, aber es wird wohl auf ein Downgrade hinauslaufen.

    Moin zusammen,

    wir haben bei einem Kunden über den Jahreswechsel von Terminal-Server-Betrieb auf direkte Verbindung der Notbeook-Clients umgestellt. Und weil eh jedes Gerät einmal angepasst werden musste, dachten wir: Hey, schmeißen wir auch gleich die alten David-Clients raus und installieren den Team-Client. Alles schön neu [tm].

    Großer Fehler, offenbar. Folgendes Problem lässt sich reproduzieren: User wählt sich ein, verbindet sich zum David-Server. Oft kommt das Fenster, in dem man manuell eine Serveradresse eintragen soll - die Suche funktioniert über VPN nicht. Das haben wir den Usern mitgeteilt, klappt. Jedoch: Beendet man den Team-Client (komplett, incl. Notifier) und startet ihn neu, kommt unter der Angabe des gleichen Servernamens plötzlich keine Verbindung mehr zustande. Man darf dann experimentieren: Mal klappt SERVER, mal nur FQDN (SERVER.KUNDE.NETZ), dann wieder nur die IP-Adresse, und oft muss man zusätzlich noch Usernamen und Kennwort eintragen. Irgendwann geht es irgendwie, aber die User nervt das verständlicherweise mächtig.

    Mit dem alten "Modern Client" trat das Problem nicht auf. Da konnte man auch noch die Anmeldedaten speichern, was die Sache zumindest vereinfacht hätte, aber Team merkt sich ja schlichtweg gar nichts mehr.

    Die Clients sind alle Mitglied der Domäne, VPN läuft stabil und performant, DNS werkelt einwandfrei. Wir können übers VPN alle Netzwerk-Ressourcen verwenden, sowohl im Windows Explorer als auch z. B. in der Warenwirtschaft, die auf einen SQL-Server im LAN zugreift. Nur der Team-Client will nicht. Wir hatten schon die Idee, den David ins WAN direkt zu öffnen, aber a) ist das sicherheitstechnisch heikel und b) haben wir bei einem anderen Kunden ein verwandtes Problem, denn der muss je nach LAN oder VPN ebenfalls immer händisch den Servernamen wechseln, weil der Anschluss eine dynamsiche IP hat (david.kunde.de vs. server.internesnetz.local). Das ist den Usern kaum zu vermitteln.

    Hat jemand von euch Praxiserfahrung in dieser Richtung mit dem Team-Client? Ich hatte im Hinterkopf, dass der bzgl. Remote- oder generell "dünnen" Verbindungen optimiert sei, und im täglichen LAN-Betrieb kann man mit dem Teil inzwischen eigentlich auch ganz gut arbeiten. Aber dass der Kunde von obigem Verhalten maximal genervt ist, kann ich total verstehen.

    "Witzig" ist in diesem Zusammenhang, dass wir als worst-case-workaround angeboten haben, den alten Client wieder in Betrieb zu nehmen. Da der Kunde im Zuge der RDS-Server-Abschaffung aber schon für alle Clients M365 erworben hat, steht nun natürlich eher der vorgezogene Umstieg auf Exchange Online im Raum. Klassischer Fall von Knieschuss. :(

    Also, ich bin für alle Ideen dankbar. Schönes Wochenende schonmal euch allen!

    schau mal ins kleindruckte:

    **Die Bestandsprovision gilt für laufende Lizenzumsätze mit aktuellen Produktversionen und Software-Diensten, die von Tobit.Software berechnet werden (PRO-Gebühren, Verbindungen, Additive Dienste, Applications (chayns-basierende Produkte, auch Sidekick...)), User Lizenzen, Backline Services (Team/David).

    Eben. SiteCare sehe ich da nicht.

    Sinkt oder stagniert der Umsatz 3 Jahre in Folge, kann die Bestandsprovision auf den Mitgliedsbeitrag gedeckelt werden.

    Ja, das ist noch so ein Klops (ich hatte mich nicht getraut, den zu zitieren). Das dürfte wohl auf so ziemlich jeden Fachhändler zutreffen, denn die Kunden migrieren von David weg, nicht zu David hin...

    Umsatz Provisionen kommen wohl wieder

    Ich lese da nichts von Provisionen auf Sitecare-Umsätze. Bleiben also nur Backline Services wie die MIS - die empfehlen wir auch fleißig, weil sie wirklich gut sind. Viele Kunden halten sie aber für zu teuer und bilden die Funktion z. B. in der Firewall ab.

    Aufgefallen ist mir eher, dass die NFR-Version offenbar kostenpflichtig wird - ZUSÄTZLICH zum jährlichen Partnerbeitrag. Bislang war die enthalten. Oder lese ich die Tabelle falsch?

    Moin zusammen,

    und täglich grüßt das Murmeltier. Ich habe mal wieder das Thema rechtssichere E-Mail-Archivierung auf dem Tisch. Und dazu auch schon die diversen existierenden Threads gelesen, insbesondere diesen hier, der ziemlich genau beschreibt, was wir wollen. ABER mit Abwandlung: In der Cloud!

    Konkret möchten wir 2025 verstärkt in den Vetrieb von EL mailarchive einsteigen, was letztlich nichts anderes ist, als ein Mailstore-System, das von einem Dienstleister betrieben wird. Dabei entfällt für den Endanwender natürlich die on-premise-Hardware, und insbesondere unsere M365-Kunden fragen eine solche Lösung explizit an.

    Die Anbindung an M365 ist ziemlich simpel. Und man sollte ja meinen, dass bei "Standard-Protokollen" auch nicht viel schief gehen kann - zumal unsere David-Kunden allesamt per Provider senden und empfangen (POP/SMTP über Provider-Postfächer).

    Eingehend ist die Sache denn auch echt einfach umzusetzen. Wir lassen im David via POP ankommende Mails für 30 Tage beim Provider liegen und setzen die Mailstore-Konfiguration über eine IMAP-Abfrage parallel auf das Postfach an, um die Archivierung durchzuführen. Klappt super und sauber, ohne dass sich die beiden Instanzen in die Quere kommen - und der User kann im David löschen wie und was er will, er hat keine Chance, Mails vor der Archivierung zu entfernen oder zu manipulieren.

    Dumm ist halt, dass es ausgehend so gar nicht klappt. On-premise lief das bei Mailstore über einen Proxy, der die SMTP-Kommunikation mitgeschnitten und archiviert hat. Aber a) der Proxy ist abgekündigt (s.o.) und b) gibt's diese Möglichkeit bei der Cloud-Variante nicht. So schickt David also Nachrichten raus, die nicht im Archiv landen. Beim lokalen Mailstore hätte man nun noch etwas mit dem Mail Access Server basteln können, der via IMAP die User-Ausgänge abfischt, aber da die Kunden wie gesagt keinen "echten" (und somit auch keinen von extern erreichbaren) Mailserver betreiben, fällt diese Option weg.

    Ich grüble nun, ob es eine Möglichkeit gibt, David beizubringen, ausgehende Mails grundsätzlich in Kopie an ein Archiv-Postfach beim Provider zu senden. Also eine Art erzwungenes CC. Darüber könnte man ja wieder einen passenden Sammeldienst konfigurieren. Aber über die Sende-Methoden im David Admin komme ich an der Stelle nicht weiter.

    Hat jemand von euch eine Idee, wie man das Problem angehen kann? Oder evtl. schon eine cloudbasierte Lösung im Einsatz? Und bitte keine Grundsatzdiskussion zum Thema "Cloud" - kann man so oder so finden, das ist schon klar, aber wie oben beschrieben: Die Endkunden fragen eine solche Lösung explizit an, da viele keine Lust darauf haben, extra einen lokalen Server als Datengrab anzuschaffen.

    Bei sehr kleinen Installationen haben wir bisher oft z. B. auf die eigenen Archivierungs-Lösungen von Strato & Co. verwiesen, das rennt auch ziemlich gut, aber bei einer größeren Anzahl von Usern wird die Sache schnell unübersichtlich. Und viel Speicher ist da auch nicht bei.

    Also, falls jemand eine Idee hat, würde ich mich freuen - ganz davon unabhängig aber euch allen eine angenehme und Downtime-freie Weihnachtszeit! :)

    hatten wir immer auch Kunden, die sich Sitecare einfach nicht leisten konnte und auch Kunden - da stehe ich hinter - wo neue Funktionen einfach überhaupt nicht benötigt wurden.

    Ja, OK, das hätte ich vor 10-15 Jahren so noch unterschrieben, aber inzwischen zeigt sich (nicht nur) beim Thema E-Mail, dass Software technisch nicht auf einem Stand verharren KANN - Ein Beispiel war vor einiger Zeit die Abschaltung von TLS 1.0 bei Mail-Providern. Da tut sich viel bzw. immer mehr. Einfach updatelos rennen lassen kann man ein System auch heute noch bequem, wenn es komplett offline bleibt. Ist bei einem E-Mail-Server halt schwierig. ;)

    Ob Tobit für die doch relativ üppige Sitecare-Gebühr genug an Gegenwert bietet (mal abgesehen von Sicherheits- und Protokoll-Fixes), steht natürlich auf einem anderen Blatt und kann durchaus diskutiert werden.

    Wir nutzen den Administrator aber sehr umfangreich zum Versenden von "internen" Systemmails. Ich habe noch nicht darüber nachgedacht, ob Relaying dann überhaupt noch funktioniert.

    Relaying ist vom Admin-User unabhängig, das klappt auch so. Den User benutzen wir eigentlich nur, um bequem direkt auf dem Server den David-Client verwenden zu können. Tobit hat schon Recht, das kann man natürlich auch mit einem "echten" (= produktiv verwendeten) Benutzer tun, der über entsprechende Privilegien verfügt. Aber dafür müsste der Fachhändler das Passwort des Benutzers wissen, und generell ist es natürlich schöner, wenn die Technik mit einem eigenen Account arbeitet.

    Ohne so einen Admin-User fehlt einem halt der Client, aber im David Administrator kann man wie gewohnt alles einstellen (incl. Relays).

    Kann man eigentlich unnötige und bezahlte Lizenzen aus einem anderen Kunden in einen anderen übernehmen?

    Wenn die Lizenzen bereits einem spezifischen Kunden (=Site.ID) zugeordnet sind, AFAIK nein.

    Man kann dagegen argumentieren, dass diese Form der Unterlizenzierung von Tobit jahrzehntelang toleriert wurde. IANAL, aber im Zivilrecht gibt es so etwas wie ein "Gewohnheitsrecht".

    ZUMINDEST aber hätte Tobit den Fachhandel auf die Umstellung der Lizenzierung und die damit verbundenen eventuellen Probleme mit etwas Vorlauf (!) hinweisen können. Die Kommunikation zum Fachhandel jedoch ist seit Jahren bescheiden, was bei einem Unternehmen, das Kommunikationslösungen vertreibt, nicht einer gewissen Ironie entbehrt.

    Wir haben die betroffenen Endkunden angeschrieben und den Sachverhalt erklärt, incl. der Tatsache, dass der Admin eigentlich keine Lizenz benötigt, uns damit aber die Wartung erheblich vereinfacht wird. Die meisten waren zum Glück so freundlich und haben quasi "für uns" eine zusätzliche User-Lizenz erworben. Dass für einen Wartungs-Account zukünftig Sitecare fällig wird, ist trotzdem eher so "meh".

    Ist doch OK dafür bekommen wir ja Provision ;) Ach ne nicht mehr....

    Das wird hier tatsächlich immer mehr zum Thema. Die Provisionen bei M365 sind absolut lachhaft, und trotzdem haben wir darüber 2024 voraussichtlich mehr verdient als mit David. An Tobit festzuhalten, wird betriebswirtschaftlich gesehen zunehmend schwierig. Neukundengeschäft ist quasi nicht existent, somit gibt's außer bei Lizenzerweiterungen auch keine Einnahmen. Und trotzdem darf man brav jährlich die Partnergebühr abdrücken.

    Ohne die Details zu kennen würde ich sagen: Erstmal manuell aufräumen. Schau dir im Client an, welche Archive wirklich aktiv benutzt werden und welche nur als Dummy oder mit alten Daten herumliegen. Bei letzteren notierst du die User-ID (Rechtsklick auf den User-Ordner, Eigenschaften -> 1x auf das Bildchen klicken, um den Dateisystem-Pfad anzeigen zu lassen) und löscht die betreffenden User im David-Admin raus. Sicherheitsalber könntest du die Archive selbst erst einmal liegen lassen (wird beim Löschen des Users abgefragt). Oder, wenn die leer sind, gleich entfernen, je nachdem.

    Stell dann (oder besser: vorher) sicher, dass im David-Admin unter System -> Konfigurieren -> Optionen -> "Neue Benutzer automatisch anlegen (Autovalidation)" KEIN Haken gesetzt ist. Dann abwarten und horchen, ob User zu schimpfen anfangen, weil sie nicht mehr in den David kommen. ;) Ist das der Fall, hast du dich bei den IDs verhaspelt.

    FALLS pro User jeweils mehrere Archiv-Strukturen befüllt waren, bliebe last not least noch übrig, die alten Einträge in die aktiv genutzten Archive zu verschieben. Anschließend die nun leeren User-Archive rausputzen, und fertig.

    Kommt natürlich auf eure Installation-Größe an. Bei 10 Usern kann man das wie beschrieben mal fix machen, bei 250 artet das ggf. in Arbeit aus.

    Für Server 2025 freigegeben scheint David jedenfalls zu sein, gemäß https://david.tobit.software/leistungs%C3%BCbersicht:

    "Server für Windows Server 2012 (R2), Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025"

    Wir haben diese Konstellation bisher noch nicht eingerichtet, aber ich vermute da auch eher ein grundsätzliches Problem. Wie schaut's denn mit DNS aus, wird der Servername vom Client korrekt aufgelöst? Was passiert, wenn ihr testweise mal die lokale IP des Servers nehmt?

    Oh Mann, ich brauche echt Wochenende. Es war sogar noch blöder. In den Einstellungen "Andere Taskleistensymbole" gibt es über der App-Liste einen Schalter "Menü 'ausgeblendetes Symbol'" ein/aus. Der stand auf "aus". Ich hab' die die Option noch nie bewusst wahrgenommen und vermutlich irgendwann mal versehentlich auf "aus" gesetzt.

    Das Tückische dabei: Solange alle vermuteten Icons dort auftauchen (bei mir ca. 10 Stück dauerhaft eingeblendet), fällt das ja nicht auf. Erst, wenn ein neues dazu kommen müsste und das Icon komplett versteckt wird, wundert man sich.

    Boah ey. Eventuell war das eine unterbewusste Trotz-Handlung, weil ich die Win10-Option ("Immer alle Symbole im Benachrichtigungsbereich anzeigen") gerne wieder haben möchte. Es sträubt sich in mir offenbar alles gegen Win11. ;)

    Also - Tobit komplett unschuldig. Und MS nur insofern, als dass sie (imho) in Win11 die Taskleiste "versaut" haben.

    Problem ist gelöst. Windows-Einstellungen -> Personalisierung -> Taskleiste -> "Andere Taskleistensymbole" -> Team einblenden.

    Warum ich da nicht selbst drauf gekommen bin? Weil Windows 11 in seiner unerforschbaren Weisheit den kleinen Pfeil zum Einblenden weiterer Symbolleisten-Einträge NICHT angezeigt hat. Man musste also denken, dass alle vorhandenen Symbole angezeigt werden - war aber nicht so. Neben Team ist nun plötzlich auch das PassKey-Icon wieder aufgetaucht.

    Manchmal ist's eben doch einfach. Immer dran denken, dass unter Windows auch das passiert, was eigentlich nicht passieren kann/darf/soll. ;)