Neu Probleme beim Verbinden mit SQL Server von Arbeitsplatzrechner

[Pucci]

Hallo,
ich wollte die Wawi auf einem Haupt-Pc installieren und anschließend dann auf einem anderen Arbeitsplatz, welcher auf die Datenbank des Haupt-PCs zugreift.
Auf dem Haupt PC kann ich nach Installation die Datenbank ohne Probleme öffnen, aber auf dem anderen Arbeitsplatz komischerweise nicht. Die PCs sind beide im gleichen Netzwerk.
Ich habe dann selbstverständlich mich durchs Forum gewühlt, wurde aber einfach nicht schlau. Als Servername habe ich den namen des pc (so wie es auch in den tutorials erklärt wird) angegeben. Dann \JTLWAWI (die instanz heißt auch zu 100% so) und das hat nicht funktioniert. Anschließend dann mit dem Port. Also PCName,Port\JTLWAWI
das hat auch nicht funktioniert. Letzten Endes habe ich es auch mit der IP-Adresse probiert und das ging auch nicht.
TCP/IP ist aktiviert. Und die Dienste sehen folgendermaßen aus:



Hat der SQL Server-Agent was damit zu tun?


Im SQL Server Configuration Manager sieht es bei den Server-Diensten so aus:



Die Fehler Meldung bei dem anderen Arbeitsplatz sieht so aus:


Und leider weiß ich mittlerweile auch nicht mehr so richtig weiter, was ich noch ausprobieren kann. Damit das funktioniert.
Ach ja, die Antivirus-Software habe ich auch abgeschaltet.
Die JTL-Wawi Datenbankverwaltung habe ich auch als Adminstrator gestartet.

Hoffe, mir kann hier eventuell jemand weiterhelfen

 

[Christian_Röhl]

Moin, hast du den Port der DB in der Firewall freigegeben? Der Server-Agent spielt hier keine Rolle, der ist wichtig bei den zu definierenden Wartungspänen, das macht aber nur bei der Standardversion Sinn.

Bitte FW prüfen und dort den Port der DB freigeben. Vom PC aus kann man das testen telnet IP port, telnet muß aber als feature nachinstalliert werden. Gern auch PN, dann machen wir das morgen kurz per TeamViewer. Dauert 5 Min.

 

[Pucci]

Oh vielen Dank für die Antwort! das wars, jetzt hat es funktioniert!

 

[Christian_Röhl]

Oh vielen Dank für die Antwort! das wars, jetzt hat es funktioniert!

Manchmal schlägt hier die Betriebsblindheit zu "ich habe doch alles kontrolliert" - danke für das Feedback. viel Erfolg weiterhin...

 

[FitBike]

Moin, hast du den Port der DB in der Firewall freigegeben? Der Server-Agent spielt hier keine Rolle, der ist wichtig bei den zu definierenden Wartungspänen, das macht aber nur bei der Standardversion Sinn.

Bitte FW prüfen und dort den Port der DB freigeben. Vom PC aus kann man das testen telnet IP port, telnet muß aber als feature nachinstalliert werden. Gern auch PN, dann machen wir das morgen kurz per TeamViewer. Dauert 5 Min.

Hallo ich habe das gleiche Problem denke ich. Aber ich verstehe leider nur Bahnhof. würdest du mir per teamViewer helfen?

 

[Pucci]

Hallo ich habe das gleiche Problem denke ich. Aber ich verstehe leider nur Bahnhof. würdest du mir per teamViewer helfen?

Vielleicht hilft dir der Artikel: https://www.cmo.de/2015/03/04/lokal...xternen-sql-server-bei-jtl-wawi-in-der-cloud/

Als ich das, was im Abschnitt "Wer oder was darf wem oder wie? Die Windows-Firewall mit erweiterter Sicherheit." gemacht habe, hat es funktioniert.

 

[FitBike]

