SQL Datenbank migriert, keine Verbindung zur Datenbank

[Ens 0]

Hallo erstmal :)

 

Folgendes Szenario:

 

- Neuer Server für TeamViewer Manager hochgezogen von MS Server08 auf 12.

- Alte Datenbank von SQL2008 Express auf SQL2012 Express migriert, keine Probleme.

- TV Manager gestartet, auf dem Server selbst wird die Datenbank sofort übernommen. Keine Probleme.

- Von anderen Rechnern aus klappt die Verbindung zur Datenbank nicht über den TV Manager.

 

Der gesunde Menschenverstand sagt also: Konnektivitätsproblem.

 

Verwirrend:

Alle erforderlichen Nutzer existieren und haben die erforderlichen Rechte. Die Verbindung zum Server ist einwandfrei. Keine Blockierung durch Firewallregeln. Nichts...

 

Ich bin im Moment ratlos und dankbar für Denkanstöße :)

 

Fehlermeldung:

[Microsoft]

SQL-Netzwerkschnittstellen: Fehler beim Suchen des angegebenen Servers/der angegebenen Instanz [xFFFFFFFF]. [Microsoft][sql Native Client]Fehler beim Herstellen einer Verbindung zum Server. Bei einer Verbindung zu SQL Server 2005 kann dieser Fehler dadurch verursacht werden, dass SQL Server unter den Standardeinstellungen keine Remoteverbindungen zulässt. [Microsoft][sql Native Client]Anmeldungstimeout abgelaufen QODBC3: Es kann keine Verbindung aufgebaut werden

[Sunny61 773]

Wer oder was ist der TV Manager? TemaViewer Manager vielleicht? Habt ihr keinen kostenlosen Support von TeamViewer?

 

Auf Seite 26 könnte etwas für dich dabei sein: http://www.teamviewer.com/de/res/pdf/TeamViewer7_Manual_Manager_DE.pdf

[Ens 0]

Danke für die Antwort.

 

Der Support von TeamViewer verweist bei so einem Problem auf Microsoft, da es sich um ein SQL Problem handelt. Bevor ich mich aber durch die Knowledgebase von MS fräse, wollte ichs lieber mal woanders probieren.

 

Danke für den Tip, aber das Handbuch beschreibt lediglich wie man die Daten einträgt für die zu nutzende Datenbank oder wie man eine neue via TeamViewer anlegt. Das ist bekannt :)

[Sunny61 773]

- Neuer Server für TeamViewer Manager hochgezogen von MS Server08 auf 12.

- Alte Datenbank von SQL2008 Express auf SQL2012 Express migriert, keine Probleme.

- TV Manager gestartet, auf dem Server selbst wird die Datenbank sofort übernommen. Keine Probleme.

- Von anderen Rechnern aus klappt die Verbindung zur Datenbank nicht über den TV Manager.

 

Der gesunde Menschenverstand sagt also: Konnektivitätsproblem.

 

Verwirrend:

Alle erforderlichen Nutzer existieren und haben die erforderlichen Rechte. Die Verbindung zum Server ist einwandfrei. Keine Blockierung durch Firewallregeln. Nichts...

 

Aber die Benutzer können von anderen Rechnern nicht auf die Datenbank zugreifen. Also doch ein Verbindungsproblem. ;)

 

Fehlermeldung:

[Microsoft]

SQL-Netzwerkschnittstellen: Fehler beim Suchen des angegebenen Servers/der angegebenen Instanz [xFFFFFFFF]. [Microsoft][sql Native Client]Fehler beim Herstellen einer Verbindung zum Server. Bei einer Verbindung zu SQL Server 2005 kann dieser Fehler dadurch verursacht werden, dass SQL Server unter den Standardeinstellungen keine Remoteverbindungen zulässt. [Microsoft][sql Native Client]Anmeldungstimeout abgelaufen QODBC3: Es kann keine Verbindung aufgebaut werden

 

Installiere doch auf dem Server das Management Studio und prüf nach in den Eigenschaften der Instanz ob Remote Verbindung zugelassen ist. Welcher Port wird denn vom TV Manager benutzt? Du könntest das hier prüfen: http://blog.alexonasp.net/post/2011/03/06/Auf-welchem-Port-lauft-mein-SQL-Server-(Express)-2008-R2-Oder-warum-bekomme-ich-keine-Verbindung.aspx

bearbeitet 26. Mai 2014 von Sunny61

[Dukel 436]

Bei SQL Express musst du normalerweise TCP/IP explizit aktivieren.

[Ens 0]

Management Studio 2012 ist installiert :) wir haben tatsächlich nicht geprüft ob Remoteverbindungen zugelassen werde....das war aber der Fall.

 

TCP/IP wurde aktiviert.

Wir haben aber gerade noch einen vermeintlichen Faktor aufgestöbert.

