Jump to content

LTTG

Members
  • Gesamte Inhalte

    1
  • Registriert seit

  • Letzter Besuch

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von LTTG

Newbie

Newbie (1/14)

  • Erster eigener Beitrag

Neueste Abzeichen

0

Reputation in der Community

  1. 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.
×
×
  • Neu erstellen...