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.
Ja, das fragt man sich... Die IP zeigte standardmäßig auf den bei ionos/1&1 gehosteten Webspace, aber das ist natürlich genau das, was wir nicht wollten. Generell ein komischer Laden, irgendwie. Mit Strato hatte ich solche seltsamen Überraschungen noch nie.
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?
Nachtrag: Ich habe mir gerade mal den Spaß gemacht, und eine .pck-Datei geöffnet, die scheinen in der Tat nur zusammengefasst und nicht gepackt zu sein (zumindest sind z. B. die Header usw. noch im Klartext zu lesen).
Von daher wird die Platzersparnis durch eine eingeschaltete Verzeichniskomprimierung seitens Windows erheblich davon abhängen, ob die Nachrichten textlastig sind oder viele Anhänge enthalten - bei mir ergab sich beim ZIPen der .pck lediglich ein Platzvorteil von knapp 10%. Da sind viele Anhänge dabei, die nicht mehr bedeutend weiter verkleinert werden können (PDFs, JPGs).
Bei reinen Textnachrichten wird die Sache anders aussehen.
Die Windows-eigene Komprimierung arbeitet ja transparent, das heißt, David bekommt gar nichts davon mit, dass die Daten auf der Platte gepackt vorliegen. Von daher halte ich es für ausgeschlossen, dass man sich im Archivsystem irgendwas kaputt macht.
Die spannende Frage ist eher, ob David beim Zusammenfassen von Archiven nur alles in eine Datei wirft oder dabei intern auch schon komprimiert. Wenn letzteres, dann wird eine zusätzliche Komprimierung durch Windows nichts (oder kaum was) bringen.
Hätte ich jetzt auch gesagt. Mit Acronis/Drive Snapshot o. ä. offline die Partition auf ein externes Ziel (USB, LAN...) wegsichern, dann RAID umbauen und offline alles wieder zurück schreiben. Je nach Programm anschließend noch in Windows die Partition groß ziehen, aber das geht heutzutage ja mit Bordmitteln.
Der Server kriegt von der Aktion dann im Idealfall gar nichts mit, und alle Rechte, Freigaben usw. bleiben erhalten.
Funktionieren müsste der Ansatz über Windows Backup allerdings auch.
Ist jetzt nur ein Tipp ins Blaue, da wir immer die klassische Ansicht nutzen, aber: Werden bei der "modernen" (Vorschau neben der Eintragsliste) nicht Unterhaltungen standardmäßig irgendwie zusammengefasst? Tauchen die hin- und hergeschickten Mails evtl. untereinander auf, wenn du in der Übersichtsliste die Ursprungsmail anklickst?
Windows 7 im Einsatz? Dann ist bestimmt KB4480970 Schuld:
Es gibt inzwischen einen Hotfix.
Moin,
ich habe länger keine Neuinstallation mehr gemacht, aber steckt im Installationsimage der aktuellen David-Versionen eingentlich immer noch der SQL 2008R2 mit drin? Mal angesehen davon, dass der auf Server 2016 erst nach dem Einspielen der letzten Service Packs überhaupt vernünftig rennt (wie sieht das bei 2019 aus?), flattert mir gerade eine Mail von Microsoft ins Haus: Supportende für SQL 2008R2 im Juli 2019...
Hat jemand von euch Erkenntnisse, wie das seitens Tobit weitergehen soll? Oder gibt's inzwischen eine offizielle Anleitung für den Betrieb einer neueren SQL-Version mit David? Mein letzter Stand ist ein Info-Dokument, in dem sinngemäß hieß: "Neuere Versionen des SQL-Servers als 2008R2 verfügen nicht über einige von David benötigte Funktionen. Sie können aber trotzdem auf eigene Faust eine neuere Version einsetzen". Übersetzt: Mach doch; wenn's funktioniert, ist's gut, aber wir wissen eigentlich auch nicht so richtig.
Das klingt für mich eigentlich eher nach einem Problem in der Domäne (sofern ihr eine habt) - klappt im Netzwerk generell denn alles mit deinem User? Zugriffsrechte usw.?
Was du mal testen kannst, ist im David-Admin temporär deinem David-Benutzer einen anderen AD-User zuzuordnen, z. B. das Gast-Konto oder irgendein anderes unbenutztes (notfalls schnell ein Dummy-Konto im AD anlegen). Anschließend stellst du die Zuordnung gleich wieder zurück auf deinen eigenen Benutzer. Damit sollte die Verknüpfung zwischen der AD-Anmeldung und dem David-User neu aufgebaut werden.
Oder REGEDIT.EXE starten und hier schauen: \HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Wenn Du's dir einfach machen willst, nimm Autoruns - da wird dir so ziemlich alles angezeigt, was auf dem Rechner automatisch startet. Aber beim Löschen bitte vorsichtig sein!
Nein, der Mobile Client erstellt dir eine komplette lokale Kopie incl. abgespecktem Service Layer, so dass du z. B. auf einem Notebook offline arbeiten kannst. Als ich das zum letzten Mal angesehen habe (ist schon ein paar Jahre her), funktionierte das eher schlecht als recht - eine solche Offline-Anbindung würde ich heute eher mit einem lokalen Outlook und EAS realisieren.
Domain Controller zuerst aufsetzen ist sicher eine gute Idee, sonst musst du u. U. später die User-Zuordnungen neu einrichten.
Wenn ich nichts überlesen habe, musst du eigentlich nur im David-Client deine interne Nummer (wie in der FritzBox hinterlegt) unter "Benutzerprofil" eintragen. Bei FritzBoxen drei Sternchen voranstellen, also z. B. ***621
Wenn du dann aus dem Client heraus eine Nummer anwählst, sollte dein Telefon klingeln, und beim Abnehmen wird die Verbindung aufgebaut.
Nett, die Liste habe ich mir gleich mal weggespeichert. Wer sich auf dem Port 80 so alles tummelt...
Aber schön, dass wir auf die richtige Spur gekommen sind. Dann kann das Let's Encrypten ja jetzt starten!
Oh ja, sorry, hatte ich überlesen.
Das einzige was ich mir in der Richtung mal notiert hatte war, dass auch ein ggf. installierter SQL Reporting Service den Port 80 blocken kann. Über den "Reporting Services Configuration Manager" lässt sich das ändern, man muss aber darauf achten, auch die URL im Report Manager (über "Advanced") entsprechend anzupassen.
Das Deaktivieren von HTTP in der Registry macht zwar den Port 80 vom Server frei und ich kann diesen mit Tobit nutzen, das Lets encrypt Zertifikat einrichten usw., aber dann funktionieren andere Dinge am Server nicht mehr. Das fängt bei der Datenträgerverwaltung an und hört bei der Netzwerkkennung auf. Server 2016 benötigt das so...
Nee, das hängt denke ich eher am Essentials. Mit Windows Server 2016 Standard hatte ich derartige Probleme bisher nicht. Schade in diesem Zusammenhang, dass es für kleine Netze keinen Foundation mehr gibt; beim Essentials kriegt man wie früher beim SBS seitens MS immer alle möglichen Funktionen mit reingewürgt.
Ergänzend zu den anderen Vorschlägen: Was passiert denn, wenn du den IIS wieder installierst, dessen Standard-Webseite aber auf einen anderen Port konfigurierst? Ist dann 80 immer noch belegt?
Oben in der Menüleiste!
Ich würde den @@-Befehl nicht in der Vorlage, sondern lieber in einer Include-Datei unterbringen und die bei der Benutzerkonfiguration im David hinterlegen.
Alternativ kannst du ja die T-Online-Adresse bei jedem Benutzer als Standard eintragen. Damit es kein Zufall ist, wo eingehende Mails dann landen, ergänzend noch eine Verteilregel in jedem persönlichen Eingang: Wenn Mail von extern, dann verschieben ins Archiv "Sammeleingang" oder so ähnlich.
Schön ist aber anders. Ich habe auch einen Kunden, der nach außen partout mit einer einheitlichen info-Adresse arbeiten möchte, aber es gibt an anderer Stelle immer mal wieder Probleme - zum Beispiel, wenn Terminanfragen eingehen, die für einen spezifischen Benutzer gedacht sind und über info@ eintrudeln.
Du kannst doch für intern einfach Phantasienamen unter "eingehende E-Mailadressen" in der User-Konfiguration einrichten. Zum Beispiel mit der lokalen Domäne, sofern vorhanden: klaus@kundendomain.local. Oder sogar einfach nur den Namen ("Klaus").
