Zugriff auf SQL-Server (SBS 2008) mit XP-Client OK, mit Windows 7 nicht möglich

[Samoth 32]

Guten Abend MCSE-Community,

 

gleich zu Beginn: Ich bin leider nicht der SQL-Spezialist, der ich in dem Fall sein sollte. Hoffentlich sind meine Ausführungen nachvollziehbar und nicht zu laienhaft.

 

Mit folgendem Szenario haben wir momentan zu kämpfen:

Einer unserer Kunden hat einen neuen Windows 7 (64 Bit) Rechner bekommen. Diesen haben wir in seine Domäne eingebunden, was auch ohne Probleme klappte. An den Clients wird eine Software benutzt, die auf den einzigen Windows Server SBS 2011 Standard, 64 Bit) und dort auf eine SQL-Instanz zugreift.

 

Dieser Zugriff funktioniert von einem XP-Rechner wunderbar. Dort läuft das zugehörige Programm nach wie vor und auch der Test mit einem ODBC-Connector(?) ähnlichen Test-Tool klappt. In dem Tool kann man auf "Aktualisieren" klicken, den Anmeldetyp mitgeben und erhält letztlich beim Test der Verbindung ein "Erfolgreich". Meiner Ansicht nach sollte der Server und dessen Konfiguration also OK sein.

 

Jetzt kommt der Windows 7 Client (mittlerweile auch komplett frisch installiert) ins Spiel: Dort klappt der oben genannte Test einfach nicht. Leider habe ich die Fehlermeldung gerade nicht greifbar, liefere diese aber morgen gleich nach. Vielleicht hat schon vorher jemand eine gute Idee? Der Hersteller des Tools war heute den kompletten Tag mit der Fehlerbehebung beschäftigt, leider erfolglos.

 

Was haben wir schon versucht:

 

1. Vom 7-Client aus den Befehl "telnet sbs 1433". Danach blinkt für lange Zeit ein Cursor, das war es.

 

2. Windows 7 neu installiert, was auch nicht zum Erfolg führte. Dabei wurde lediglich das OS frisch aufgezogen und der Rechner in die Domäne aufgenommen. Sonst keinerlei Software.

 

3. Über die Boardsuche fand ich folgenden interessanten Thread: http://www.mcseboard.de/topic/194150-fehlermeldung-bei-sql-verbindung/?hl=%20windows%20%20sql%20%20server%20%20zugriff. In diesem wird auf eine Internetseite verwiesen: blog.alexonasp.net/post/2011/03/06/Auf-welchem-Port-lauft-mein-SQL-Server-(Express)-2008-R2-Oder-warum-bekomme-ich-keine-Verbindung.aspx. Das klingt alles nach unserem Problem. Ob bei uns dynamische Ports genutzt werden, muss ich noch nachsehen und entsprechend anpassen, also Port 1433 einstellen. Hier würde ich gerne wissen, ob ich diese Einstellung am Server oder Client machen muss? Ich frage, weil dieser Artikel (http://www.gevitas.de/wiki/index.php?title=Zugriff_auf_SQL-Server_nicht_m%C3%B6glich) auf XP/7/8 eingeht.

 

Was mich in diesem Kontext noch brennend interessiert: Laufe ich mit der fixen Eingabe des Ports 1433 in Probleme mit anderen SQL-Instanzen? Auf dem Server gibt es wohl noch ein Kaspersky Security Center, das auch eine Instanz auf dem Server hat. Ich möchte nämlich vermeiden, dass diese z. B. nicht mehr funktioniert. Hier fehlt mir einfach das Hintergrundwissen.

 

4. Die Firewall an den Clients ist jetzt deaktiviert und der Kaspersky läuft nicht bzw. war auf dem frisch installierten PC noch gar nicht installiert.

 

Habt ihr sonst noch Vorschläge, was hier das Problem sein könnte? Verwunderlich ist ja, dass es bei XP nach wie vor geht und Windows 7 so problematisch ist.

 

Würde mich über hilfreichen Input freuen :-)

 

Schöne Grüße und besten Dank schon mal

 

Samoth

 

PS. Wie gesagt, liefere ich noch die Fehlermeldungen inkl. Fehlercodes nach!

bearbeitet 5. Februar 2014 von Samoth

[Doso 77]

sql management studio installieren und prüfen ob damit der zugriff klappt.

[Daniel -MSFT- 129]

1. Vom 7-Client aus den Befehl "telnet sbs 1433". Danach blinkt für lange Zeit ein Cursor, das war es.

 

Wenn es blinkt, sollte alles gut sein. Dann steht die Verbindung. Würde die Verbindung unterbrochen sein oder der Server auf einem anderen Port lauschen, dann würde die Telnet-Verbindung hängen oder abbrechen.

 