Vielleicht hilft dir der Artikel: https://www.cmo.de/2015/03/04/lokal...xternen-sql-server-bei-jtl-wawi-in-der-cloud/

Als ich das, was im Abschnitt "Wer oder was darf wem oder wie? Die Windows-Firewall mit erweiterter Sicherheit." gemacht habe, hat es funktioniert.

Der sql server wird mir dort nicht angezeigt

 

[ergowebshop]

Anschließend dann mit dem Port. Also PCName,Port\JTLWAWI

Vielleicht nur ein Tippfehler, aber es müsste heißen: PCName\JTLWAWI,Port
falls noch jemand das Problem hat.

Der sql server wird mir dort nicht angezeigt

Du meinst der SQL Server taucht nicht bei Firewall Regeln auf?
Na dann wie im Artikel erwähnt einen neuen Eintrag hinzufügen:

In der Liste schauen wir, ob wir einen Eintrag für den SQL-Serverzugriff entdecken. Wenn nicht, legen wir diesen Eintrag neu an. Dazu klicken wir mit der Rechten Maustaste auf den Punkt Eingehende Regeln und danach auf Neue Regel … Es öffnet sich der Assistent für neue eingehende Regel.

 

[Christian_Röhl]

Bist Du heute erreichbar? Dann gern per PN kurz ne Nummer senden. Denke gegen 14.00 wäre ich am Rechner.

 

[Kaffeeautomatenersatzteil]

Hallo, ich habe ein ähnliches Problem seit gestern.

Der DB-Server ist ein eigener Server, der über IP in der Domäne erreichbar ist, etwa so wie hier:

SRV-DBxxxxx\JTL WAWI.

Das hat Monate funktioniert, seit gestern nicht mehr.

Nach langer Suche habe ich auf dem Terminalserver und dem DB-Server die Firewalls deaktiviert
und in der Wawi ein neues DB-Profil mit der IP statt dem Namen erstellt:

192.xxx.xxx.xxx\JTLWAWI

Das funktioniert jetzt, jedoch nur bei ausgeschalteten Firewalls.

Das man die IP statt des Namens nimmt ist ja nicht weiter tragisch.
Hat evtl. noch den Vorteil, wenn der DNS mal ein Problem hat, bekommt man immer noch die Verbindung.

Gibt es irgendwo eine aktuelle Schritt für Schritt Anleitung, wie die Firewalls zu konfigurieren sind und welche Ports ggf.
auch im SQL Configurationsmanager unter TCP/IP Protokolle einzustellen sind?

Dort steht bei mir:

• unter IPAll Dynamische Ports 49720
• unter IP2 ( wo die IP 192.xxx.xxx.xxx steht ) Dymamische TCP-Ports = 0
• TCP Port = Kein Eintrag

Alle Anleitungen die ich bisher gefunden habe, sind entweder veraltet ( Windows 7 )
Oder beschreiben nur, das die Regeln entsprechend zu konfigurieren sind.

Aber die Aussage. " das dies entsprechend zu konfigurieren ist" , ist ja keine Anleitung.
Hat jemand eine Lösung ?

 

[zeroalex]

Moin,

die normalen SQL Ports wären: TCP 1433, 4022, 135, 1434, UDP 1434

Eine Anleitung für die FW findest du hier:https://docs.microsoft.com/de-de/sq...allow-sql-server-access?view=sql-server-ver16

 

[Shopworker.de]

Hallo @Kaffeeautomatenersatzteil,

wie du die Firewall korrekt einstellst steht im JTL-Guide: https://guide.jtl-software.de/jtl-w...wi-auf-mehreren-arbeitsplaetzen-installieren/

Und unter IPAll stelle ich unter

• TCP Port = Kein Eintrag

immer einen festen Port ein; am liebesten 5stellig mit einer 4 vorn

Und diesen Port musst du dann natürlich in deinem Verbindungsstring auf den Clients angeben ...dann klappts auch mit der Datenbank ...

 