Wenn man sich die SQL Version anschaut ist alles auf 2012, der SQL Native Client jedoch noch auf 2005, obwohl auf dem neuen Server noch nie was anderes installiert war.

Hatte der Native Client schon seit Jahren kein Update mehr?

 

Danke soweit für die Antöße :)

[Sunny61 773]

Management Studio 2012 ist installiert :) wir haben tatsächlich nicht geprüft ob Remoteverbindungen zugelassen werde....das war aber der Fall.

 

TCP/IP wurde aktiviert.

 

Habt ihr den Port auch überprüft? Details dazu im von mir geposteten Link.

Wir haben aber gerade noch einen vermeintlichen Faktor aufgestöbert.

Wenn man sich die SQL Version anschaut ist alles auf 2012, der SQL Native Client jedoch noch auf 2005, obwohl auf dem neuen Server noch nie was anderes installiert war.

Hatte der Native Client schon seit Jahren kein Update mehr?

 

Auf einer Maschine mit 2 SQL 2012-Express Instanzen ist der SQL Native-Client in der Version 11.0 vorhanden.

 

Habt ihr bei dem Server ein sog. Inplace Upgrade gemacht oder ist das alles vollkommen neu installiert worden?

[Ens 0]

Ok, wir testen gerade ein paar Sachen wegen dem Port....mal sehen.

 

Zur Installation:

Es wurde alles komplett neu installiert.

DIe Datenbank wurde auf dem 2008er "gesichert" und auf dem frisch installierten 2012er "wiederhergestellt", was einwandfrei funktioniert hat.

 

Edit:

 

Problem gelöst:

 

 

 

Nach tieferer Forschung und "rumprobieren" ist uns ins Auge gefallen, dass der "SQL Server Browser"-Dienst aus unerfindlichen Gründen deaktiviert war.....

Dienst gestartet. Läuft...

 

Manchmal sucht man die Nadel im Heuhaufen, dabei liegt sie direkt vor den Füßen xD

 

Danke trotzdem für alle Lösungsansätze.

bearbeitet 26. Mai 2014 von Ens

[Dukel 436]

Wenn man den Port richtig konfiguriert braucht man den SQL Server Browser nicht, sondern nur, wenn man unterschiedliche Instanzen hat.

[Sunny61 773]

 

Problem gelöst:

 

 

 

Nach tieferer Forschung und "rumprobieren" ist uns ins Auge gefallen, dass der "SQL Server Browser"-Dienst aus unerfindlichen Gründen deaktiviert war.....

Dienst gestartet. Läuft...

 

Jaja, der Browser Dienst, immer wieder gerne genommen in diesem Kontext. ;) Danke für die Rückmeldung.

[Ens 0]

Wenn man den Port richtig konfiguriert braucht man den SQL Server Browser nicht, sondern nur, wenn man unterschiedliche Instanzen hat.

 

Das ist seltsam, da wir nur eine Instanz haben...aber definitiv nichts im Netz ist, was die Ports blockiert. Die Windows Firewall ist überall abgeschaltet und die Kommunikation über Port 1433 nicht blockiert, eingehend wie ausgehend.

Aber da es funktioniert, will ich gar keine weiteren Fragen stellen ;)

[Dukel 436]

Dann ist wohl der Port 1433 in der TCP/IP Konfiguration nicht eingetragen sondern Dynamische Ports.

[Sunny61 773]

Das ist seltsam, da wir nur eine Instanz haben...aber definitiv nichts im Netz ist, was die Ports blockiert. Die Windows Firewall ist überall abgeschaltet und die Kommunikation über Port 1433 nicht blockiert, eingehend wie ausgehend.

 

Weshalb schaltet alle Welt die Firewall ab? Die ist per GPO sehr einfach zu konfigurieren, das abschalten ist IMHO ab VISTA sogar äußerst kontraproduktiv. Und den SQL Server per TCP 1433 nach draußen zu lassen und/oder den Browser per 1434 UDP ist ja auch in max. 1 Minute eingerichtet.

 

Aber da es funktioniert, will ich gar keine weiteren Fragen stellen ;)

 

Da könnte man aber noch etwas lernen.

[Doso 77]

Weshalb schaltet alle Welt die Firewall ab? Die ist per GPO sehr einfach zu konfigurieren, das abschalten ist IMHO ab VISTA sogar äußerst kontraproduktiv. Und den SQL Server per TCP 1433 nach draußen zu lassen und/oder den Browser per 1434 UDP ist ja auch in max. 1 Minute eingerichtet.

 

Für den SQL Server gibt es ein Script von MS das die entsprechenden Ports in der Firewall freigibt. Bei uns ist auch die Regel das alle produktive Server die lokale Firewall aktiv haben.

 

Ist halt vermutlich einfacher die Firewall abzuschalten, aber für mich ist sowas dann kein "richtiger" Server-Admin :p

[Ens 0]

Hardware-Firewall Lösung.

 

also:

Warum doppelte Arbeit? :)