LTTG 0 Geschrieben 9. August 2022 Melden Teilen Geschrieben 9. August 2022 Sehr geehrte SQL-Server-Experten, nachdem viel Recherche und viele Versuche mein Problem nicht lösen konnten, bitte ich hier einmal um Experten-Rat. Gegeben ist ein SQL-Server 2012 SP4 V 11.0.7507 auf einem Windows Server 2012 R2 mit aktuellem Patch-Level und .NET Framework 4.8. Wir möchten die im SQL-Server integrierte Datenbank-E-Mail-Funktion nutzen, um über zwei verschiedene Office365-Mail-Adressen E-Mails aus dem SQL-Server heraus zu versenden. Beide Office 365-Adressen haben Lizenz-technisch einen „Exchange Online Plan 1“ (also sind jeweils eine „vollwertige eigenständige“ Mailbox) sowie ist im Office Admin Center für beide Adressen das authentifizierte SMTP aktiviert. SMTP soll laut Angabe Microsoft über den Server smtp.office365.com mittels TLS 1.2 und Port 587 erfolgen. Nutzername und Passwort wurden zigmal auf etwaige Tippfehler hin geprüft. Im E-Mail-Einstellfenster des SQL Management Studios ist nebst Port-Nummer 587 auch die Option „Für diesen Server ist eine sichere Verbindung (SSL) erforderlich“ angehakt sowie Standardauthentifizierung gewählt. Als Nutzername ist die vollständige Mail-Adresse eingetragen. Beim Versuch, über das SQL Management Studio eine Testmail zu senden, erhalte ich laut Protokoll die leider wenig aussagekräftige Fehlermeldung „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. (Fehler beim Senden von Mail.).“ Das ist alles. Kein Fehler-Code oder sonstiges. Ich möchte den Fehler „im SQL drin“ vermuten, denn: - Ich konnte beide Mail-Adressen fehlerfrei in einem Mozilla Thunderbird einrichten und problemlos Mails versenden und empfangen - Ich kann über die Powershell vom selben SQL Server aus problemlos eine Test-Mail über Port 587 senden (auch als Nutzer ohne Admin-Rechte am Server) Dadurch meine ich, etwaige Port- oder Firewall-Probleme ausschließen zu können (der Vollständigkeit habe ich natürlich dennoch bereits mit testweise komplett deaktivierter Firewall getestet gehabt). „Irgendwas“ macht der SQL-Server selbst anders. Laut Online-Recherche zu obiger wenig aussagekräftige Fehlermeldung würde die falsche TLS-Version genutzt werden. Frage ich über Powershell, welches TLS-Version Windows nutzt, wird artig TLS 1.2 geantwortet (sonst würde zudem ja auch der Test-Versand über Powershell nicht funktionieren). Folgende Dinge habe ich erfolglos probiert: Registry-Schlüssel angelegt/angepasst: HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319: DWord “SchUseStrongCrypto” mit Wert 1 HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319: DWord “SchUseStrongCrypto” mit Wert 1 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 In einem weiteren Vorschlag soll die zu verwendende .NET Framework-Version durch die DatabaseMail-Exe über das dazugehörige exe.config File im Ordner Microsoft SQL Server\MSSQL11.xxxx\MSSQL\Binn geprüft werden. Eine etwaige exe.config-Datei konnte ich in diesem Verzeichnis jedoch nicht finden. Hat jemand eine Idee, was wir noch probieren könnten / was wir übersehen haben? Vielen Dank im Voraus für die Hilfe! PS: Dass 2012er Systeme nächstes Jahr aus dem Support fallen, ist klar und Ersatz ist bereits für Jahresende angedacht. Das Problem besteht aber jetzt und mit dem noch aktuellen System. Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 9. August 2022 Melden Teilen Geschrieben 9. August 2022 Ich kann morgen an einem SQL 2017 nachsehen wie dort die Einstellungen aussehen. Wenn das dann noch reicht, gib bitte kurzes Feedback. ;) Zitieren Link zu diesem Kommentar
t-sql 18 Geschrieben 9. August 2022 Melden Teilen Geschrieben 9. August 2022 Was hier erstmal fehlt sind die Ausgaben aus dem Errorlog. Was steht denn da drin? Was geben denn die passen Systemviews zu Database Mail aus? Siehe hier Database Mail Views (Transact-SQL) - SQL Server | Microsoft Docs Zitieren Link zu diesem Kommentar
LTTG2 1 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 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!! Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 vor 12 Minuten schrieb LTTG2: SMPT-Authentifizierung: Standard-Authentifizierung https://docs.microsoft.com/de-de/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 vor 38 Minuten schrieb LTTG2: Für diesen Server is ein Sicherung Verbindung (SSL) erfrderlich: Aktiviert Das ist bei mir NICHT aktiviert, Port 587 wird verwendet. Zitieren Link zu diesem Kommentar
t-sql 18 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 ok. Kommst Du überhaupt von deinem SQL Server Server zu smtp.office365.com Port 587 hin oder wird da was von einer Firewall geblockt? Außerdem hab ich noch den Artikel How to configure SQL Database mail so send emails using Office 365 (Exchange Online): A walkthrough | Microsoft Docs gefunden. Zitieren Link zu diesem Kommentar
testperson 1.677 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 Hi, evtl. mal anders ans Problem rangehen: Gibt es lokal kein Mailrelay (Exchange, anderer Mailserver, Firewall, o.ä.), wo du einlieferst und wo dann "einfach" an Exchange online relayed wird? Gruß Jan Zitieren Link zu diesem Kommentar
LTTG2 1 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 @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?? Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 Wie genau sieht das PS-Script denn aus? Gibt es wirklich keinen Unterschied zwischen PS und SQL Script? BTW: Hier steht ein OnPrem Exchange 2016 der die Mails annimmt. Zitieren Link zu diesem Kommentar
LTTG2 1 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 @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/ Zitieren Link zu diesem Kommentar
t-sql 18 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 (bearbeitet) Ich würde jetzt mal mit Wireshark mit sniffen wenn Du aus dem SQL Server verschickst. BTW. Du benutzt hoffentlich beim testen das korrekte Mail Profil? Gerade noch was interessantes gefunden: Enable TLS 1.2 for SQL Server 2016 database mail - Database Administrators Stack Exchange und dort die Antwort vom MS Support bearbeitet 10. August 2022 von t-sql Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 vor einer Stunde schrieb Sunny61: Gibt es wirklich keinen Unterschied zwischen PS und SQL Script? Zitieren Link zu diesem Kommentar
t-sql 18 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 vor 2 Stunden schrieb Sunny61: Gibt es wirklich keinen Unterschied zwischen PS und SQL Script? Doch gibt es. Das eine is Powershell und das andere T-SQL ;-). T-SQL selbst verschickt keine Mails. Das wird das Database Mail Subsystem übergeben. Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 10. August 2022 Melden Teilen Geschrieben 10. August 2022 vor 55 Minuten schrieb t-sql: Doch gibt es. Das eine is Powershell und das andere T-SQL ;-). T-SQL selbst verschickt keine Mails. Das wird das Database Mail Subsystem übergeben. Ich meine etwas anderes, der TO weiß sicherlich was ich meine. ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.