SiteCare kündigen weil nicht alle 14 Tage ein Update kommt?
Uns sind gut getestete Updates mehr wert als agile Entwicklung die alle 14 Tage raushaut was gerade verfügbar ist!
Ansonsten ist SiteCare nicht teurer als beim Wettbewerb und immer noch günstiger als alle jubel Jahre mal den aktuellen Stand in Form eines Upgrades zu kaufen.
Wichtiger als dieser 14 Tage Marketing Quatsch - auf den offenkundig auch einige Tobit Partner abgefahren sind - ist das wenn notwendig auch Sicherheitsupdates kommen und das man im Zweifel zügig nachbessert wenn doch mal beim testen eines Updates etwas durchgerutscht ist.
Ja, auch David hat noch einiges an Potential welches gerne mal gehoben werden könnte, aber das gibt es in jedem Produkt und letztlich muss man sich das Produkt auswählen welches einem am besten zusagt.
Davon unabhängig gehört es heutzutage aber schlicht zur Sorgfaltspflicht im geschäftlichen Einsatz Wartungsverträge für die eingesetzte Software zu haben um sowohl Updates einspielen zu können wenn sie Verfügbar und der Sicherheit zuträglich sind, aber auch um dem Hersteller zu ermöglichen sich um das bereitstellen solcher Updates zu kümmern.
Wesen Kunden die SiteCare kündigen weil zu lange nicht alle 14 Tage Updates kamen sollte sich mal überlegen ob er das Produkt tatsächlich sachgerecht angepriesen und verkauft hat.
Sorry, aber in diesen Chor kann ich nicht mit einstimmen.
Beiträge von riawie
-
-
kann es sein, dass Vorgabe = schwarz ist?
schwarz steht eigentlich immer ganz unten in der Liste:
Mir ist allerdings das Problem noch nicht untergekommen und entsprechend auch keine Lösung dafür bekannt.
-
diese 3 Einstellungen sind für das Verhalten des Navigator Bereichs verantwortlich:
-
Hat schon irgendjemand mal versucht und war sogar erfolgreich dem Smart Client bzw. der Smart Client App am Smartphone eine eigene Vorlage für Mails zu verpassen, oder auch nur herausgefunden wo der seine Vorlage her zieht?
-
Das ist sehr schwer zu ergründen wenn man erst Monate später nach einem Tipp fragt.
Die Ursache wird mit hoher Wahrscheinlichkeit nicht an der David-Client Installation selbst liegen, sondern an anderen Veränderungen auf Euren Systemen. Man hätte also zu dem Zeitpunkt als es erstmalig aufgetreten ist genau gucken sollen was sich kurz vorher auf allen Systemen verändert hat.
Es gab in den letzten mindestens 6 Monaten jeweils mindestens einen Microsoft Patch welcher meist gravierende Auswirkungen auf das Windows Drucksystem hatte. Es kann aber durchaus auch sein das die Ursache in einer gänzlich anderen Komponente bei Euch liegt welche auf alle Arbeitsplätze und sogar den Server zutrifft.
Wenn Dir hier jemand Tipps geben soll wären allerdings mindestens noch Informationen zur Windows Version an den Arbeitsplätzen und am Server sinnvoll, sonst ist das reines im Trüben fischen. -
Unsere Leute mit Notebook arbeiten von unterwegs aus durchgehend mit dem normalen David Client über LTE, DSL zu Haus und WLANs in Hotels oder bei Kunden.
Der Web Access wird hier schon seit Jahren nicht mehr genutzt. -
Wobei so eine Datenbank wirklich sinnvoll wäre.
Da gebe ich Dir definitiv recht und ich hätte da auch schon einen Absender den ich mit genau einer einzigen Dateiendung in die Datenbank eintragen würde.
Aber das sollte halt echt eine separate Datenbank mit genau definiertem Zweck und einzeln festzulegenden Dateiendungen bzw. Typen sein und kein überraschender Seiteneffekt der hier genannten Liste. -
Oder wird aufgrund der Domäne der PostMan komplett übergangen?
genau das
-
Das hat je derartige Auswirkungen gehabt?
Gut das es diese Auswirkungen nicht mehr hat, denn das ist nicht wofür diese Datenbank gedacht ist.
"email/PostMan/Datenbanken/erlaubte Adressen" soll einzig dazu dienen einzelne Adressen einer Domain welche man in "email/PostMan/Datenbanken/Nicht erlaubte Adressen" für eingehende Mails blockiert hat doch zu erlauben Mails zu senden.
Zusätzlich wird für Adressen welche in "email/PostMan/Datenbanken/erlaubte Adressen" eingetragen sind ein eventuelles Greylisting deaktiviert, was notwendig sein kann wenn ein Absender mit Greylisting nicht klar kommt.
Jeglicher Einfluss auf den Virenschutz wäre für diese Datenbank aber weder dokumentiert noch sinnvoll. -
Ich habe festgestellt, daß der Zugriff auf das david-Verzeichnis über die NW-Freigabe auf den Systemem wo das Problem auftritt langsam ist. Will man das david-Verzeichnis öffnen dauert das ca. 4 Sekunden. Bei anderen Systemen geht das sofort. Es macht keinen Unterschied, ob über den Servernamen oder IP (\\Server08\david, \\192.168.0.108\david). Ist man einmal im david-Verzeichnis ist der Wechsel in andere Unterverzeichnisse schnell.
Nun, da hast Du Deine Ursache welche es genauer zu analysieren und zu beheben gilt.
SMB 1.0 ist auf allen Systemen aktiviert.
Wozu ? braucht die da noch wer? David jedendfalls nicht, wobei das mit dem Problem wahrscheinlich kausal im Zusammenhang steht.
-
Das hängt nicht an einem Rollout, sondern ist schlicht ein Problem der jeweiligen Installation.
Schlagt mich nicht, ich hab keinen Link für Euch, aber solche und ähnliche Probleme waren hier immer mal wieder Thema im Forum und sie konnten soweit ich mich dunkel erinnere stets gelöst werden.
Wenn das Folge eines Rollouts gewesen wäre würde ich den Leuten in Ahaus seit dem nicht mehr von der Pelle gerückt sein. Wir haben dieses Problem aber schlicht nicht und hatten es auch nie.
Bzw. wir kennen ähnliches nur bei remote arbeitenden Kollegen wenn deren Netzwerkanbindung schlicht Mist war, die Lösung waren dann andere Netzwerkeinstellungen für den Moment und anschließend beheben der Netzwerkprobleme bei diesen remote arbeitenden Kollegen. -
korrekt
-
Kann man das o.g. Archiv "ehemalige Mitarbeiter" komplett aus dem SQL-Suchindex ausklammern? (z.B. mittels Ini Datei Schalter?)
David Client > Rechte Maustaste auf den Ordner den Du nicht im Index haben möchtest > Eigenschaften > Reiter Dienste > Feld Optionen > Indexerstellung: Haken bei Unterordner ausschließen setzen = der entsprechende Ordner mit allem was drin ist und all seinen Unterordnern wird aus dem Index ausgeschlossen.
Ausgeblendete Ordner werden ebenfalls nicht indexiert:
David Client > Rechte Maustaste auf den Ordner den Du nicht im Index haben möchtest > Eigenschaften > Feld Optionen: Haken bei Ausblenden setzen.
Die Einstellung bei Dienste ist allerdings zum einen offensichtlicher und hat keine Seiteneffekte.
Es kann sein das das ganze erst dann in der Datenbankgröße bemerkbar wird wenn man die Datenbank zurücksetzt und den Volltextindex neu aufbauen lässt:
David Administrator > rechte Maustaste > Status Monitor > Reiter Volltextindex > Datenbank zurücksetzen
PS: "Indexerstellung" als Suchbegriff in der Online Hilfe des David Clients oder Administrators hätte Dir das auch erläutert
-
einfach irgendeinen Knowledgebase Artikel mit Google oder aus dem eigenen Archiv finden, dann die Ziffern am Ende der URL gegen die letzten 4 Ziffern des gesuchten Artikels austauschen, hier also 8174 ergibt:
http://www.tobit.de/login/kbAr…omSearch=1&ArticleID=8174 -
Wizzard jo, da geht das durchaus, ist aber halt kein Teil des Eingangsregel Systems.
Sollte er allerdings eine Einzelplatzinstallation sein eigen nennen oder der Admin einer Installation sein könnte er das natürlich dennoch nutzen, dazu gehört aber halt nicht nur Creativität, sondern auch eine gute Organisation, sonst sucht man sich später echt blöde weil keiner drauf kommt was da eigentlich im System passiert
Aber ja, man kann das wohl dazu vergewohltätigen... -
Ich interpretiere den Log so das der Grabbing Server da schlicht bei Mail 28016 aussteigt, vermutlich schlicht weil die Verbindung zum Server unterbrochen wurde und nicht wieder aufgenommen werden konnte. beim Versuch mehr las 28016 Mails abzurufen ist das ja auch nicht weiter verwunderlich, da muss ja schon in letzter Zeit jeder Abruf Ewigkeiten gedauert haben.
-
zu 1. das geht schlicht nicht
zu 2. das wäre nur möglich wenn man einen Drucker hat welcher eMails empfangen und darin enthaltene PDF Anhänge automatisch drucken kann. dann könnte man mittels der Regel weiterleiten und xMedia eMails basierend auf den zur Verfügung stehenden Kriterien an seinen Drucker weiterleiten lassen. Alternativ zu einem Drucker der das kann könnte man natürlich auch einen passenden Druckserver aufsetzen der sowas kann. -
mir ist das Zeug nie ganz klar geworden.
Das Problem damit war für mich von vornherein die Facebook Verbindung.
Entsprechend hab ich mich auch nie weiter damit beschäftigt.
Inzwischen hat Tobit halt die Chayns ID zu einem strategischen Element für den Smart Client und den Support gemacht.
Hätten sie das nicht getan wäre mir Chayns in zwischen auch völlig in Vergessenheit geraten. -
Ah, sie mal einer Guck, ich hatte mich schon gewundert warum Du die Zeile scheinbar nicht hattest oder sie übersehen hast.
Ich hatte entsprechend schon erwartet das Du irgendwann noch mit irgendwas um die Ecke kommst wie man diese erste Zeile verhindern kann.
Was dann ja jetzt auch in gewissem Sinne der Fall ist, wenngleich das - zumindest hier - jetzt eher keine Option ist. -
Oder Methode 3 man installiert Lets Encrypt von Hand auf seinem David Server, automatisiert das aktualisieren des Zertifikats einmalig und hat dann ebenfalls für alle Zeiten Ruhe.
Dieser dritte Weg kann übrigens besonders dann sinnvoll sein wenn man weder Geld für Zertifikate ausgeben noch Port 80 für die Validierung der Zertifikatszuteilung nach außen offen haben möchte und die Validierung lieber per DNS durchführen mag. Ist dann allerdings einmalig etwas aufwändiger einzurichten, Wenn man es aber mal hat ist es ein sehr lange laufender Selbstläufer
Ich nutze allerdings aktuell auch SiteCare, einfach weils dabei ist und mich nicht stört Port 80 offen haben zu müssen. Für eine Reihe anderer Lets Encrypt Zertifikate nutze ich allerdings seit geraumer Zeit mit wachsender Begeisterung DNS basierte Validierung und denke durchaus gelegentlich darüber nach das auch beim David Server so zu tun um den Port 80 gänzlich loszuwerden.
