13
Windows-Firewall und Logging wegen SQL-Problem
Servus zusammen, mal wieder eine andere Baustelle...
Server 2012
Format-Software - WUP
Es wird eine Exe aus einer Freigabe geöffnet.
Die Einstellung in der Software für den SQL sind: (Da ich keine Ahnung von SQL habe, ist das shared-Pipe ?)
Lokal auf der Maschine (Server01) funktioniert es. Egal ob von D:\ oder der Freigabe gestartet.
Von einem 2ten PC aus ist die Windows-Firewall von Server01 im Weg.
Ich habe an der Windows-Firewall folgendes freigeschaltet:
Normalerweise müsste für SQL TCP 1433 ausreichend sein. Tut aber nicht. Wenn ich die FW deaktiviere klappt der Zugriff.
Jetzt habe ich das Logging der FW für verworfene Pakete aktiviert. Aber das Log hat 1kB und selbst wenn ich mit Nmap von einer zweiten Maschine einen Port-Scan auf den Server mache, so entstehen dort keine Eintrage. Selbst wenn ich erfolgreiche Verbindungen mit aktiviere, schreibt der nix ins Log ?
Wenn shared pipe... das wird über UDP 137,139 und TCP 445 abgewickelt, diese Ports sind auf der FW offen.
Jedoch habe ich keinen listen Port 137 UDP auf dem Server ?
Was übersehe ich ?
Grüße, Henere
EDIT: Falschen Screenshot gepostet
Server 2012
Format-Software - WUP
Es wird eine Exe aus einer Freigabe geöffnet.
Die Einstellung in der Software für den SQL sind: (Da ich keine Ahnung von SQL habe, ist das shared-Pipe ?)
Data Source=SERVER01\SQLEXPRESS;Initial Catalog=FormatWUPLokal auf der Maschine (Server01) funktioniert es. Egal ob von D:\ oder der Freigabe gestartet.
Von einem 2ten PC aus ist die Windows-Firewall von Server01 im Weg.
Ich habe an der Windows-Firewall folgendes freigeschaltet:
Normalerweise müsste für SQL TCP 1433 ausreichend sein. Tut aber nicht. Wenn ich die FW deaktiviere klappt der Zugriff.
Jetzt habe ich das Logging der FW für verworfene Pakete aktiviert. Aber das Log hat 1kB und selbst wenn ich mit Nmap von einer zweiten Maschine einen Port-Scan auf den Server mache, so entstehen dort keine Eintrage. Selbst wenn ich erfolgreiche Verbindungen mit aktiviere, schreibt der nix ins Log ?
Wenn shared pipe... das wird über UDP 137,139 und TCP 445 abgewickelt, diese Ports sind auf der FW offen.
Jedoch habe ich keinen listen Port 137 UDP auf dem Server ?
Was übersehe ich ?
Grüße, Henere
EDIT: Falschen Screenshot gepostet
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 385671
Url: https://administrator.de/contentid/385671
Printed on: April 25, 2024 at 20:04 o'clock
13 Comments
Latest comment
Hallo,
Da wird dir geholfen
Gruß,
Peter
Da wird dir geholfen
Max-Planck-Straße 25
63303 Dreieich
Telefon 0 61 03 / 93 09-0
Telefax 0 61 03/34659
info@formatsoftware.de
www.formatsoftware.de(Da ich keine Ahnung von SQL habe, ist das shared-Pipe ?)
Named-Pipe auf der lokalen Maschine wenn du magst, ansonsten TCPIPLokal auf der Maschine (Server01) funktioniert es.
Vermutlich named-pipesVon einem 2ten PC aus ist die Windows-Firewall von Server01 im Weg.
Mit welchen Ports läuft denn deine SQL Express Instanz für dieses PRG? Du weisst ja, es kann nur einer eine bestimmten Port abhören, nicht mehrere.Normalerweise müsste für SQL TCP 1433 ausreichend sein. Tut aber nicht. Wenn ich die FW deaktiviere klappt der Zugriff.
Müsste, mosste, müsste. Tutu aber nicht. Jede Instanz braucht einen anderen Port. Nur die erste oder einzigste SQL Instanz kann auf 1433 horchen wenn nichts anderes daruf horcht. Mit deine SQ Instanz sind auch Werkzeuge für die Konfiguration mit aiuf dein Rechner gelangt. Nutze diese. z.B. den SQL Server 2016-Konfigurations-ManagerWas übersehe ich ?
Sich mit den SQL Grundlagen erstmal zu beschäftigen. Haben sich seit SQL Server 2000 nicht so wahnsinnig geändert, nur viel neues dazugekommenSelbst wenn ich erfolgreiche Verbindungen mit aktiviere, schreibt der nix ins Log
Wird dein Name denn überhaupt Richtig aufgelöst bzw. den tatsächlichen FQDN nutzen? Dann nutzen deine Anfrgaen kein TCPIP.Gruß,
Peter
Hallo Peter,
wenn die Format-Hotline nicht erst jedes Mal Rücksprache mit den Entwicklern halten müsste....... Ich hatte heute schon 2h mit denen das Vergnügen.... Ticket ist dennoch offen bei denen.
Ich bin mir aber sicher, dass ihr Spezialisten hier einfach schneller und besser seid !
Ich dachte mir jetzt, das bekommst auch alleine hin, auch ohne SQL Kenntnisse. Und vor allem ohne deren Hotline.
Stand ist: Es ist bis vor 2 oder 3 Wochen gelaufen. Gestern bemerkt der Kunde, dass die Anmeldung nicht mehr funktioniert. Frag mich bitte nicht, warum er 2-3 Wochen die Anwendung nicht genutzt hat. (Sanktionsmonitor.... ein Grauen vor dem Herrn.)
Im Test mit der Format-Hotline hatte ich heute die FW auf Server01 deaktiviert, und schon ging die Anwendung.
Darum kann ich Namensauflösung und anderes ausschliessen.
Es ist ein reines Windows-Firewall-Problem. Und wenn das Drecks-Onboard-FW-Teil loggen würde, was es macht, dann hätte ich diese Frage hier nicht gestellt. (Ich will meine Checkpoint 4.1 wieder haben!)
Die Wondows-Firewall loggt mir gar nichts. Null und noch weniger. Das einzige was sie in das Log schreibt:
Mehr steht ums verrecken nicht drin. FW-Dienst neu gestartet, macht keinen Unterschied. Er legt das Log-File an, schreibt aber nur die Überschrift rein. Oder muss ich irgendwo die Überwachung noch aktivieren ? Ich denke hier an NTFS-Logging.
Ich kann derzeit kein dort Wireshark installieren um zu sehen, wo es hängt.
Grüße, Henere
wenn die Format-Hotline nicht erst jedes Mal Rücksprache mit den Entwicklern halten müsste....... Ich hatte heute schon 2h mit denen das Vergnügen.... Ticket ist dennoch offen bei denen.
Ich bin mir aber sicher, dass ihr Spezialisten hier einfach schneller und besser seid !
Ich dachte mir jetzt, das bekommst auch alleine hin, auch ohne SQL Kenntnisse. Und vor allem ohne deren Hotline.
Stand ist: Es ist bis vor 2 oder 3 Wochen gelaufen. Gestern bemerkt der Kunde, dass die Anmeldung nicht mehr funktioniert. Frag mich bitte nicht, warum er 2-3 Wochen die Anwendung nicht genutzt hat. (Sanktionsmonitor.... ein Grauen vor dem Herrn.)
Im Test mit der Format-Hotline hatte ich heute die FW auf Server01 deaktiviert, und schon ging die Anwendung.
Darum kann ich Namensauflösung und anderes ausschliessen.
Es ist ein reines Windows-Firewall-Problem. Und wenn das Drecks-Onboard-FW-Teil loggen würde, was es macht, dann hätte ich diese Frage hier nicht gestellt. (Ich will meine Checkpoint 4.1 wieder haben!)
Die Wondows-Firewall loggt mir gar nichts. Null und noch weniger. Das einzige was sie in das Log schreibt:
#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info pathMehr steht ums verrecken nicht drin. FW-Dienst neu gestartet, macht keinen Unterschied. Er legt das Log-File an, schreibt aber nur die Überschrift rein. Oder muss ich irgendwo die Überwachung noch aktivieren ? Ich denke hier an NTFS-Logging.
Ich kann derzeit kein dort Wireshark installieren um zu sehen, wo es hängt.
Grüße, Henere
Hallo,
Die ärmsten...
Gruß,
Peter
Die ärmsten...
Im Test mit der Format-Hotline hatte ich heute die FW auf Server01 deaktiviert, und schon ging die Anwendung.
Dann wird definitiv TCPIP genutzt Es ist ein reines Windows-Firewall-Problem.
Dann ist Wireshark dein Werkzeug.(Ich will meine Checkpoint 4.1 wieder haben!)
Und was hat die jetzt mit den Datenverkehr innerhalb deines LANs zu tun?Mehr steht ums verrecken nicht drin.
Dann machst du was falsch...Oder muss ich irgendwo die Überwachung noch aktivieren ?
Nö, warum?Ich kann derzeit kein dort Wireshark installieren um zu sehen, wo es hängt.
Dann nimm Wireshark Portable https://www.wireshark.org/download.htmlGruß,
Peter
Servus,
so ganz komme ich mit Wireshark nicht weiter. Es ist zuviel Traffic. Und filtern nach Programm geht wohl nicht, oder lese ich das falsch ?
Ich habe mit dem ResMon nach aktiven Verbindungen geschaut. Das einzige was ich dann sehe, ist eine Verbindung auf Port TCP 60490 von Server01. Den Port auf der FW freigeschaltet, keine Änderung.
Im SQL-Conf-mgr sehe ich auch keine Portbindungen für den SQLEXPRESS.
Und das ist je genau der, den mir Resmon auch anzeigt. Nur bringt mir die Freischaltung TCP 60490 im FW-Profil nichts. Es kann bei aktivierter FW immer noch keine Verbindung hergestellt werden. Ich denke, das kommt wegen "dynamischen Ports".
Was mache ich denn falsch mit dem Logging der Windows-Firewall ?
Wo außer hier, kann ich das logging aktivieren ?
Grüße, Henere
(Mit CP 4.1 meinte ich, dass ich diese GUI und vor allem deren logging wiederhaben möchte.)
Mir graust es vor dem Windows-Teil.
so ganz komme ich mit Wireshark nicht weiter. Es ist zuviel Traffic. Und filtern nach Programm geht wohl nicht, oder lese ich das falsch ?
Ich habe mit dem ResMon nach aktiven Verbindungen geschaut. Das einzige was ich dann sehe, ist eine Verbindung auf Port TCP 60490 von Server01. Den Port auf der FW freigeschaltet, keine Änderung.
Im SQL-Conf-mgr sehe ich auch keine Portbindungen für den SQLEXPRESS.
Und das ist je genau der, den mir Resmon auch anzeigt. Nur bringt mir die Freischaltung TCP 60490 im FW-Profil nichts. Es kann bei aktivierter FW immer noch keine Verbindung hergestellt werden. Ich denke, das kommt wegen "dynamischen Ports".
Was mache ich denn falsch mit dem Logging der Windows-Firewall ?
Wo außer hier, kann ich das logging aktivieren ?
Grüße, Henere
(Mit CP 4.1 meinte ich, dass ich diese GUI und vor allem deren logging wiederhaben möchte.)
Mir graust es vor dem Windows-Teil.
Moin,
schau' Dir bitte mal im Konfigurationsmanager für den SQL Server an, welche Dienste laufen.
Dann die Native Client Konfiguration und Server Netzwerk Konfiguration.
Stimmen die Protokolle überein.
Ist das Domänenprofil an der Netzwerkkarte aktiv, oder hat sich das verstellt?
TCP und UDP 1433 in der FW erlaubt?
Gruss
schau' Dir bitte mal im Konfigurationsmanager für den SQL Server an, welche Dienste laufen.
Dann die Native Client Konfiguration und Server Netzwerk Konfiguration.
Stimmen die Protokolle überein.
Ist das Domänenprofil an der Netzwerkkarte aktiv, oder hat sich das verstellt?
TCP und UDP 1433 in der FW erlaubt?
Gruss
Hallo,
Schau mal ins errorlog deiner MS SQL Server Instanz was dort steht? z.B.
Wenn dort nichts steht, hört deine MS SQL Server Instanz auch auf nichts (TCPIP) Oben siehst du das auf TCPIP Port 1433 für IPv6 und für IPv4 gelauscht wird, ebenso auf named pipes.
Und es scheint das du noch einen MS SQL Server 2005 nutzen tust, oder?
https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/c ...
Gruß,
Peter
Zitat von @Henere:
so ganz komme ich mit Wireshark nicht weiter. Es ist zuviel Traffic. Und filtern nach Programm geht wohl nicht, oder lese ich das falsch ?
Nee, das geht nicht. Aber du hast doch den Port, nimm den (1433 UDP/TCP)so ganz komme ich mit Wireshark nicht weiter. Es ist zuviel Traffic. Und filtern nach Programm geht wohl nicht, oder lese ich das falsch ?
Ich habe mit dem ResMon nach aktiven Verbindungen geschaut. Das einzige was ich dann sehe, ist eine Verbindung auf Port TCP 60490 von Server01. Den Port auf der FW freigeschaltet, keine Änderung.
Wie wäre es wenn du einfach alle Ports für alle IPs und allen Programmen erlaubst? Da kann das Chaos auch nicht viel größer werden. Du drehst an jeder erreichbaren Schraube ohne zu wissen was du tust.Im SQL-Conf-mgr sehe ich auch keine Portbindungen für den SQLEXPRESS.
Dann ist auch kein TCPIP aktivWas mache ich denn falsch mit dem Logging der Windows-Firewall ?
Wo außer hier, kann ich das logging aktivieren ?
Schon mal darüber nachgedacht das ebene keine TCPIP versucht wird? Da kann dann auch nichts Protokolliert werden, oder?Wo außer hier, kann ich das logging aktivieren ?
Schau mal ins errorlog deiner MS SQL Server Instanz was dort steht? z.B.
2018-07-09 18:45:03.05 spid10s Server is listening on [ 'any' <ipv6> 1433].
2018-07-09 18:45:03.05 spid10s Server is listening on [ 'any' <ipv4> 1433].
2018-07-09 18:45:03.05 spid10s Server is listening on [ 'any' <ipv6> 57163].
2018-07-09 18:45:03.05 spid10s Server is listening on [ 'any' <ipv4> 57163].
2018-07-09 18:45:03.06 spid10s Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\XXL ].
2018-07-09 18:45:03.07 spid10s Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$XXL\sql\query ].
2018-07-09 18:45:03.09 spid10s SQL Server is now ready for client connections. This is an informational message; no user action is required.
Und es scheint das du noch einen MS SQL Server 2005 nutzen tust, oder?
https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/c ...
Gruß,
Peter
Hallo Henere,
ich poste mal meine Checkliste, die ich für die Programmierung der automatisierten Installation einer benannten Instanz von SQL Server für unsere Software entwickelt habe:
Grüße
Friemler
ich poste mal meine Checkliste, die ich für die Programmierung der automatisierten Installation einer benannten Instanz von SQL Server für unsere Software entwickelt habe:
- Installation im Modus für gemischte Authentifizierung (Anmeldung mit SQL Server Benutzerdaten oder per Windows-Authentifizierung).
- TCP/IP-Konnektivität ist aktiviert, damit der SQL Server über das Netzwerk erreichbar ist (lässt sich über den SQL Server Configuration Manager ermitteln:
SQL Server Network Configuration -> Protocols for SQLEXPRESS -> TCP/IP = Enabled). - Der Dienst "SQL-Server-Browser" wird automatisch gestartet, er wird für den Netzwerkzugriff auf benannte Instanzen von SQL Server benötigt (lässt sich über den SQL Server Configuration Manager ermitteln:
SQL Server Services -> SQL Server Browser -> Eigenschaften -> Registerkarte Service -> Start Mode). - In der Windows Firewall wurden alle benötigten Einstellungen vorgenommen, damit der SQL Server über das Netzwerk erreichbar ist.
- Freigabe von Port 137 UDP (NetBios Nameservice, wird für die Auflösung des Hostnamens in Arbeitsgruppen-Netzwerken benötigt)
- Freigabe von eingehenden PING-Paketen (ICMPv4, wahlweise auch ICMPv6)
- Freigabe von Port 1434 UDP (Port des SQL Server Browsers)
- Einrichten der EXE-Datei des SQL Servers als vertrauenswürdige Anwendung, erreichbar über TCP und UDP
- In Domänen-Netzwerken besteht die Möglichkeit, per Gruppenrichtlinie die Erstellung von Firewallregeln für eingehende Verbindungen zu verbieten bzw. die lokalen Regeln zu überschreiben. Diese Einstellung muss deaktiviert sein.
Grüße
Friemler
Hallo Peter,
schon alleine wenn durch das deaktivieren der Windows Firewall eine Verbindung zustande kommt, muss TCP/IP im Spiel sein.
Der TCP 1433 bringt ja nix, der ist durch die FW erlaubt.
Ich war ja erstmal auf der Suche nach dem Port. Und wie der Screenshot zeigt, lag ich wohl nicht ganz daneben.
Keine Sorge, ich bohre keine Löcher, die ich bei Mißerfolg nicht sofort wieder schließe. Und selbst wenn, ist ein offener Port an dem Server besser als eine deaktivierte Firewall, damit die User arbeiten können.
Es handelt sich um einen SQL 2012.
Ich habe von Format noch diese Anleitung bekommen, die ich heute Abend nochmal durchgehe.
Nur wie schon vorher lange durch einen Screenshot zu sehen, sind diese Regeln eingerichtet.
Grüße, Henner
schon alleine wenn durch das deaktivieren der Windows Firewall eine Verbindung zustande kommt, muss TCP/IP im Spiel sein.
Der TCP 1433 bringt ja nix, der ist durch die FW erlaubt.
Ich war ja erstmal auf der Suche nach dem Port. Und wie der Screenshot zeigt, lag ich wohl nicht ganz daneben.
Keine Sorge, ich bohre keine Löcher, die ich bei Mißerfolg nicht sofort wieder schließe. Und selbst wenn, ist ein offener Port an dem Server besser als eine deaktivierte Firewall, damit die User arbeiten können.
Es handelt sich um einen SQL 2012.
Ich habe von Format noch diese Anleitung bekommen, die ich heute Abend nochmal durchgehe.
Nur wie schon vorher lange durch einen Screenshot zu sehen, sind diese Regeln eingerichtet.
Microsoft SQL-Server verwendet standardmäßig den Port 1433, Named-Pipe kann deaktiviert werden, falls diese Option von Ihnen nicht benutzt wird.
Nach Rücksprache mit einen Kollegen, müsste noch geprüft werden, ob der SQL-Browser bei Ihrer Instanz aktiviert ist und für diesen Dienst ebenfalls eine Firewall-Ausnahme definiert ist.
Kurzfassung
Systemsteuerung | Windows-Firewall | Erweiterte Einstellungen
Eingehende Regeln | Neue Regel
Regeltyp = "Programm"
Programmpfad zum Beispiel "C:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\Binn\sqlservr.exe"
Aktion = "Verbindung zulassen" oder besser "Verbindung zulassen, wenn sie sicher ist".
Profil: In der Regel nur Domäne und/oder Privat.
Der Name ist beliebig, beispielweise "Für SQL-Server zugelassen".
Die Schritte bitte für den Browser-Dienst wiederholen, Programmpfad ist z. B. "C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe". Den jeweiligen Pfad können Sie ermitteln, indem Sie in der "Verwaltung | Dienste" die Eigenschaften der Dienste öffnen. Dort finden Sie "Pfad zur EXE-Datei". Grüße, Henner
Hallo Henere,
der Port 1433 wird vom SQL Server selbst benutzt, wenn er als Hauptinstanz installiert wird. Eine benannte Instanz benutzt einen dynamisch zugewiesenen Port und benötigt deshalb den SQL Server Browser als Vermittler, und der lauscht auf Port 1434 UDP.
Grüße
Friemler
der Port 1433 wird vom SQL Server selbst benutzt, wenn er als Hauptinstanz installiert wird. Eine benannte Instanz benutzt einen dynamisch zugewiesenen Port und benötigt deshalb den SQL Server Browser als Vermittler, und der lauscht auf Port 1434 UDP.
Grüße
Friemler
Hallo,
Da er ja gar nicht verwendet wird.
Was steht z.B. indrin. Auch wie hier ein 1433 oder was?
https://www.itprotoday.com/microsoft-sql-server/sql-server-tcp-and-udp-p ...
https://www.mssqltips.com/sqlservertip/2495/identify-sql-server-tcp-ip-p ...
Und beachte ob du mehr als die Standard Instanz (hast oder mehrere. Dann wird wie du oben bei mir siehst auch noch Dynamsche Ports angegeben z.B. Port 57153, aber die kannst du nicht verwenden, ausserdem können die sich mit jedem Start des SQL Servers ändern. Das macht dann der SQL Server Browser der über UDP 1434 angesprochen werden will.
https://stackoverflow.com/questions/39242796/how-to-check-port-1433-is-w ...
https://sqlandme.com/2013/05/01/sql-server-finding-tcp-port-number-sql-i ...
https://www.mssqltips.com/sqlservertip/2495/identify-sql-server-tcp-ip-p ...
https://www.itprotoday.com/microsoft-sql-server/sql-server-tcp-and-udp-p ...
Vielleicht ist es an der Zeit mal wieder neu anzufangen
Gruß,
Peter
Da er ja gar nicht verwendet wird.
Ich war ja erstmal auf der Suche nach dem Port. Und wie der Screenshot zeigt, lag ich wohl nicht ganz daneben.
Der wird aber auch nicht vom SQL Server direkt verwendet.Was steht z.B. in
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib\Tcp]
"TcpPort"="1433"https://www.itprotoday.com/microsoft-sql-server/sql-server-tcp-and-udp-p ...
https://www.mssqltips.com/sqlservertip/2495/identify-sql-server-tcp-ip-p ...
Und beachte ob du mehr als die Standard Instanz (hast oder mehrere. Dann wird wie du oben bei mir siehst auch noch Dynamsche Ports angegeben z.B. Port 57153, aber die kannst du nicht verwenden, ausserdem können die sich mit jedem Start des SQL Servers ändern. Das macht dann der SQL Server Browser der über UDP 1434 angesprochen werden will.
Microsoft SQL-Server verwendet standardmäßig den Port 1433, Named-Pipe kann deaktiviert werden, falls diese Option von Ihnen nicht benutzt wird.
Jau, ist so.Nach Rücksprache mit einen Kollegen, müsste noch geprüft werden, ob der SQL-Browser bei Ihrer Instanz aktiviert ist und für diesen Dienst ebenfalls eine Firewall-Ausnahme definiert ist.
Da fragst du am besten dann denjenigen der deinen SQL Server Installiert hat.https://stackoverflow.com/questions/39242796/how-to-check-port-1433-is-w ...
https://sqlandme.com/2013/05/01/sql-server-finding-tcp-port-number-sql-i ...
https://www.mssqltips.com/sqlservertip/2495/identify-sql-server-tcp-ip-p ...
https://www.itprotoday.com/microsoft-sql-server/sql-server-tcp-and-udp-p ...
Vielleicht ist es an der Zeit mal wieder neu anzufangen
Gruß,
Peter
Hi Peter,
den Schlüssel habe ich nicht.
Ich habe weder den SQL. noch die Format-Software installiert. Ich kann es nur ausbaden.
In spätestens 3 Wochen gibt es eh einen neuen Server, dann wird eine saubere Grundinstallation gemacht.
Bis dahin... mit allen Eimern das Boot vor dem Ertrinken retten. Und das meine ich ernst. So viele Baustellen, die da zum stopfen sind....
Die Ausnahmen sind in der Firewall enthalten. Sowohl Browser wie auch Server.
Was mich stutzig macht, ist ja auch, dass die FW nix loggt.
Kann das sein, dass die einfach "nen Batscher" hat ?
Ich hab jetzt mal UDP1434 zusätzlich freigeschaltet.
Trotz dem "SQLBrowser darf"..
Und siehe da.... es scheint jetzt erstmal zu funktionieren.
Ich Danke allen Beteiligten für ihre Mühen.
Wenn noch jemand ne Idee hat, warum die Drecks-Windows-FW nix loggt .... wäre ich ganz glücklich.
Danke und allen ein schönes Wochenende !!!
Henere
den Schlüssel habe ich nicht.
Ich habe weder den SQL. noch die Format-Software installiert. Ich kann es nur ausbaden.
In spätestens 3 Wochen gibt es eh einen neuen Server, dann wird eine saubere Grundinstallation gemacht.
Bis dahin... mit allen Eimern das Boot vor dem Ertrinken retten. Und das meine ich ernst. So viele Baustellen, die da zum stopfen sind....
Die Ausnahmen sind in der Firewall enthalten. Sowohl Browser wie auch Server.
Was mich stutzig macht, ist ja auch, dass die FW nix loggt.
Kann das sein, dass die einfach "nen Batscher" hat ?
Ich hab jetzt mal UDP1434 zusätzlich freigeschaltet.
Trotz dem "SQLBrowser darf"..
Und siehe da.... es scheint jetzt erstmal zu funktionieren.
Ich Danke allen Beteiligten für ihre Mühen.
Wenn noch jemand ne Idee hat, warum die Drecks-Windows-FW nix loggt .... wäre ich ganz glücklich.
Danke und allen ein schönes Wochenende !!!
Henere
Hallo @Henere,
wenn ich mich recht erinnere, muss nach dem Aktivieren des Firewall-Loggings zuerst das System neu gestartet werden, bevor das Logging funktioniert. Kann mich auch irren, ist schon 'ne Weile her, seit ich das mal benötigt habe.
In Deinem Screenshot ist oben rechts übrigens nicht der SQL Server Browser als vertrauenswürdiges Programm eingetragen sondern der SQL VSS Writer...
Grüße
Friemler
wenn ich mich recht erinnere, muss nach dem Aktivieren des Firewall-Loggings zuerst das System neu gestartet werden, bevor das Logging funktioniert. Kann mich auch irren, ist schon 'ne Weile her, seit ich das mal benötigt habe.
In Deinem Screenshot ist oben rechts übrigens nicht der SQL Server Browser als vertrauenswürdiges Programm eingetragen sondern der SQL VSS Writer...
Grüße
Friemler
Danke für den Hinweis.
Ich hatte nur auf den Fenstertitel geachtet.
Aber geht ja jetzt.
Ich halte von der bordeigenen FW eigentlich wenig. Aber ein gewisser Grundschutz sollte im Netz schon sein.
Ich Boote den nicht mehr neu. Der Anmeldedienst kommt nicht mehr von selbst hoch. NLA muss neu gestartet werden sonst meint er in keinem Dpmänennetz zu sein.
Aber in 2-3 Wochen freue ich mich darauf im laufendem Betrieb den Netzstecker zu ziehen
Henere
Ich hatte nur auf den Fenstertitel geachtet.
Aber geht ja jetzt.
Ich halte von der bordeigenen FW eigentlich wenig. Aber ein gewisser Grundschutz sollte im Netz schon sein.
Ich Boote den nicht mehr neu. Der Anmeldedienst kommt nicht mehr von selbst hoch. NLA muss neu gestartet werden sonst meint er in keinem Dpmänennetz zu sein.
Aber in 2-3 Wochen freue ich mich darauf im laufendem Betrieb den Netzstecker zu ziehen
Henere