Dein Probem ist sehr wahrscheinlich, dass Du eine 32bit Anwendung auf einem 64bit Betriebsystem ausführen willst. Du musst mit dem 32bit Admin-Tool die Datenbankverbindung anlegen: The 32-bit version of the ODBC Administrator tool and the 64-bit version of the ODBC Administrator tool display both the 32-bit user DSNs and the 64-bit user DSNs in a 64-bit version of the Windows operating system

 

Die 32-bit Version der Odbcad32.exe findest Du unter %systemdrive%\Windows\SysWoW64.

 

BTW: Windows 7 gibt es in 64bit schon eine ganze Weile. Das sollte eigentlich der Softwarehersteller wissen.

 

Have fun!

Daniel

[Samoth 32]

Hallo zusammen,

 

ich habe oben noch die genaue Serverversion eingefügt. Tut mir leid, dass ich mit dem 2008er angefangen habe. Ich weiß nicht, inwieweit das Auswirkungen auf eure Beiträge hat?

 

@Doso

Ich habe eben mal das Studio am Server gestartet und sehe dort Folgendes:

Servertyp: Datenbankmodul

Servername: SBS\WFP

Auth. Windows-Auth.

Benutzername: <Domänenname>\user

 

Klicke ich auf Verbinden, scheint auch eine Verbindung hergestellt zu werden, zumindest sehe ich dort unter "Datenbanken" zwei Datenbanken mit unterschiedlichen Namen. Kann ich das als funktionierenden Zugriff werten oder meintest du, dass ich das Studio am Client installieren und ausführen soll?

 

@Daniel

Freue mich, dass du dich hier beteiligst :-). Bei Telnet hast du absolut Recht. Habe das eben mal getestet und mit einem ausgedachten Port erhalte ich zügig eine Fehlermeldung, bei 1433 nicht. Hoffentlich klappt das mit dem 32-Bit ODBC-Tool. Ich kann mir einfach (noch) nicht vorstellen, dass der Hersteller das nicht kennt. Es gibt doch kaum noch 32-Bit Windows 7 und der Hersteller wird doch wohl nicht nur einige wenige Installationen haben und bei uns zum ersten Mal damit konfrontiert werden...?

 

Ich rühre mich wieder!

 

Danke, danke, danke :-)

[coshi 11]

Folgende Tests solltest du mal Versuchen:

 

Kaspersky Sec Center wird nur mit Endpoint Sec benutzt. Endpoint Sec läuft auch wenn du die "Firewall" deaktivierst. Für Gewissheit, dass es Kaspersky nicht ist musst du die Endpoint sec auf dem Server deinstallieren. (Ausschalten reicht nicht!)

Beim "frischen" win7 Client auch die win Firewall komplett ausschalten.

 

Dann SQL MMC starten. Schauen ob der SQL Browser für deine Datenbankinstanz läuft. Ist TCP/IP Protokoll an in der Instanz.

 

Hier noch ein paar Gundlegende Infos:

 

http://support.microsoft.com/kb/287932/de

[Samoth 32]

Moin coshi,

 

dank dir für den Input :-)

 

Ich habe eben mal das ODBC-Tool, das Daniel erwähnte, durchgeklickt und am Schluss erschien dann (nachdem ich noch in dessen Konfig "Dynamische Ports" deaktiviert habe) auch Tests erfolgreich. SIeht ja schon mal gut aus! Auf diesem Stand würde ich jetzt erst mal aufbauen und schauen, was der Hersteller sagt. Fall ich hier nicht weiterkomme, hänge ich deinen Tipp noch an, OK?

 

Außerdem habe ich gesehen, dass der Hersteller die Verbindung zum SQL-Server über eine "server.upl" Datei erstellen möchte. Nach dem Doppelklick erscheint eine Maske (Titel: Datenverknüpfungseigenschaften) mit 3 Schritten:

 

- Servername eingeben

- Anmeldung am Server definieren

- Datenbank vom Server auswählen

 

Keine Idee, ob das eine Verknüpfung zum ODBC-Tool ist?

 

Viele Grüße

Samoth

bearbeitet 6. Februar 2014 von Samoth

[Daniel -MSFT- 129]

:jau:

[Samoth 32]

Klatsch mal nicht zu bald... wer weiß, ob das nun auch zielführend ist ;-) Mal sehen, ob der Hersteller damit weiterarbeiten kann.

 

Was mich an dieser Stelle noch interessiert: Ich habe die oben beschriebene Maske nach dem Test mit dem ODBC32-Tool nun mal ausgefüllt:

 

- Servername: sbs

- Anmeldung: Integrierte...

- Datenbank wählen: leer gelassen

 

Beim Klick auf "Verbindung testen" kommt jetzt auch erfolgreich. In welchem Zusammenhang steht das?

 

Update:

