ak-47.2
Goto Top

SSRS Berichtsserver - Verbindung verweigert

Hallo Zusammen,

ich schlage mich seit zwei Tagen mit einem Problem rum, dass es nicht möglich ist, eine Verbindung mit dem Berichtsserver über HTTP oder HTTPs. Der Anmeldeversuch auf http://servername:80/reports wird mit einer Verbindung verweigert quittiert.

Das Problem existiert seit dem Übergang auf das neue Jahr, Änderungen, außer die üblichen Windows Patches, sind mir keine bekannt.

Zur Umgebung: Es handelt sich um einen Microsoft Server 2022 mit einem MS SQL Server 2022, der Berichtsserver ist ebenfalls der 22er, zu Testzwecken hatte ich hier mal den 19er probiert, mit dem gleichen Ergebnis.

Der Aufruf funktioniert schon auf dem Server selbst nicht, sodass das Netzwerk außen vor ist. Die notwendigen Firewallregeln für TCP/80 und TCP/443 sind vorhanden, ebenso habe ich mehrfach überprüft, dass alle Dienste laufen sowie über netsh http show urlacl überprüft, dass die URL Reservierungen vorhanden sind.

Ein Auszug sieht folgendermaßen aus:

    Reservierte URL            : http://+:80/ReportServer/
        Benutzer: NT SERVICE\SQLServerReportingServices
            Abhören: Yes
            Delegieren: No
            SDDL: D:(A;;GX;;;S-1-5-80-4050220999-2731624961-1537482082-519483261-379003301)

    Reservierte URL            : http://+:80/Reports/
        Benutzer: NT SERVICE\SQLServerReportingServices
            Abhören: Yes
            Delegieren: No
            SDDL: D:(A;;GX;;;S-1-5-80-4050220999-273162961-1537482082-519483261-379003301)

Mir ist aufgefallen, dass über Test-Netconnection -Computername "Servername" -Port 80 auf den Ports anscheinend nicht gelauscht wird. Jedenfalls wird der Test mit TCPTestSucceeded mit false quittiert.

In den Logfiles der ReportingServicesWMI steht mehrfach ReportingServicesWMI!8160!7272!2025/01/23-16:27:55!N27User!I!Attempt to reconnect to RPC server failed with hr = 0x800706b3, dazu habe ich jedoch nichts gefunden im Netz, der Dienst für RPC läuft und eine lokale Firewallregel für TCP/135 ist ebenso vorhanden.

Weiterhin steht in den logs mehrfach:

ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27UserI!GetSSLCertificateBindings: Entering method
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: There are no SSL certificate bindings
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27UserI!GetSSLCertificateBindings: Leaving method, hr = 0x1
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetVirtualDirectory: Leaving method, hr = 0x0
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetApplicationInformation: Entering method
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!AddUrlReservation: UrlString=http://+:80
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!AddUrlReservation: UrlString=http://+:80
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: Entering method
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: There are no SSL certificate bindings
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: Leaving method, hr = 0x1
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!Instance SSRS: Entering ListReserverURLS()
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetApplicationInformation: Entering method
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!AddUrlReservation: UrlString=http://+:80
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!AddUrlReservation: UrlString=http://+:80
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: Entering method
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: There are no SSL certificate bindings
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: Leaving method, hr = 0x1
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetApplicationInformation: Entering method
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!AddUrlReservation: UrlString=http://+:80
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!AddUrlReservation: UrlString=http://+:80
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: Entering method
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: There are no SSL certificate bindings
ReportingServicesWMI!8160!7180!2025/01/23-16:30:39!N27User!I!GetSSLCertificateBindings: Leaving method, hr = 0x1

Ich habe den Berichtsserver schon mehrfach neu installiert, ohne Erfolg.

Langsam gehen mir die Ideen aus, daher hoffe ich, dass ich hier neue Ansätze finden kann.

Content-ID: 670922

Url: https://administrator.de/forum/ssrs-berichtsserver-verbindung-verweigert-670922.html

Printed on: February 7, 2025 at 08:02 o'clock

aqui
aqui Jan 23, 2025 updated at 16:27:58 (UTC)
Goto Top
Ein falsches oder fehlendes SSL Server Zertifikat sorgt ja per se schonmal dafür das HTTPS dann generell wegfällt und ein Browser Zugriff so technisch nicht möglich ist. Wie auch ohne Server Zertifikat?! Da ist dann sogar eine falsche Uhrzeit (Zertifikats Ablaufdatum) irrelevant.
Wenn dann zusätzlich noch Port 80 (unverschlüsseltes HTTP) deaktiviert oder blockiert ist wie du sagst, ist damit der gesamte Browser basierte Zugriff auf den Server blockiert bzw. nicht möglich. Da muss man sich dann auch über das o.a. Server Verhalten nicht groß wundern...
AK-47.2
AK-47.2 Jan 23, 2025 updated at 16:26:43 (UTC)
Goto Top
Punkt 1) ich bin ja nicht komplett bescheuert, Verschlüsselung ohne Zertifikat ist schwierig, aber darum geht es doch gar nicht.