[Kaffeeautomatenersatzteil]

Hallo,
vielen Dank für Eure Hilfe, das ist wirklich sehr nett das es jemand liest und auch antwortet.

Die genannte JTL Anleitung hatte ich schon gefunden, jedoch kann ich damit leider gar nichts anfangen, weil das veraltet ist.

Ich gehe davon aus, das grundsätzlich nur " Eingehende " Regeln auf dem DB Server gemeint sind.
Muss es auch eingehende/ausgehende Regeln auf dem Terminalserver geben ?

Aktuell sieht die Firewall jedenfalls ganz anders aus als in der Anleitung.
Viele Dinge können dort eingestellt werden und Häkchen gesetzt.

Für jemanden der das Tag ein / Tag aus macht ist es vermutlich schnell gelöst.

Für alle anderen stellt sich das so dar, das man das ja nicht jeden Tag sieht und sich bei manchem Haken
nicht vorstellen kann ob es richtig oder zwingend erforderlich ist.

Ich füge hier mal ein Bild an.
Das sind die eigehenden Regeln auf dem DB-Server.
Es gibt noch eine "ausgehende" für UDP-Ports auf dem DB Server.

Der Terminalserver hat gar keine SQL-Regeln.

Wer jetzt leicht verwirrt ist, dem geht es wie mir....
Den festen Port 50888 habe ich selbst hinzugefügt, auch im SQL Configuration Manager unter IPAll

Das hat aber nicht geholfen.

Ich vermute, ein Windows Security Update für Defender hat mir am Mittwoch Abend etwas verändert, was dazu führte,
das dann keine Datenbankverbindung mehr ausgebaut werden konnte.

 

[zeroalex]

Hallo,

schau bitte mal nach dem Firewall Profil, nicht das dies auf Öffentlich steht. Das passiert hier und da mal nach einem Update.

 

[Kaffeeautomatenersatzteil]

Hallo an Alle, die dieses Thema verfolgen.

Ich habe mittlerweile eine Lösung für die Firewall auf dem externen DB-Server gefunden, die zumindest funktioniert.
Den Port 50888 habe ich im SQL-Konfugurationsmanager unter

-> SQL Server Netzwerkkofiguration -> Protokolle für JTLWAWI -> TCP/IP -> -IP-Adressen -> IPAll eingetragen.
bei Dynamische TCP-Ports eine 0 ( Null ) um die Verwendung dynamischer Ports zu erlauben.

Ob dies die beste und vor allem eine sichere Lösung ist, kann ich nicht beurteilen.
Ich glaube das geht noch besser, vor allem Dynamische Ports unter IPAll könnten mit den Reglen möglicherweise unsinnig sein.

Für eingehende Reglen habe ich lokale Ports verwendet, für ausgehende die Remoteports.

In Anleitungen steht oft nur das Ports freigegeben werden müssen, aber Angaben ob ein.- oder ausgehende Regeln gemeint sind,
welche davon erforderlich und in welcher Regel lokale ports oder remote-ports eingestellt werden müssen habe ich leider nicht gefunden.

Sobald ich in den Reglen zusätzlich die sqlserv.exe als zugelassenes Programm eintrage, geht in der WaWi auf dem Terminalserver nichts mehr:
Wenn jemand sieht was hier grundsätzlich falsch ist oder besser gemacht werden kann, bitte hier posten, dann haben alle Leser etwas davon.

Ich wünsche Allen eine schöne Woche...

 

[ergowebshop]

Hallo.
Bei dynamische Ports eine 0 einzutragen führt zu genau dem was das Wort und die Beschreibung darunter sagt, dynamisch, also einen immer wechselnden Port. Deswegen ging es bei dir womöglich Monate lang und jetzt nicht mehr.

