Ergänzung: OK, 64 bit scheint nicht das Problem zu sein. Das Element ist weiterhin vorhanden - bei OFFICE (!!!) x64 heißt's wohl schlicht "E-Mail", bei Office x86 explizit "E-Mail (32-Bit)".
Dann bleiben also generelle Bugfixes, um das Element wiederzuholen. Ich wiederhole daher meine Frage aus Beitrag Nr. 4: ist die .cpl auffindbar und kann man sie manuell auf Dateisystem-Ebene öffnen?
Ich denke wenn ich ein Screenshot von Windows 11 schicke ist es selbsterklärend
Ich denke, du verstehst mich nicht 
WINDOWS ist meistens x64, seit Windows 11 alternativlos.
OFFICE gibt es aber auch in x86 und x64. Zum Einsatz kommt heute in aller Regel weiterhin Office x86, es steht aber eben auch eine x64-Version zur Verfügung, gerade bei M365 relativ prominent zum Download angeboten. Die verhält sich in vielen Details anders.
Das Systemsteuerungs-Element "Mail" existiert nur, wenn MS Outlook installiert ist. Mein Verdacht ist, dass dieses Element bei der x64-Version von OFFICE eben nicht mehr installiert wird. Da ich auf meinen x64-Systemen unter Windows 10 und 11 aber überall 32-bit-Versionen von Office installiert habe, kann ich das nicht prüfen - daher die Bitte an den Thread-Ersteller.
Ich meine nicht Windows x64, sondern Office x64. Da gab's bei Einführung diverse Wehwehchen, auch mit Schnittstellen usw. Sogar MS selbst empfahl zunächst, "im Zweifel die 32bit-Variante" zu installieren... Darum kann ich das momentan auch nicht prüfen, alle meine Office-Versionen sind hier 32 bit.
wordplex: Schau bitte mal in deinem M365-Outlook: Datei -> Informationen -> Office-Konto -> Auf den Button "Info zu Outlook" anklicken -> Im neuen Fenster gleich die erste Zeile: "Microsoft Outlook..." ganz am Ende: "32 bit" oder "64 bit"?
Glaskugel sagt: Ihr sendet und empfangt über einen Provider, mit individuellen Postfächern (kein Catchall). Dann stammt die Meldung, die die externen Absender erhalten, korrekterweise von eben jenem Provider, der darüber informiert, dass das Postfach nicht gefunden wurde. Bis zum David gelangt sie also erst gar nicht. Den externen Fehlertext anpassen kann entsprechend nur eurer Provider.
Intern sieht das ganz anders aus, da schickt jemand an gibtsnicht@domain.de und David denkt "Hey, domain.de, das bin ja ich!" - fühlt sich also zuständig, nimmt die Mail intern an, und da eine User-Zuordnung nicht möglich ist, landet's im Unverteilt.
Die einzige Variante, die mir einfällt wäre folgende: Ihr sorgt zunächst dafür, dass Unverteilt grundsätzlich leer bleibt, z. B. indem Sammel-Adressen gleich per Verteilregel im David Admin in passende Unterarchive geschoben werden. Dann legt ihr im Unverteilt eine Regel an für "Mail = intern" und einen Autoreply der dem MA sagt: "Die Mailadresse gibt's nicht".
Hmm, ich bin nicht so der Outlook-Fuchs, aber kann es sein, dass der "klassische" Systemsteuerungs-Eintrag bei der x64-Version von Office nicht mehr vorhanden ist? Das wäre dann doof... Findest du im Office-Programmverzeichnis irgendwo eine MLCFG32.CPL? Wenn ja, klick die mal mit rechts an und wähle "Mit Systemsteuerung öffnen".
Spontan gefunden habe ich ansonten diesen Thread hier - im vorletzten Beitrag geht es um Misch-Installation x86 + x64.
Kurz zur Dokumentation: Die eigentliche Umstellung ist dann tatsächlich relativ simpel. Man klickt sich seine Postfächer zusammen, und im Admin-Center gibt es unter "Setup" sogar eine Art Assistent, der (ganz MS-untypisch) ziemlich genau angibt, was man am Ende in den DNS-Einstellungen beim Provider noch machen muss. Konkret: MX-Eintrag erstellen, CNAME für Autodiscover einrichten und einen TXT-Eintrag für SPF ergänzen.
Die Administration wirkt ein bisschen verstreut, aber passt schon. Im David ist's halt mehr "oldschool", einfacher und direkter.
Ich sehe das mit einem lachenden und einem weinenden Auge. Schade, dass wir uns jetzt ganz allmählich von David wegbewegen. Aber da Tobit kein wirkliches Interesse an seinen Fachhändlern mehr zu haben scheint, ist's gut, den Kunden eine Alternative anbieten zu können.
Ach so... Also einfach in "AD Domänen und Vertrauensstellungen" den öffentlichen Domain-Namen ergänzen und dann die User entsprechend umstellen?
OK, das ist dann wirklich einfach. Manchmal macht man sich auch unnötig einen Kopf. 
Moin, ich dachte, ich frage mal hier an, weil uns dieses Thema vermutlich alle früher oder später beschäftigen wird...
Es ist so weit: Die ersten unserer Kunden drängen in Richtung M365, und damit sind wir ja in der Tat schon ziemlich spät dran. Die ganze Diskussion Pro und Contra lasse ich an der Stelle mal weg, vielleicht nur so viel: Ich persönlich finde David weiterhin ein schönes Produkt insbesondere für kleine Umgebungen. Aber der Wegfall der Sitecare-Provisionen hat nicht unbedingt zur Motivation beigetragen, David weiterhin "mit Zähnen und Klauen" gegen die übermächtige Konkurrenz zu verteidigen. Und einige Kunden drängeln halt schon eine ganze Weile. Spätestens, wenn im Zuge der nächsten Server-Umstellung die Fax-Funktion rausgeworfen wird, kommt wieder die Frage nach Outlook + Exchange.
Wobei ich, ansonsten durchaus Cloud-Skeptiker, schon ganz dankbar dafür bin, dass auf diese Weise zumindest die Betreuung eines on-premise Exchange-Servers komplett an mir vorüber gegangen ist. Gewissermaßen aus der "Windows-NT-Zeit" (David) direkt in die Cloud. Kann man machen. 
OK, aber nun zum Thema. Nach den üblichen Steinen, die einem die MS-Logik wie gewohnt in den Weg legt, bin ich nun an der Stelle, wo der Endkunde eine onmicrosoft-Domain besitzt, M365 ist bestellt. Nun soll's ans Anlegen der User gehen, und ich dachte mir: Hey, da haben wir doch ein feines, gut gepflegtes AD lokal, ist doch bestimmt am schlausten, einen permanenten Abgleich lokales AD -> Azure AD einzurichten. Flugs das lustige Tool IdFix zur Prüfung heruntergeladen, nach einem manuellen Eingriff in der Registry (ächz...) funktioniert das dann sogar, und sagt mir: Näää, gefällt mir alles nicht. "Top level domain". Also, die lokalen User enden halt alle auf die lokale Kunden-Domain "kundenname.local". Und da mache ich dann schon dicke Backen.
Wie geht man hier vor? Muss ich "einfach mal so" die ganze Domäne umbenennen in kundenname.onmicrosoft.com? Oder gar in kundenname.de, die momentan von David "bedient" wird und deren Mails später mal in Outlook landen sollen? Früher[tm] hab' ich mal gelernt, dass die lokale Domäne eben explizit NICHT eine extern per DNS auflösbare Bezeichnung haben darf. Und nu?
Und die nächsten Probleme deuten sich schon an, speziell beim Einbinden der Kunden-eigenen Domain. Wie läuft das da: Ich muss wohl einen TXT-Eintrag (oder etwas vergleichbares) zur Verifizierung hinterlegen und dann die Domain mit dem MS-Konto verknüpfen. Und anschließend? Den MX beim Provider so ändern, dass Mails zu MS laufen? Und die landen dann automatisch in den passenden Outlook-Postfächern?
Jaja, ich weiß, für jemanden, der in der Sache fit ist, bestimmt blöde Fragen. Aber ich mag David halt, weil er "plain & simple" ist, zumindest im Grundatz. Dieses ganze Gewurschtel mit den MS-Diensten ist für mich ein Buch mit 4 Siegeln. Also nicht mehr 7, aber immer noch etliche.
"Witzig" auch, dass ich extra eine M365-Schulung gemacht habe. Da ging's dann darum, wie großartig alles ist und wie man den Webshop bedient - aber diese technischen "Kleinigkeiten" mit dem Namen des AD kamen dort gar nicht vor. Ist doch eh alles total einfach, weil Cloud... Grrr.
Falls jemand von euch Lust hast, mich zu erhellen, wäre ich sehr dankbar. Einstweilen lege ich die User im Admin-Center mal manuell an - sind bei diesem Kunden nur 5 Stück. 
SQL Report Server kann gut sein, ja.
Wenn es sich um einen 2019 Essentials handelt, evtl. auch der BranchCache: https://docs.microsoft.com/en-us/previous…rectedfrom=MSDN
Übliche Verdächtige zusammengefasst:
SQL Server Reporting Services (ReportServer)
Web Deployment Agent Service (MsDepSvc)
BranchCache (PeerDistSvc)
Sync Share Service (SyncShareSvc)
World Wide Web Publishing Service (W3SVC)
Internet Information Server (WAS, IISADMIN)
IIS neu gestartet (am besten nicht den Dienst, sondern aus der Verwaltungsoberfläche heraus)?
Wer oder was meldet sich denn, wenn du am Server http://127.0.0.1 aufrufst?
Falls es hilft: Bei obigem Kunden ist
- bei IONOS das Postfach als "*@kundenname.invalid" eingerichtet, Typ "Mail Basic"
- im David-Admin der Account angelegt mit Server pop.ionos.de, Account "*@kundenname.invalid", Port 995
Ich bin momentan nicht ganz sicher - sind eigentlich ALLE 1&1-Domain-Kunden zu IONOS migriert worden, oder gibt es 1&1 als Consumer-Marke weiterhin? Du kannst ja aus Spaß auch mal mit den Server-Namen experimentieren.
Hm. Also wir haben auch einige Kunden mit Catchall-Postfach bei 1&1 bzw. IONOS. Da wird "Envelope-to:" korrekt befüllt. Hängt das evtl. am Typ des Vertrags oder so? Geschaut hab ich gerade mal bei einem Kunden mit "1&1 Homepage Business". Dort rennt's.
Kann ich bislang auch nicht bestätigen. Ist die Mail definitiv im Ausgangsprotokoll im David-Admin nicht verzeichnet? Ich frage deshalb so "doof", weil dort die Sortierung mitunter etwas unübersichtlich wird. Such mal über den Quickfinder.
Falls die Nachricht dort wirklich nicht auftaucht, ist das ein heftiger Fehler. Ansonsten hätte ich auf defekte Indexdateien im Ausgangs-Archiv getippt oder so etwas, aber davon sollte das Protokoll unbeeinflusst sein (oder?). Der Server an sich fühlt sich wohl? Platten OK, keine Lastspitzen, kein amoklaufender Virenscanner?
Ich hatte den Fehler bisher in zwei Fällen:
Bei dem betreffenden User fehlte das "Temp"-Verzeichnis auf dem Server, also \Archive\User\<userid>\temp - dazu würde aber nicht passen, dass das Problem nur auf einem PC auftritt.
Oder
Die Rechte unter DAVID\APPS stimmen nicht, insbesondere die Rechte aller David-User auf \David\apps\faxware\out\api - das wäre dann allerdings ebenfalls PC-unabhängig.
Prüf' mal lokal, ob alle temporären Verzeichnisse am PC korrekt zugewiesen und auch beschreibbar sind. Ansonsten hilft ggf. nur der Holzhammer: Client deinstallieren und manuell alle restlichen Tobit-Einträge aus der Registry löschen, und wenn das auch nicht reicht, das lokale Userprofil löschen und komplett neu aufbauen lassen. Vorher Datensicherung nicht vergessen.
Btw: Was heißt in diesem Zusammenhang "Externer PC"? Via VPN verbunden, aber Domänen-Mitglied? Oder direkt via David-Client angebunden...?
"Eigenen Absender benutzen" erscheint wimre nur, wenn man auf eine Mail antwortet, die ursprünglich an eine andere Adresse ging. Hat ein User mehrere Adressen hinterlegt, wird beim Antworten standardmäßig jene verwendet, an die die Nachricht geschickt wurde. Mit obiger Option lässt sich das übersteuern.
Was du suchst ist vermutlich eher das Feld "von". Erstelle eine neue Nachricht und blende im Editor-Fenster über "Burger-Menü" -> "Ansicht" die Zeile "Von" ein. Dann kannst du, sofern für den User im David-Admin mehrere Sendeadressen eingetragen sind, über den kleinen Pfeil neben "Von: " den zu verwendenden Absender direkt auswählen.
Oder David Admin -> Webbox -> Konfigurieren -> "Standard TCP Port exklusiv für Let's Encrypt benutzen"
Thema Nr. 2 hatten wir hier neulich schon - im Thread sind auch alternative Lösungen enthalten, wir sind letztlich beim Automatic E-Mail Manager gelandet, und das Tool läuft bislang reibungslos. Gibt aber auch noch viele andere Programme in der Art.
Ergänzung 1: Statt über den Webmailer kannst du natürlich auch z. B. mit einem Thunderbird das Postfach testweise als IMAP-Konto einrichten, das macht das Hin- und Herschieben der Mails einfacher. Und man sieht auch gleich, ob prinzipiell die Anmeldung am Konto problemlos möglich ist.
Ergänzung 2: Wenn tatsächlich noch david.fx zum Einsatz kommt (oder hast du den Thread nur versehentlich im falschen Bereich erstellt?), liegt die Info zu bereits abgeholten Mails ggf. nicht in einer mldb-Datei, sondern in einer mit Endung .lst, iirc.
Könnte eine einzelne Mail sein, an der David sich verschluckt. Am besten mal per Webmailer ( https://webmail.strato.de/appsuite/signin ) ins Postfach schauen, dort ggf. manuell alle Mails in einen Unterordner verschieben und dann einzeln oder gruppenweise wieder zurück legen - und jeweils beobachten, was der Grabbing Server dazu sagt.
Werden die Nachrichten bei der POP-Abholung sofort beim Provider gelöscht oder dort für eine Weile liegen gelassen? Falls letzteres könnte auch eine defekte .mldb-Datei in \David\Apps\Dvgrab\Code vorliegen. Diese ggf. testweise verschieben/löschen, aber Vorsicht: Der Grabbing Server holt anschließend ALLE noch beim Provider liegenden Nachrichten ab und behandelt sie als neu. Also auch hier manuell vorsortieren oder entsprechende Maßnahmen im David treffen!
Stimmt, manueller Import scheint auch unter iOS 15 noch zu gehen: https://blog.mayflower.de/10764-self-signed-zertifikate.html
Wenn ich mir das so durchlese, scheint mir der Weg über eine korrekt konfigurierte Webbox aber nach wie vor am schmerzfreisten.