Punkt 2) ich habe mit keiner Silbe erwähnt, dass Port 80 deaktiviert ist, hab doch extra die URL Konfig von netsh gepostet, da steht es doch schwarz auf weiß drin. Ebenso Extra die lokalen Firewall regeln erklärt.

Also Port 80 ist offen, Zertifikat nicht notwendig, connection trotzdem refused. Das sollte schon ein Grund sein, um sich zu wundern.
Ich habe es selbstverständlich auch mit gültigem Zertifikat probiert, Ergebnis ist jedoch gleich.
mirdochegal
mirdochegal Jan 23, 2025 updated at 17:18:13 (UTC)
Goto Top
Moin,

http://+:80/ReportServer/
Hast Du mal zu Testzwecken ganz stumpf die eigene IP eingetragen? Kommt der Port dann hoch?

Gruß

Edit:
alle Dienste laufen
Sicher?
AK-47.2
AK-47.2 Jan 24, 2025 at 07:01:12 (UTC)
Goto Top
Zitat von @mirdochegal:

Moin,

http://+:80/ReportServer/
Hast Du mal zu Testzwecken ganz stumpf die eigene IP eingetragen? Kommt der Port dann hoch?

Ja, auch das habe ich geprüft, die Verbindung wird weiterhin abgelehnt face-sad
Gruß

Edit:
alle Dienste laufen
Sicher?
Fällt dir ein offensichtlicher ein, den ich vergessen haben könnte?
Sonst liste ich sie gleich nochmal auf.
mirdochegal
mirdochegal Jan 24, 2025 at 07:08:57 (UTC)
Goto Top
Ja, auch das habe ich geprüft, die Verbindung wird weiterhin abgelehnt face-sad
Ätzend.

Hängt da vielleicht ein IIS noch mit rum, der den 80er Port reserviert hat? Also mal :81 testen bspw.
Sonst liste ich sie gleich nochmal auf.
So viele dürften das ja eig. nicht sein!?

Gruß
AK-47.2
AK-47.2 Jan 24, 2025 at 09:15:57 (UTC)
Goto Top
Zitat von @mirdochegal:

Hängt da vielleicht ein IIS noch mit rum, der den 80er Port reserviert hat? Also mal :81 testen bspw.
Das habe ich auch schon probiert, die Ports umzubiegen, leider ohne Erfolg.
Ein IIS ist nicht mit an Bord.
Sonst liste ich sie gleich nochmal auf.
So viele dürften das ja eig. nicht sein!?
Die meines Wissens nach wichtigen Dienste sind die SQLServerReportingServices sowie der RPC-Dienst.
Leider finde ich in den logs auch keine aussagekräftigen Fehler außer ReportingServicesWMI!8160!7272!2025/01/23-16:27:55!N27User!I!Attempt to reconnect to RPC server failed with hr = 0x800706b3
wozu ich jedoch wiederum nichts im Netz finde.

Gruß
AK-47.2
Solution AK-47.2 Jan 30, 2025 at 10:51:22 (UTC)
Goto Top
Für den Fall, dass jemand das gleiche Schicksal ereilt und man absolut keine Lösung findet:

nach tagelangem suchen und testen mit dem Ansatz, dass der RPC-Server Probleme macht, habe ich das Problem folgendermaßen entschlüsseln können...

Powershell hat per Test-NetConnection ja bereits bestätigt, dass beide Ports nicht lauschen - per netstat -an kann man dies verifizieren.

Ich habe danach über netsh http show urlacl mir die entsprechenden Pfade anzeigen lassen, die vom SSRS automatisch hinterlegt werden. Die URLs vom SSRS habe ich dann alle gelöscht und die SSRS Konfig ein weiteres mal angestoßen, meiner Erinnerung nach hatte ich dies auch schon zuvor getan.

Nach Abschluss der SSRS Konfig hab ich per netstat -an die lauschenden Ports überprüft, mit dem Ergebnis, dass sowohl 80 als auch 443 nun bereit sind.

Nach vielem herumprobieren ist der RPC-Server nun wieder aktiv, sollte dies nicht die Lösung sein bleibt zumindestens bei Problemen remote eigentlich nur DNS.

Wie auch immer, SSRS läuft wieder rund.