Beiträge von NoHopeNoFear

    SL + Postman anhalten, Backup und lösche mal alle Einträge unter:

    Apps\Faxware\Out\Api (muss dann leer sein)

    Apps\Postman\In (muss dann leer sein)

    Tld\Port\Extra (alles löschen außer postman.job/sta und tld.cfg/chk)

    zusätzlich die david.job löschen


    SL + Postman wieder starten


    Kann sein dass irgendein Job quer hängt und den Postman immer wieder abschießt. Damit sollte der Job entfernt werden.

    Unsere Mitarbeiter sind weltweit im Einsatz und unser Server steht in Deutschland.

    Die Situationen in denen das nicht funktioniert sind extrem selten und dann ist das aber auch selbsterklärend, da kannste nämlich dann auch normales Surfen schlicht vergessen.

    Im übrigen nervt die ständige Office 365 Werbung langsam, ich bin hier im David Forum weil ich Informationen rund um David suche und wo ich sie habe auch gern gebe, nicht weil ich in jedem zweiten Thread was zu Office 365 lesen will :o

    Hast hja grundsätzlich recht. Das Problem ist nur dass die Möglichkeiten zum externen Zugriff einer der größten Schwachpunkte in David sind. Und das schon lange und ohne nennenswerte Besserung. Wer mit beiden (oder noch weiteren) Varianten gearbeitet hat kommt eben schnell zu dem Schluss dass es bessere Lösungen gibt. Die meisten User hier sind Mitarbeiter in Systemhäusern die es sich nicht erlauben können nur ein Produkt zu verkaufen, gerade wenn es nicht zu den Anforderungen des Kunden passt. Deshalb hat der Hinweis auf Konkurenz Produkte schon eine gewisse Berechtigung.

    Das Infocenter von extern via Port 267 zum David Server verbinden zu lassen läuft aber wirklich nur dann vernünftig wenn Bandbreite und Latenz passen. So wie er es beschreibt - User in Singapur, Server in Honkong, am besten noch via Public WiFi - da sind Probleme vorprogrammiert.


    Bei Office 365 wird nichts mehr repliziert zwischen Servern. Es gibt in dem Fall nur noch "den einen" Office 365 Server bei MS. Das FileSharing wird dann über Sharepoint gelöst. Die Outlook Clients haben ihren Datenbestand offline vorliegen.

    Alles was du bemängelst sind Probleme die David im Grunde schon immer hat und an denen sich seit Jahren kaum etwas verbessert hat. Wäre es meine Installation würde ich eine Migration Richtung O365 planen. Bei David hast du die Grenze des machbaren schon überschritten.


    Was man noch testen kann ist die Anbindung von externen Usern via Outlook und ActiveSync. Damit ist zumindest ein Arbeiten offline möglich. Alternativ IMAP/SMTP.


    Also der Umstieg lohnt sich auf jeden Fall!

    Sehe ich auch so. Gerade was mobiles arbeiten angeht ist David einfach noch in der Steinzeit. Die Migration ist aber wirklich eklig. Wir haben jetzt ein paar kleinere Migrationen mit dem Tool von Itacom gemacht und mir graut es wirklich vor den größeren die noch anstehen. Ist einfach mit extrem viel Handarbeit verbunden und die Probleme beim Einlesen von großen .PST Files hast du ja schon erwähnt.


    Da ist wirklich noch viel Potenzial für eine bessere Lösung. Wir sind auch durchaus bereit dafür deutlich mehr zu zahlen - wenn es denn im wesentlichen automatisch abläuft.


    Im Vergleich zu Exchange -> O365 oder Kerio -> O365 ist der Aufwand wirklich extrem hoch. Die beiden anderen Varianten machen wir via SkyKick. Das ist im wesentlichen fire and forget, bis auf die Nacharbeiten am Outlook Profil.

    Das klingt nach einem netten Konzept, für 98% aller David Installationen aber wohl ziemlich oversized ;)

    Immer auch dran denken dass die Strongbox keine Config sondern nur Daten enthält. Beim Desaster Recovery musst du also auch irgendwie das System selbst aus einem Image zurück schreiben.

    Kontingente wären ne feine Sache... ich würde auf jeden Fall davon Abstand nehmen Kontingente via FSRM zu setzen. Das ist in Kombination mit David sicherlich ein Schuss ins Knie mit Anlauf.


    Grundsätzlich sollte man auf Eingang/Ausgang Ordnernd die Ablage aktivieren, das reduziert zumindest die Anzahl der Files enorm und reduziert etwas die Probleme bei einem Recovery.

    Spassig. Da ja die Chat Daten in der DB stehen wird das zu einem Problem werden. Das Tobit eigene Migration Tool ignoriert die SQL DB ja ebenfalls. Hat der Kunde also wichtige Daten im Chat - hat er nach der Migration keine mehr. Wie erklärt man einem Kunden dass er diese Funktion nicht für Kommunikationen verwenden soll die er in ein paar Jahren evtl. noch mal braucht?

    Ich weiß gar nicht genau wie David das löst, gerade was die rückwirkende Anzeige von verschlüsselten Mails nach Ablauf des Zertifikates angeht.


    Bei Reddoxx läuft es so:
    Zertifikat wird auf der Appliance installiert

    User triggert den verschlüsselten Versand z.B. über bestimmten Text im Betreff oder durch generelle Config (an Mail xx@sdsd.de immer verschlüsseln)

    Appliance verwendet Zertifikat zur Verschlüsselung, vorher wir die Mail unverschlüsselt archiviert. Danach noch mal verschlüsselt.


    Beim Empfang läuft es andersrum, hat der Schlüsselaustausch stattgefunden wird die Mail entschlüsselt und ebenfalls in beiden Versionen gespeichert.


    Das löst auch das Problem mit der Zertifikat Verwaltung da die Zerts nicht auf einzelnen Clients rumfliegen und für jeden User konfiguriert werden müssen.

    Damit die Pflicht zur Archivierung und Verschlüsselung sich nicht gegenseitig abschießen musst du serverseitig verschlüssen und archivieren. Wir lösen das mit Reddoxx, nehme mal an dass Mailstore da ähnlich arbeitet.


    Generell ist die Mailverschlüsselung halt ein Krampf. Noch größer ist der Krampf aber wenn die Zertifikate auf den Clients liegen.

    Habe das vor Ewigkeiten mal gemacht, hat funktioniert. Musste nichts neu zuweisen, hat mich auch gewundert. Würde allerdings auch davon abraten.


    David läuft problemlos auf einem DC, irgendwas auf einem DC zu installieren ist allerdings nie "sauber". Dürfte aber bei fast allen kleineren Installationen gängige Praxis sein.

    Wir haben sehr viele Kunden von David auf Kerio umgestellt. Mittlerweile verkaufen wir keine Connect (und auch keine Control) Neulizenzen mehr freiwillig. Seit Kerio von GFI geschluckt wurde, die gesamte Entwicklung in Tschechien platt gemacht wurde, stagniert die Entwicklung. Dazu kommt dass einige der letzten Versionen mit massiven Fehlern ausgeliefert wurden und die Behebung sehr lange gedauert hat.


    Dazu kam natürlich noch eine Preiserhöhung von gut 30%...


    Ernst gemeinter Rat: Finger weg. Zumindest im momentanen Zustand.



    Wir gehen momentan mit allen Migrationen und Neukunden auf Office 365. Gibt ca. 17% monatlich für alle verkauften Lizenzen und die grundlegenden Sachen sind recht einfach einzurichten.


    Kerio Connect hat einen eigenen Webclient. Sonst nichts. Die Anbindung erfolgt idr. via Outlook über einen eigenen Connector der leider ziemlich schrottig ist und seit 5 Jahren kein nennenswertes Update bekommen hat. Bei großen Postfächern oder wenn viele Postfächer im gleichen Outlook verbunden sind geht die Performance extrem in den Keller. SSD in jedem Fall Pflicht bei Postfächern über 5 GB.


    Wenn du was mit integriertem Fax suchst kommst du an David wohl nicht vorbei. Is halt nicht mehr 1995 ;)

    Wir werden die Partnerschaft wohl auch kündigen müssen. Betohnung liegt auf müssen. Was soll ich jedes Jahr Gebühren zahlen wenn keine Provision zurück kommt. Ich kann mir kaum vorstellen dass es Tobit Partner gibt die wirklich nur von David Lizenzen leben. Im Grunde sind wir doch alle reguläre Systemhäuser die David als Beiwerk ihren Kunden anbieten. Damit hält sich der Absatz von Neulizenzen prinzipiell schon in Grenzen. Wenn die Lizenz dann auch noch doppelt so teuer ist...


    Tobit ebnet hier den Weg zur O365 Migration. Wird Zeit dass ein Partner mal ein wirklich brauchbares Tool dafür entwickelt. Bei O365 via CSP Lizenzen kommt auch konstant eine Provision.