Wir haben den sog. dynamischen Port fest eingetragen unter IPAll und in der Firewall und so funktioniert das seit Monaten. Es reicht auch eine Regel mit lokalem Port und nur TCP. In unserem Fall auf einem Windows Server 2016 mit SQL Server 2017 ist das übrigens.

Bei dir dann halt entsprechend mit Port 50888.

Vielleicht nur ein Tippfehler, aber der SQL Server heißt sqlservr.exe, nicht sqlserv.exe

 

[Kaffeeautomatenersatzteil]

Hallo Ergowebshop,

danke für die " Inspiration "... Das funktioniert.

Ich kann bei " Eingehende Regeln " für die TCP Ports 1433, 50xxx jetzt auch den Pfad zur sqlsevr.exe ( war ein Tippfehler von mir )
als zugelassenes Programm eintragen. Die Wawi meckert hier nicht...

Die Eingehende Regel UDP Port 1434 habe ich erstmal aktiv gelassen, funktioniert aber nicht mit den Pfad zur sqlsevr.exe.
wenn ich dort den Pfad zur sqlsevr.exe eintrage, findet die Wawi die Datenbank nicht. Den UDP Port 1434 ( Eingehende Regel )
braucht also nach meiner Einschätzung eine oder eine weitere Anwendung.

Die 2 ausgehenden Regeln ( die für TCP Port und die Regel für UDP Port ) habe ich auch zunächst drin gelassen,
aber auch die Ports wie oben geändert und lokale Ports statt Remote Ports gewählt. Auch das funktioniert.

Bei den 2 "ausgehenden Regeln" habe ich beliebige Programme zugelassen.
Eine Beschränkung auf die sqlsevr.exe habe ich nicht getestet.

Schöne Grüße an alle Leser, hoffentlich können hier weitere User profitieren
und Ihre Verbindung zur Datenbank wiederherstellen, falls Diese mal nicht geht.

 

[ergowebshop]

Auf 1434 horcht für gewöhnlich der sog. SQL Server Browser für benannte Instanzen.

Die Idee ist das alle Clients sagen "ich will auf Server XYZ, Instanz JTLWAWI", dann fragen die bei XYZ auf Port 1434 und der Server sucht die Instanz raus, man muss dann nicht mit dynamischen Ports hantieren. Also wenn du nur auf "192.xxx.xxx.xxx\JTLWAWI" gehst ohne Portangabe, ja dann kann es sein, dass er die 1434 braucht, dann muss aber afaik auch im SQL Server Configuration Manager der Dienst dazu aktiviert sein.

Gib einfach den Port mit an und gut. 😅 Wir haben auch "beliebiges Programm" in der Regel und nicht nur auf die Exe beschränkt.

 

[Kaffeeautomatenersatzteil]

Vielen Dank.

Ich habe zum besseren Verständnis aktuell noch diese weiterführenden Erklärungen von Microsoft gelesen:
https://docs.microsoft.com/de-de/sq...atabase-engine-and-ssas?view=sql-server-ver16

Das Thema ist schon sehr viel umfangreicher, als man es sich vorher denkt.
Jetzt verstehe ich auch , das es nicht mal eben so gemacht ist und das es hier viele Abhängigkeiten und Möglichkeiten gibt.

Grüße

 

[Garten-Fuxx]

Hallo Zusammen,
ich bräuchte dringend Hilfe, bzw. Rat und Unterstützung.
Wir waren jetzt im Weihnachtsurlaub und nun wollten wir wieder in die Arbeitswelt starten. Jedoch haben wir das Problem, dass unser Client den Server nicht mehr findet.
Bevor wir in Urlaub gingen, hat alles Reibungslos funktioniert und nun geht nichts mehr. Der Server läuft und läßt sich auch problemlos öffnen. Der Client findet aber den Server nicht mehr, und wir bekommen die folgende Fehlermeldung:


Es hat sich der Konfiguration nicht geändert, bzw. es wurde nichts verändert.

Wer könnte mir bitte helfen?

LG
Stefan