Ich hab das Problem gefunden und auch die Lösung. Lag eigentlich nur an zwei Punkten die mir gefehlt hatten:
1) beim SQL-Server in Remoteverwaltungsbenutzer die Brokers mit eintragen
2) den SQL String mit geschweiften Klammern und dem ODBC Driver 18 for SQL Server nutzen und den Parameter TrustedCertificate=yes mit einbauen.
Der Fehler mit 15353 und der Sicherheitsgruppe ist nur entstanden, weil ich die neue Datenbank gleich mit der Gruppe anlegen wollte. Wird die Datenbank angelegt und nachträglich auf den dbowner der Gruppe gesetzt ist alles gut.
kurze Szenarioschilderung:
Lokales AD soll mit Azure AD synchronisiert werden. Dazu hab ich das Azure AD Connect Tool auf einen Server installiert und alle Daten gem. Assistent eingetragen.
Ergebnis am Ende des Tools - Synchronisierung wird durchgeführt.
Danach bin ich mit dem Administratorkonto auf das Admin365-Portal und wollte prüfen ob die User ankommen. War auch der Fall, aber nicht alle, bzw. eher nur ein kleiner Teil der User wurde synchronisiert, der Rest erhält die Fehlermeldung:
"Microsoft.Online.Workflows.ValidationException" - also das Tool auf dem Server nochmal gestartet und den Bereich Problembehandlung ausgewählt und einen User ausgesucht, der nicht ankommt.
Ergebnis der Prüfung: AD Connector Space wird grün angezeigt, auch Metaverse und AAD Connector Space. Danach wird die Attribute Filtering configuration geprüft, der erste Eintrag ist OK, der zweite dann Rot mit diesem Wert:
Object "CN={69424B683...}" has export error(s)
Der nachfolgende Connection to Azure AD Tenant ist wieder OK.
Also werf ich einen Blick in das erstellte Log. Hier sehe ich aber nichts, was mir den Fehler verrät. Im Bereich On-Premises Active Directory sieht alles ganz normal aus. Im zweiten Bereich AADConnect Database sieht auch alles unverdächtig aus.
accountEnabled ist true, ein sourceAnchor ist gesetzt. Die restlichen Eintragungen stimmen mit dem ersten Abschnitt über ein. Führe ich nur eine Diagnose nach den Attribute Synchronization Issue durch, erhalte ich alles in grün - also keinen direkten Fehler.
Danach hab ich über Azure AD den Provisioning Client runtergeladen und eingerichtet, sowie eine Konfiguration ins Azure AD eingetragen. Diese wurde anfänglich als fehlerfrei markiert, bis die Synchronisierung durch war, danach kam die Fehlermeldung das die Synchronisierung in Quarantäne gestellt wurde.
Frage ist, wie finde ich heraus, warum das System sich weigert bestimmte User zu importieren?
Kommando zurück - Fehler wurde gefunden. Wir setzen für unser Netzwerk einen Provider ein, dessen Firewall war ausgelastet und hat den ganzen Traffic blockiert.
@NorbertFe: Speicherplatz ist aktuell noch vorhanden, wird aber langsam etwas enger, nur noch 30 GByte frei. Kann man eigentlich unter Exchange 2013 die Datenbanken mit einem Tool bereinigen, wie früher auch bei 2007/2010?
Gerade wenn wir Postfächer löschen oder Mails archivieren, ich hab den Eindruck die Datenbank bleibt so groß wie sie ist.
@Nobbyaushb: Merkwürdig, da sie zwar Fehler anzeigen, aber eigentlich schon seit einiger Zeit auftreten, aber durch diese Problem heute, muss sich dann noch was zusätzlich im Log aufgebauscht haben. Überwiegend zum Bspl das usbperf Log mit dem Verweis das ein Zugriff auf einige Systeme länger gedauert haben als normal. Ich beobachte jetzt erstmal, ob sich alles wieder einpegelt und wenn nicht, geh ich die Meldungen einzeln durch. Meld mich dann dazu aber noch mal separat.
Forseti2003's post in SQL Connection String für Verbindungsbroker wurde als beste Lösung markiert.