Läuft noch nicht. Den Mitarbeiter habe ich eben erreicht und der hat es mit seiner upl-Datei erneut versucht. Folgende Einstellungen:

 

- Servername: sbs\<Instanzname>

- Anmeldung: Spezifischen Benutzernamen. Dort hat er "sa" und ein eigenes PW genutzt

- Datenbank wählen: leer gelassen.

 

Danach erscheint eine Fehlermeldung mit dem Titel "Microsoft Datenverknüpfungsfehler" und dem Inhalt:

 

Fehler beim Testen der Verbindung durch einen Fehler beim Initialisieren des Providers. [DBNETLIB][ConnectionOpen(Connect()).]SQL Server existiert nicht oder Zugriff verweigert.

 

Ich soll jetzt mal auf den Rückruf des SQL-Spezialisten warten.

 

Von ihm erhielt ich eine Mail mit einigen Infos: UPL-Datei ist normalerweise zuverlässig, Zugriff per Management Studiu funktioniert und "Die Vermutung, dass es ein Problem mit 32 und 64bit geben könnte, ist plausibel, jedoch haben wir unsere Software schon oft in gemischten Umgebungen im Einsatz und im Regelfall sollte es auch bei solchen Verbindungen nicht zu Problemen kommen, da der SQL Server Native Client bzw. der ODBC /ADO Treiber im Hintergrund für eine reibungslose Kommunikation sorgt. Seltsamerweise funktioniert der Zugriff ja von den im Netzwerk vorhandenen XP Rechnern."

 

Mit einigen Inhalten aus dem Zitat kann ich aus technischer Sicht nichts anfangen. Seine Vermutung ist außerdem, dass "dass wir hier beim Einbinden in die Domäne, irgendwo tief im System vergraben, den TCP Port der Applikation/des UDL blockieren oder umleiten." Wäre das der Fall, könnten wir dann mit der Deaktivierung der dynamischen Ports arbeiten?

 

Viele Grüße einstweilen

Samoth

bearbeitet 6. Februar 2014 von Samoth

[Daniel -MSFT- 129]

Arbeite Dich mal hier http://support.microsoft.com/kb/328306/en-us und hier http://support.microsoft.com/kb/265808/en-us durch. Habt ihr schon mal einen ODBC Trace gemacht: http://support.microsoft.com/kb/274551/en-us

 

Die Antwort in der Mail klingt ein wenig esoterisch

[Samoth 32]

Die Lösung scheint(!) nun vorzuliegen und ich bin so gespannt auf eure Ansichten! Wir spielen nun das ursprüngliche Backup des Rechners wieder auf und testen das dann komplett

 

Aufgrund des Tipps mit dem odbcad32.exe von Daniel habe ich das heute morgen ja mal versucht und durchgeklickt. Ich übernahm alle Standardeinstellungen und habe lediglich bei der "Clientkonfiguration" den Haken bei "Anschluss dynamisch bestimmen" entfernt. Danach wird die Portnummer 1433 aktiv. Am Schluss hat ja auch der Test im ODBC-Admin funktioniert.

 

Danach klappte auch die Verbindung über die Hersteller-Datei Server.udl, allerdings nur, wenn man keine Instanz mit übergibt. Der Gegentest zeigt dann auch, dass es nicht mehr funktioniert, wenn ich im ODBC-Admin den Haken wieder setze. So kann man das Spiel hin und her treiben...

 

Ich sage jetzt mal vorsichtig: DANKESCHÖN!

 

Vielleicht hilft es dem einen oder anderen mal und ich gebe dann später noch Bescheid, wie es um den Rechner steht.

 

Güße

Samoth

[Samoth 32]

Moin zusammen,

 

aus Gründen der Vollständigkeit hier nun die Fortsetzung der Geschichte. Ich gebe das mal so weiter, wie ich es eben am Telefon mitbekommen habe: Über die "Server.udl" (ich schrieb oben fälschlicherweise immer "upl") Datei ist nun eine Testverbindung möglich. Allerdings nur, wenn Names Pipes genutzt werden. Über TCP geht es aus unerfindlichen Gründen nicht. ODBCAD32 zeigt zwar an, dass der Test erfolgreich ist, aber darüber kann keine Verbindung hergestellt werden, da das Programm vom Hersteller dies nicht unterstützt.

 

Der Mitarbeiter hat vor der Sache mit den Named Pipes auf dem PC noch den SQL Native Client installiert und es damit auch getestet, was wohl auch funktioniert hat.

 

Heute haben wir das alles mit dem Windows 7 durchgeführt, das von den Lenovo Recovery Medien kam. Gestern war es eine frische Windows 7 Installation von einer OEM CD. Keine Idee, was nun anders war.

 

Befriedigend ist es zwar nicht, aber es funktioniert nun zumindest.

 

Viele Grüße

Samoth