SQL Server 2008 auf MS Server 2008 R2 SP1
Guten Tag Gemeinde, heute ist Sonntag und man sollte relaxen, vl hat ja
trotzdem jemend von Euch eine Idee zu meinem Problem.
Ein Kunde hat einen neuen Server bekommen. Betriebssystem MS Windows Server 2008 R2 SP1.
Der Server wurde ohne Aktive Directory eingerichtet, also als Arbeitsgruppenserver.
Darauf wurde der SQL Server 2008 (kein R2!) installiert, sowie das SP1 für diesen SQL Server.
Ich habe eine Instanz eingerichtet, diese heisst STOTAX. Über den SQL Server Konfigurator
habe ich überprüft, dass TCP/IP als Verbindungsprotokoll aktiv ist und über das MS SQL Server
Management Studio habe ich bei der Instanz überprüft, das "Remote Server Connections" erlaubt
sind. In der Server Firewall habe ich eine eingehende Regel definiert für den TCP Port 1433.
Die Instanz liess sich anstandslos mit Daten aus einer Sicherung "füttern". Ich kann auch die
Datenbanken unter der Instanz im SQL Server Management Studio sehen. Alle notwendigen Dienste
sind aktiv, also auch die SQL Instanz selbst sowie der SQL Browser.
Die Arbeitsstationen melden sich alle als Administrator am Server an, da in dieser kleinen
Arbeitsgruppe (3 Clients) keine Sicherheitsbeschränkungen gewünscht werden. Wenn jetzt eine
Anwendung, in diesem Falle Stotax, versucht vom Client-PC eine Verbindung zur SQL Datenbank aufzubauen,
kommt stets eine Fehlermeldung "Eine Verbindung zu der Datenbank ist nicht möglich". Ich habe
sowohl auf dem Server als auch auf den Client-PC die Firewall ausgeschalten. Antivirenprogramme
wurden abgeschalten,...., wir haben den gesamten Samstag "Jugend forscht" betrieben, der Fehler
erscheint, egal was ich tue.
Hat jemand von Euch eine Idee, gibt es evtl generelle Einschränkungen betreffs des Arbeits-
gruppenservers? Mir gehen ehrlich langsam die Ideen aus.
Viele Grüsse
festus
trotzdem jemend von Euch eine Idee zu meinem Problem.
Ein Kunde hat einen neuen Server bekommen. Betriebssystem MS Windows Server 2008 R2 SP1.
Der Server wurde ohne Aktive Directory eingerichtet, also als Arbeitsgruppenserver.
Darauf wurde der SQL Server 2008 (kein R2!) installiert, sowie das SP1 für diesen SQL Server.
Ich habe eine Instanz eingerichtet, diese heisst STOTAX. Über den SQL Server Konfigurator
habe ich überprüft, dass TCP/IP als Verbindungsprotokoll aktiv ist und über das MS SQL Server
Management Studio habe ich bei der Instanz überprüft, das "Remote Server Connections" erlaubt
sind. In der Server Firewall habe ich eine eingehende Regel definiert für den TCP Port 1433.
Die Instanz liess sich anstandslos mit Daten aus einer Sicherung "füttern". Ich kann auch die
Datenbanken unter der Instanz im SQL Server Management Studio sehen. Alle notwendigen Dienste
sind aktiv, also auch die SQL Instanz selbst sowie der SQL Browser.
Die Arbeitsstationen melden sich alle als Administrator am Server an, da in dieser kleinen
Arbeitsgruppe (3 Clients) keine Sicherheitsbeschränkungen gewünscht werden. Wenn jetzt eine
Anwendung, in diesem Falle Stotax, versucht vom Client-PC eine Verbindung zur SQL Datenbank aufzubauen,
kommt stets eine Fehlermeldung "Eine Verbindung zu der Datenbank ist nicht möglich". Ich habe
sowohl auf dem Server als auch auf den Client-PC die Firewall ausgeschalten. Antivirenprogramme
wurden abgeschalten,...., wir haben den gesamten Samstag "Jugend forscht" betrieben, der Fehler
erscheint, egal was ich tue.
Hat jemand von Euch eine Idee, gibt es evtl generelle Einschränkungen betreffs des Arbeits-
gruppenservers? Mir gehen ehrlich langsam die Ideen aus.
Viele Grüsse
festus
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 197312
Url: https://administrator.de/contentid/197312
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
16 Kommentare
Neuester Kommentar
Hallo festus,
versuche mal Port 1434 UDP eingehend freizugeben. Das ist der Port für den SQL Server Browser, Port 1433 ist der Port für Hauptinstanzen des SQL Servers. Für die Namensauflösung in einem Arbeitsgruppennetzwerk ist noch Port 137 UDP eingehend (NetBios Nameservice) notwendig und die EXE des SQL Servers muss als vertrauenswürdige Anwendung für TCP und UDP eingehend in der Firewall eingerichtet werden. Und teste erstmal die Anmeldung als
Reine Vermutung: In einem Arbeitsgruppennetzwerk ist die Anmeldung am SQL Server per Windows-Authentifizierung mit einem Account eines Remotecomputers nicht möglich.
Schau auch mal hier vorbei: User Account Control and SQL Server
Gruß
Friemler
versuche mal Port 1434 UDP eingehend freizugeben. Das ist der Port für den SQL Server Browser, Port 1433 ist der Port für Hauptinstanzen des SQL Servers. Für die Namensauflösung in einem Arbeitsgruppennetzwerk ist noch Port 137 UDP eingehend (NetBios Nameservice) notwendig und die EXE des SQL Servers muss als vertrauenswürdige Anwendung für TCP und UDP eingehend in der Firewall eingerichtet werden. Und teste erstmal die Anmeldung als
sa
, also mit SQL Server Anmeldeinformationen. Auch dran denken, dass bei benannten Instanzen die Syntax Rechnername\Instanzname
als Servername verwendet werden muss.Reine Vermutung: In einem Arbeitsgruppennetzwerk ist die Anmeldung am SQL Server per Windows-Authentifizierung mit einem Account eines Remotecomputers nicht möglich.
Schau auch mal hier vorbei: User Account Control and SQL Server
Gruß
Friemler
Zitat von @festus:
Hallo wiesi200,
in den Ereignisprotokollen des Servers und der Clients gibt es nichts ergüssliches was jetzt
einen Grund für die Verweigerung des Zugriffs preisgeben könnte.
Hallo wiesi200,
in den Ereignisprotokollen des Servers und der Clients gibt es nichts ergüssliches was jetzt
einen Grund für die Verweigerung des Zugriffs preisgeben könnte.
Tja, wenn nicht's ergüssliches drinnen steht, dann stellt sich für mich die Frage ob es überhaupt zu einer Anmeldung kommt.
Hatte auch im SQL Server extra einen User Administrator angelegt, hat alles nichts
gebracht. Meine Vermutung ist das durch das fehlende Active Directory irgendwelche
Anmeldungen die durch die Clientanwendung gestellt werden vom SQL Server abgewiesen
werden.
gebracht. Meine Vermutung ist das durch das fehlende Active Directory irgendwelche
Anmeldungen die durch die Clientanwendung gestellt werden vom SQL Server abgewiesen
werden.
Versuch dich mal Per SQL Authentifizierung am Server anzumelden, dass muss man aber den Client extra sagen. Da hilft's nicht wenn den Benutzer einfach gibt. Denn wenn's dann auch nicht funktioniert dann kannst du das mit dem AD ausschließen. Wobei ich zu 99,99999% der Meinung bin das es das nicht ist.
Hallo,
OK. (Von dir?)
Und auf die Frage von @wiesi200
bist du auch nicht eingegangen. Wie läuft den die Anmeldung deines Stotax Clients ab?
Und dein
Die Anmeldung an einem SQL Server/Instanz kann auf unterschiedliche Wege erfolgen. Per ODBC Connector oder direkt innerhalb der Applikation welche ihre eigene Anmeldung vornimmt. Auf jedenfall sollte aber am SQL Server ersichtlich sein ob der SQL Server und sogar welche Instanz auf welchen Port lauscht. Ein Netstat -ao oder Netstat -ano hätte dir dies schon gezeigt. Mit der PID kannst du dann sogar nachschauen ob die richtige SQL Instanz auch auf den Port 1433 hört. Error.log listet dir zu jeder Instanz auch die laufende PID mit welcher die Instanz gestart wurde auf. Ein Wireshark sagt dir dann ganz schnell ob dein SQL Server überhaupt angesprochen wird und von wem bzw. wie er angesprochen wird. (Den Wireshark kannst du sogar am Client dazu nutzen um zu sehen was dein Client macht und ob Vom SQL Server eine Antwort kommt. Nach deiner Aussage sollte ja da alles korrekt eingestellt und sonst keine Fehler vorliegen eine Ablehnung deines SQL Server kommen. Dein DNS ist schon korrekt, oder?
Gruß,
Peter
OK. (Von dir?)
Die Arbeitsstationen melden sich alle als Administrator am Server an
Als "Servername\Administrator" oder wie?Fehlermeldung "Eine Verbindung zu der Datenbank ist nicht möglich".
Findet dein Stotax den überhaupt den SQL Server? Weiß dein Stotax Client den überhaupt wie der SQL Server heißt bzw. wie die Datenbank dort sich nennt und mit welcher Authentifizierung er sich anzumelden hat?Firewall, Antivirus und "Jugend forscht". Na das kann ja was werden
erscheint, egal was ich tue.
Joa.gibt es evtl generelle Einschränkungen betreffs des Arbeitsgruppenservers?
Nein.Mir gehen ehrlich langsam die Ideen aus.
So schnell? Was soll denn dein Kunde von dir denken?in den Ereignisprotokollen des Servers und der Clients
Wirklich nicht? Auch keine Fehlerhaften Anmeldeversuche? Gar nichts? Hmmmm!Meine Vermutung
Vermutingen sind immer der sichere Hinweis auf nicht Wissen und oftmals (meistens) falsch.ist das durch das fehlende Active Directory irgendwelche anmeldungen die durch die Clientanwendung gestellt werden vom SQL Server abgewiesen werden
Ich vermute hier nicht sondern sage "Nein, ist es nicht".Und auf die Frage von @wiesi200
dann stellt sich für mich die Frage ob es überhaupt zu einer Anmeldung kommt.
Und dein
Ich kann morgen nicht lange forschen
lässt uns für deinen Kunden böses ahnen. Recht hat dein Kunde schon wenn er dafür Bezahlt das da jemand sich drum kümmert der weiß was er tut. Ist es nicht besser du holst dir Hilfe ins Haus (morgen)?Die Anmeldung an einem SQL Server/Instanz kann auf unterschiedliche Wege erfolgen. Per ODBC Connector oder direkt innerhalb der Applikation welche ihre eigene Anmeldung vornimmt. Auf jedenfall sollte aber am SQL Server ersichtlich sein ob der SQL Server und sogar welche Instanz auf welchen Port lauscht. Ein Netstat -ao oder Netstat -ano hätte dir dies schon gezeigt. Mit der PID kannst du dann sogar nachschauen ob die richtige SQL Instanz auch auf den Port 1433 hört. Error.log listet dir zu jeder Instanz auch die laufende PID mit welcher die Instanz gestart wurde auf. Ein Wireshark sagt dir dann ganz schnell ob dein SQL Server überhaupt angesprochen wird und von wem bzw. wie er angesprochen wird. (Den Wireshark kannst du sogar am Client dazu nutzen um zu sehen was dein Client macht und ob Vom SQL Server eine Antwort kommt. Nach deiner Aussage sollte ja da alles korrekt eingestellt und sonst keine Fehler vorliegen eine Ablehnung deines SQL Server kommen. Dein DNS ist schon korrekt, oder?
Gruß,
Peter
Zitat von @festus:
Vielen Dank für Eure Mühen,
es war viel, viel simpler zu lösen! Ich habe einen ODBC Connector auf dem
Clientrechner eingerichtet, welcher mir nach dem Test signalisierte, dass
der Zugriff auf die Datenbank funktioniert. Trotz der korrekten Verbindung
zum SQL Server war eine Connection zu der erwähnten Instanz nicht möglich.
Wie gesagt es ging um eine STOTAX-Installation. Wenn man in die SQL-Stotax-Datenbanken
die gesicherten Daten wieder eingepflegt hat, so befindet sich auf der
Programm-DVD in einem Tools Unterordner ein Programm Datenueb.exe. Dieses
startet man und siehe da, nach 10 Sekunden konnte der Client ganz normal
eine Verbindung zum SQL-Server aufbauen. Nun wäre natürlich die Frage
was hat dieses Tool gemacht? das konnte mir jedoch niemand veraten.
Vielen Dank für Eure Mühen,
es war viel, viel simpler zu lösen! Ich habe einen ODBC Connector auf dem
Clientrechner eingerichtet, welcher mir nach dem Test signalisierte, dass
der Zugriff auf die Datenbank funktioniert. Trotz der korrekten Verbindung
zum SQL Server war eine Connection zu der erwähnten Instanz nicht möglich.
Wie gesagt es ging um eine STOTAX-Installation. Wenn man in die SQL-Stotax-Datenbanken
die gesicherten Daten wieder eingepflegt hat, so befindet sich auf der
Programm-DVD in einem Tools Unterordner ein Programm Datenueb.exe. Dieses
startet man und siehe da, nach 10 Sekunden konnte der Client ganz normal
eine Verbindung zum SQL-Server aufbauen. Nun wäre natürlich die Frage
was hat dieses Tool gemacht? das konnte mir jedoch niemand veraten.
Das Tool hat vermutlich ein Schemaupdate des Datenbank Inhalt's durchgeführt.
Du hast mit Sicherheit eine andere Programversion (unabhängig vom SQL Server) installiert als die von der das Backup bzw. die Datenbank war.
Somit das das ganze nicht's mit dem SQL Server zu tun gehabt.
Edit:
Ach und zu Peters Verteidigung. Hier findet man sehr viele "professionelle" Dienstleister die irgendwelche Aufträge annehmen und keine Ahnung haben was sie da tun sollen. Und dann kommen Sie hier her und wollen kostenlos eine schnelle Lösung und dann aber Geld vom Kunden.