LTTG2

Ja, das habe ich bereits und erwarte noch Antwort. Da es dabei aber nur um eine Anwendung geht, die Haus-intern und ausschließlich im selben Teilnetz wie der SQL-Server unterwegs ist, hat das für mich low priority.

Tippfehler in meinem Text. Die andere Anwendung kommuniziert über TLS 1.0 daher sind obige Reg-Keys richtig.

So, ich konnte das Problem nun beheben. Mittels Wireshark konnte ich ermitteln, dass, wie schon vermutet, die nichts aussagende Fehlermeldung bedeutete, dass sich der Server mit der falsche TLS-Version (nicht 1.2 wie gefordert) beim Microsoft-Mailer gemeldet hat. Unterm Strich hatten noch ein paar Registry-Schlüssel gefehlt, dann hatte es geklappt. Andere gemäß diverser Online-Anleitungen musste ich sogar explizit weg lassen, damit ein anderer Haus-interner Dienst, der ODBC-Abfragen an den selben Server per TLS 1.1 richtet, weiterhin mit dem Server kommunizieren konnte. Wer zukünftig über dieses Problem stolpert: folgende Registry-Schlüssel musste ich anlegen damit es funktioniert. Die durchgestrichenen hatte ich entgegen der Anleitung wieder entfernt, damit besagter anderer Haus-interner Server im selben Netz weiterhin über TLS 1.1 mit dem SQL-Server reden konnte: [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] "Enabled"=dword:00000000 -> stattdessen: dword:00000001 "DisabledByDefault"=dword:00000001 -> stattdessen:: dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "Enabled"=dword:00000001 "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "Enabled"=dword:00000001 "DisabledByDefault"=dword:00000000 Ich danke allen für Ihre Unterstützung und wünsche euch was!

@Sunny61: Das Powershell-Script habe ich von folgender Seite - siehe auf dieser unter "Step 9": https://www.c-sharpcorner.com/article/how-to-configure-smtp-o365-migration-using-tls-1-2-for-sql-database-mail/

@Sunny61: Das wunder mich. Mit deaktivertem SSL-Häkchen kommt bei mir im Log dann der Fehler „Die E-Mail konnte wegen einem Fehler beim Mailserver nicht an die Empfänger gesendet werden. Ausnahmemeldung: E-Mails können nicht an den Mailserver gesendet werden. Verarbeitungsfehler: Die Serverantwort war: 5.7.3 STARTTLS required to send mail [FR0P281CA0133.DEUP281.PROD.OUTLOOK.COM" @t-sql: Korrigiere mich, wenn ich damit falsch liege, aber: der Versand aus der Powershell vom heraus (selber Server) funktioniert ja. Und siehe Info an Sunn61: stelle ich bei mir die SSL-Option aus, antwortet der Microsoft-Server ja auch eindeutig. Also Kommunikation bis dahin an sich funktioniert meiner Meinung nach einwandfrei. Habe auch schon mit deaktivierter Firewall die Testmail gesendet, selbes Ergebnis. Dem Walkthrough gemäß deinem Link ("How to configure ...") folgend habe ich die Richtigkeit der Server-Kontaktinformation (Serveradresse, Port, etc.) bestätigen können. Was mich aber wundert: habt ihr bei euch auch den "On-prem SMTP server" eingerichtet und dann in der SQL Server-Einstellung auf localhost verwiesen? Genau das soll doch der SQL Server selbst schon können oder nicht? Warum den Umweg über den zusätzlichen On prem SMTP Server? Das verschiebt doch nur das Problem zu diesem hin, oder nicht? @testperson: Nein, lokal gibt es kein Mailrelay. Wir betreiben keinen eigenen Mailserver. Die Lieferung soll direkt an den Office365-Server erfolgen (und müsste nach meinem Denken ja auch funktionieren). Verzeihung, wenn ich mich wiederhole: aber: schicke ich eine Mail vom selben Server über Powershell über Port 587 raus, dann funktioniert dies einwandfrei! Ich vermute, der SQL-Server selbst kocht mit anderem Wasser. Irgendwo fehlt da noch eine Einstellung (z.B. in der Registry oder in der exe-Konfigdatei??), wo die richtige Authentifzierungseinstellung aufgezwungen wird. (Vermutung!). Was macht Powershell richtig, was der SQL-Server falsch macht??

Hallo zusammen, ich bin der Nutzer LTTG; darf aber plötzlich keine Nachrichten mehr als dieser senden. Wie kontaktiere ich einen Forum-Admin, um meine Berechtigungen zu überprüfen? Weil mir das eigentliche Problem wichtiger ist, habe ich zunächst mal auf die Schnelle hiermit einen neuen Account im MCSEboard angelegt. @Sunny61: Ja, sehr gerne. Bitte schau mal nach! Ich habe folgende Einstellungen gewählt: E-Mail-Adresse: einkauf@{unsere_Domain}.de Anzeigename: {unser gewünschter Anzeigename} Antwort-E-Mail: einkauf@{unsere_Domain}.de Servername: smtp.office365.com Port: 587 Für diesen Server is ein Sicherung Verbindung (SSL) erfrderlich: Aktiviert SMPT-Authentifizierung: Standard-Authentifizierung Benutzername: einkauf@{unsere_Domain}.de Kennwort: {Kennwort} @t-sql: Hier mal ein Log-Eintrag aus der Tabelle dbo.sysmail_log aus der msdb-Systemdatenbank: log_id event_type log_date description process_id mailitem_id account_id last_mod_date last_mod_user 389 3 2022-08-09 13:58:42.727 Die E-Mail konnte wegen einem Fehler beim Mailserver nicht an die Empfänger gesendet werden. (E-Mail unter Verwendung des Kontos 2 (2022-08-09T13:58:42) senden. Ausnahmemeldung: E-Mails können nicht an den Mailserver gesendet werden. (Fehler beim Senden von Mail.). ) 5028 119 NULL 2022-08-09 13:58:42.727 sa War dies gemeint? Oder habe ich noch an einer falschen Stelle geschaut? Vielen Dank weiterhin für eure Unterstützung!!