Beiträge von nordtech

    Zu den "Fetten" Rahmen ist mir aufgefallen, das es diese auf den

    Beispiel Bildern auf der David3 Startseite nicht gibt...

    Oder hab ich Tomaten auf den Augen?

    Ich bin da auch immer noch am Forschen. Auf meinem Win10-Desktop mit full-hd und 125% Skalierung sind die Rahmen im Vollbild fett:

    Wenn man aber das Fenster per Maus an die Seite "wirft", so dass nur eine Hälfte des Schirms ausgefüllt wird, dann werden die Rahmen deutlich schlanker. Und (neues Feature) der Navigator wird ausgeblendet. Das macht die Sache tatsächlich um einiges übersichtlicher.

    Auf meinem Laptop mit WQHD-Auflösung wirken die Ränder generell nicht so üppig. Da sieht's eigentlich fast aus wie früher.

    Ich vermute es kommen in den nächsten Rollouts noch ein paar Anpassungen.

    Erst muss ich als Partner bei meinen Kunden Überzeugungsarbeit leisten, dass sitecare sinnvoll ist und nun, da Tobit genügend zahlende sitecare-Kunden hat, nehmen die mir/uns als Partner die Provisionen dafür weg.

    So etwas geht nicht.

    Ja, das sehen wir ähnlich - bei unseren Kunden hätten von sich aus keine 10% sitecare abgeschlossen, die haben alle bei uns angefragt, ob das sinnvoll sei. WIR sind diejenigen, die Überzeugungsarbeit leisten und uns parallel dazu die Klagen über die hohen Kosten anhören dürfen. WIR haben in Rundmails den Erklärbären gegeben und dargestellt, warum das integrierte Let's-Enrcypt-Zertifikat eine feine Sache ist oder wie nützlich die verbesserten Verschlüsselungsmethoden sind. Von solchen Sachen bekommt der normale Kunde doch gar nichts mit, der sieht nur (wenn überhaupt) die Änderungen im Client und ist oft noch nichtmal besonders glücklich darüber.

    Mit der Provision im Hinterkopf ging das bisher einigermaßen. Wir haben den Kunden geduldig erklärt: Doch doch, da tut sich was, du siehst es nur nicht so direkt, aber unter der Haube, da wird für dein Geld schon was geleistet.

    Die Motivation, das zukünftig komplett ohne Vergütung zu machen, hält sich doch sehr in Grenzen. Gleichzeitig müssen wir uns sehr fragen, ob das Zahlen der Partner-Gebühr noch sinnvoll ist. Mit Marge auf Neuinstallationen alleine bekommen wir nicht einmal die wieder rein.

    Bis gespannt auf die Antwort aus Ahaus, vielleicht denkt man dort ja doch noch um, wenn der Protest laut genug ist.

    Mal wieder nur viel heiße Luft. "David drei", naja. Neuer SQL-Server? Verbesserte Webbox? Aktualisierung Mac-Client? Änderung Dateispeicherung? Verbesserung der Werkzeuge (durfte neulich mal wieder den Outlook-Import "genießen", au weia). Nöö.

    Hauptsache ein neues (hässliches, imho) Logo und eine neue Hintergrundgrafik. Man kann sich durchaus fragen, was das alles soll.

    Ich denke, dass David in diesem Fall die geringste Schuld trifft; Windows Server 2016 ist leider sehr zickig bei Updates (vgl. https://heise.de/-4316646 ), und Acronis TI hat uns insbesondere als Server-Version ebenfalls schon oft Kummer bereitet. Der einfachste Weg wäre somit wohl, eine diese Komponenten zu ersetzen. Server 2019 soll lt. obigem Heise-Artikel pflegeleichter sein, was Updates angeht. Und kleine schlanke Alternativen zu TI gibt's auch einige (z. B. Drive Snapshot).

    Ich weiß, das ist nicht das, was du hören/lesen wolltest. ;) Aber mir fällt keine andere einfach zu implementierende Lösung ein - außer, man sorgt z. B. mit Scripten dafür, dass während aufwändiger Systemaktionen (Update-Installation, Datensicherung...) alle David-Dienste angehalten werden. Ob das im "worst case"-Szenario aber konkret solche Fehler verhindert, weiss man natürlich trotzdem nicht. Wichtig ist es ferner, für Backup und Update-Installation feste Zeitfenster einzuplanen, aber ich gehe mal davon aus, dass ihr das bereits macht.

    Die wichtigste Info, die ich neben dem üblichen Markating-Blabla aus der Mail ziehe, ist: Zukünftig keine Provisionen mehr auf Kundenumsätze mit Sitecare.

    Es ist echt zum Mäuselmelken mit dem Laden. Ist das deren Ernst? Es soll statt dessen bessere Margen auf neue Lizenzen geben? WTF? Das nützt uns so ungefähr GAR nichts. Ich weiß ja nicht, wie es bei euch so aussieht, aber komplett neue Lizenzen verkaufen wir nur noch alle Jubeljahre mal.

    Hallo z'samm.

    Bei einem neuen Kunden ersetzen wir Outlook + Hosted Exchange durch David. Wie erwartet haben die User an einigen Stellen Bauchschmerzen mit dem Umstieg, allerdings gar nicht mal unbedingt da, wo ich es primär vermutet hätte... ;)

    Statt dessen sehe ich mich mit der Anforderung konfrontiert, dass die Ausdrucke (ja, die drucken E-Mails, bitte keine Grundsatzdiskussion zu diesem Thema, das hab' ich auch schon erfolglos probiert) so aussehen sollen wie bei Outlook. Insbesondere steht bei einem Outlook-Druck ganz oben auf dem Blatt der Name des druckenden Users (Realname), bei David hingegen "eMail".

    Mir ist bekannt, dass das Druckformular via \david\clients\windows\EMAIL.PRN (Ausgabe über lokalen Drucker) bzw. \david\code\template\Default.eml (Ausgabe via im DvAdmin definierten Systemdrucker) angepasst werden kann. Die darin möglichen Variablen wie ##RECIPIENT## helfen mir aber nur bedingt, da dort a) soweit ich weiß nur die E-Mail-Adresse enthalten ist und nicht der Klartext-Name und b) auch diese Adresse nicht immer korrekt widerspiegelt, wer die Nachricht gedruckt hat - es soll z. B. wenn User A eine Mail druckt, die an User B gegangen ist, trotzdem "User A" drüber stehen.

    Hat jemand von euch eine Idee, wie man das realisieren könnte? Kann man aus den globalen .prn-Formularen irgendwie User-bezogene machen?

    Meinem Vorschlag, statt dessen einen fetten Drucker mit individuellen Ausgabefächern zu installieren, wurde nicht mit Wohlwollen begegnet. Statt dessen heißt es: "Mit Outlook ging das aber!". :rolleyes:

    Bin für jede Idee, ggf. auch per "Infusion" außerhalb Davids, dankbar...

    Mein Kenntnisstand ist ebenfalls, dass die Outlook-App selbst keine Verbindung zum ActiveSync-Server aufbaut, sondern sich dazu eines weiteren Servers bedient, an den munter alle Login-Daten weitergegeben werden. Vgl.

    https://heise.de/-2533240

    Der letzte Kommentar bei Heise von Ende 2017 deutet allerdings darauf hin, dass sich das inzwischen geändert haben könnte: https://www.heise.de/forum/Mac-i/Ne…-31317217/show/

    Durchgelesen habe ich den dort verlinkten Artikel allerdings nicht.

    Und wie stellt sich das konkret dar? Sind das "echte" Mails, bei denen im Body nichts zu erkennen ist? Oder einfach Einträge, von denen niemand weiß, wo sie herkommen? Was steht im Quelltext einer solchen Nachricht? Oder handelt es sich gar um defekte Einträge in der archive.dat, die also in der Liste auftauchen, auf Dateisystem-Ebene aber nicht existieren?

    Generell kann es helfen, einmal von einem betroffenen Archiv alle Mails in ein anderes Archiv umzukopieren. Dann das alte Archiv löschen (oder zumindest Bereinigung am Server durchlaufen lassen), neu anlegen und alles wieder zurück schieben. Dadurch werden alle Indexdateien zwangsläufig neu aufgebaut und fehlerhafte Einträge rausgeworfen.

    Zeigt sich das Problem denn wild verteilt über mehrere Archive/User, oder nur bei einzelnen?

    Nein, der Kunde hat keine IPv6-Adresse. Wir lassen den A-Record auf seinen eigenen Server zeigen, haben den AAAA-Record gelöscht und dann abgewartet, bis sich die Änderungen im DNS herumgesprochen hatten - nun funktioniert's!

    Wieder was gelernt: Let's Encrypt behandelt IPv6 bevorzugt. Sprich, wenn ein AAAA-Record existiert, muss er auch stimmen. ;) Ansonsten sollte er für die Zertifikats-Abfrage deaktiviert werden.

    Update: Aha, die Einträge im Ereigniss-Archiv waren etwas aussagekräftiger:

    (AC) Certificate Order Error

    Code 1004
    Error Error order certificate
    StatusCode 422
    Description Invalid domain provided
    Reason Failed to validate DNS-records (AAAA)

    Da hat ionos offenbar ungefragt einen AAAA-Record für die Subdomain angelegt. Nun muss ich wohl erstmal die TTL abwarten, nachdem ich diesen Eintrag gelöscht habe.

    Moin,

    ich versuche gerade, bei einer ganz frischen David-Installation das Let's-Encrypt-Zertifikat zu bestellen. Passende Subdomain ist eingerichtet und funktioniert, Portfreigaben OK (david.kundenname.de bringt mir die Anmeldemaske), sitecare aktiv.

    Im Admin erhalte ich die wenig erhellende Auskunft: "Aktueller Status: Fehler bei Verarbeitung des Auftrags([object Object])". Domain und Mailadresse sind korrekt hinterlegt.

    Bei den bisherigen Installationen klappte das komischerweise immer einwandfrei, die hatten vorher aber auch alle ein bestehendes selbsterstelltes Zertifikat. Hakt es daran? Eigentlich nicht, oder? Sprich, wenn Port 80 offen ist müsste es doch gehen, oder? Der Verbindungstest zeigt mir an, dass Port 443 nicht erreicht werden kann - ist ja auch logisch, da die Webbox beim Start merkt, dass noch kein gültiges Zertifikat da ist.

    Mache ich einen Denkfehler? Hatte jemand von euch schon mal die obige Fehlermeldung?