festus
Goto Top

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

Content-ID: 197312

Url: https://administrator.de/contentid/197312

Ausgedruckt am: 22.11.2024 um 15:11 Uhr

GuentherH
GuentherH 20.01.2013 um 13:05:49 Uhr
Goto Top
Hallo.

Starte den Dienst "SQL Server Browser" dann sollte es klappen.

LG Günther
festus
festus 20.01.2013 um 13:24:49 Uhr
Goto Top
Hallo Günther H

Ich zitiere aus meiner Anfrage: "Alle notwendigen Dienste
sind aktiv, also auch die SQL Instanz selbst sowie der SQL Browser."

Wenn es doch so einfach wäre!

Danke trotzdem
wiesi200
wiesi200 20.01.2013 aktualisiert um 13:28:21 Uhr
Goto Top
Hallo,

Was steht den im Event Log drinnen?
Ach und zum anmelden als Admin,
Windows Anmeldung oder SQL Anmeldung?
festus
festus 20.01.2013 um 13:45:01 Uhr
Goto Top
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. Die Admin
Anmeldung erfogt am lokalen Client. Da der Server Administrator das gleiche
Kennwort wie die lokalen Administratoren verwendet, ist die Server Anmeldung
unproblematisch. Im SQL Server ist die gemischte Authentifizierung aktiv,
so das auch Windows Authentifizierungen vom SQL Server akzeptiert werden sollten.
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.
Friemler
Friemler 20.01.2013 aktualisiert um 17:18:21 Uhr
Goto Top
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 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
wiesi200
wiesi200 20.01.2013 um 16:50:12 Uhr
Goto Top
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.

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.

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.
festus
festus 20.01.2013 um 19:28:40 Uhr
Goto Top
Wiesi200

Wie konkret melde ich mich mit dem Client per sql-authentifizierung am sql-server an.
Geht das per net use, ich finde auf dem Client keinen Punkt um die Authentifizierung
anzubringen.
wiesi200
wiesi200 20.01.2013 um 19:34:16 Uhr
Goto Top
Erstell doch einfach nen ODBC Connector auf die DB.
Der hat auch nen kleinen Verbindungstest.
Da kannst du dann die Art der Anmeldung auswählen.

Mit SQL hast du noch nicht viel gemacht, oder?
festus
festus 20.01.2013 um 19:47:53 Uhr
Goto Top
Hast Recht SQL ist nicht mein Steckenpferd.
Es gibt unter XP den ODBC-Administrator, unter System-DNS
denke hier muss ich den Connector einrichten.

Danke für den Hinweis
festus
festus 20.01.2013 um 20:02:42 Uhr
Goto Top
Muss das Problem heute erst mal theoretisch soweit wie möglich aufarbeiten, kann
erst morgen früh wieder an den Server. Unter dem ODBC-Administrator
gibt es drei Reiter "Benutzer-DSN", "System-DSN" und "Datei-DSN".
Ich kann morgen nicht lange forschen unter welchem Reiter richte
ich den Connector ein.
GuentherH
GuentherH 20.01.2013 um 20:30:27 Uhr
Goto Top
Hallo.

Erstelle am Desktop des Clients einen Datei z.B. Test.udl
Starte die Datei mit einem Doppelklick, und wähle im Register Provider SQL Server aus.
Im Register Verbindung sollte eigentlich alles klar sein.

LG Günther
Pjordorf
Pjordorf 20.01.2013 um 21:28:35 Uhr
Goto Top
Hallo,

Zitat von @festus:
Ein Kunde hat einen neuen Server bekommen
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 werdenface-smile

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?face-smile

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.
bist du auch nicht eingegangen. Wie läuft den die Anmeldung deines Stotax Clients ab?

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
festus
festus 21.01.2013 um 13:23:49 Uhr
Goto Top
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.

@peter
Du konntest mal wieder so richtig Deinen Larry raushängen lassen, vl brauchst Du das
ja ab und zu. Ich bin vielleicht nicht so weise in Sachen SQL-Server wie Du, aber
ich habe mich in den letzten 20 Jahren durch sämtliche Probleme meiner Kunden
durch geackert, auch an Stellen an denen andere "Weise" lange das Handtuch
geworfen haben. Sollte ein Gebiet berührt werden, auf welchem ich nicht sattelfest
bin, dann habe ich durchaus soviel Arsch in der Hose mir Hilfe zu holen.
Dabei habe ich die Erfahrung gemacht das es viele sogenannte Guru´s gibt, die
in einem Programm alle Bit´s mit Namen kennen, aber die verzweifeln, wenn ihnen
beim Arbeiten die Maus vom Tisch fällt.

Sorry, aber das musste mal gesagt werden!
wiesi200
wiesi200 21.01.2013 aktualisiert um 13:33:40 Uhr
Goto Top
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.


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.
festus
festus 21.01.2013 um 17:30:33 Uhr
Goto Top
Hallo wiesi200,

erst mal vielen Dank für Deine Hinweise. Die Stotax Version ist exakt die Gleiche wie
die Version von der die Datensicherung stammt. Geändert hat sich lediglich das BS des
Servers von 2003 Small Business Server auf 2008 R2 SP1.

Ich bin ja froh, dass es diese Plattform gibt, Keiner, auch Du bist nicht allwissend
und bist irgendwann auf Hilfe angewiesen weil ein Problem einen Bereich berührt, in welchem
Du nicht sattelfest bist. Mir vorzuhalten das ich hier eine schnell kostenlose Lösung
suche ist nicht fair, wer zwingt euch denn hier zu antworten? Ihr macht das doch aus
freien Stücken. Ich habe hier auch schon einige Anleitungen und Lösungen veröffentlicht,
an welchen man sich durchaus die Zähne ausbeissen kann. Es ist schon klar das in solch
einem Forum zum Nehmen auch das Geben gehören sollte.

Ich bin kein Hobbyeinsteiger sondern war 1992 einer der ersten Novell CNE´s in diesem Ländle,
davor habe ich Hochschulabschlüsse in Elektrotechnik und Luftfahrttechnik erworben. Seit 1991
bin ich im EDV-Netzwerkbereich unterwegs, seit 1994 selbstständig. Ich habe Dinge
(z.B. Anlagensteuerungen) zum Laufen gebracht, an welchen sich selbst die Hersteller
die Haare gerauft haben. Wenn ein Kunde eine Betreuung durch mich wünscht, so muss
ich mich logischerweise erst in die spezifischen Probleme vertiefen und dazu nutze ich
auch solche Medien, wie dieses Forum, ich wäre ja beschränkt das nicht zu tun. Und wenn
einer meiner Kunden wie in diesem Fall eine Havarie hat, dann setze ich Himmel und Hölle
in Bewegung, um so schnell wie möglich eine Lösung herbeizuschaffen.

Die Art und Weise, wie Peter meine ursprüngliche Anfrage zerplückt und kommentiert hat
weisst eindeutig darauf hin, das es ihm nicht darum ging mir einen Tip zu geben. Er wollte
vielmehr selbstdarstellerisch sein Ego polieren.

Wie gesagt, ich danke Dir für Deine Hilfe.
wiesi200
wiesi200 21.01.2013 um 17:57:23 Uhr
Goto Top
Ich hab auch nie behauptet das du so bist, nur das es hier viele in der Richtung gibt.
Und somit kann ich auch Peter verstehen.