[gelöst] Verbindung Developement Environment zu SQL Server

Ich installiere gerade eine NAV 2016 Cronus mit SQL Server 2012. Auf dem Server läuft bereits eine 2009R2 mit SQL Server 2008R2, der Server selbst hat Windows Server 2008 R2 Enterprise.
Das hat bis dahin auch soweit geklappt, die Datenbank ist mit dem Client von meinem PC aus ansprechbar.
Nun mein Problem: leider klappt die Verbindung Developement Environment 2016 zum SQL-Server 2012 nicht. Dieser läuft als zweite Instanz "MeineSQLInstanz". Auf dem Server selbst kann ich die Verbindung jedoch herstellen, indem ich dort bei "Datenbank öffnen" als Servername "localhost\MeineSQLInstanz" angebe. Von meinem Client aus führt es zu dieser Fehlermeldung:

Der Servername\MeineSQLInstanz wurde nicht gefunden. Versuchen Sie es später erneut, oder wenden Sie sich an den Systemadministrator.

Mit dem SQL Server Management Studio klappt es ebenfalls nicht. An die Datenbanken auf der Hauptinstanz komme ich jedoch.

Der Server "MeineSQLInstanz" lässt Remoteverbindungen zu. Worauf könnte ich noch achten?

Im SQL Configuration Manager müssen tcp Verbindungen zugelassen sein. Firewall beachten.

Hallo,

TCP/IP- eingeschaltet bei der Instanz?

Gruß Fiddi

Habe ich beides beachtet.

db_owner ist der Benutzer?

Ja, ist er.

Eventuell ein DNS-Problem?
Nutzt der neue SQL vielleicht einen anderen Port?

Danach sieht es nicht aus, alles auf Standard 1433 (Korrektur: dynamisch) konfiguriert ... aber eine andere Idee (die mir bisher nicht wichtig erschien, weil der Zugriff vom normalen NAV-Client auf die Datenbank ohne weitere Einstellungen funktioniert): der Server läuft auf einer VM. Muss man da wohl eine Regel konfigurieren?

Hallo,

gibt es vielleicht irgendwelche verdächtigen Einträge in der Ereignisanzeige? Läuft der SQL Instanzdienst überhaupt? Gibt es irgendwelche Einträge im SQL Server Log?

Gruß

Michael

Ja, die läuft. Die Cronus ist ansprechbar und von der Development Environment, die auf dem Server installiert ist, klappt die Verbindung auch. Letzteres halt von meinem PC aus nicht.

gibt es vielleicht irgendwelche verdächtigen Einträge in der Ereignisanzeige? (...) Gibt es irgendwelche Einträge im SQL Server Log?

Der NAV-Server-Dienst schmeißt ein paar Fehler, aber um den geht's ja nicht. Sonst sehe ich nichts Verdächtiges.

Hallo,

indem Fall ist es wahrscheinlich die Firewall. Definiere eine Regel für den Port auf dem deine Instanz ansprechbar ist. Du kannst die Firewall auf beiden Rechner deaktivieren und sehen ob die Verbindung dann zustande kommt.

Gruß

Michael

...Mit dem SQL Server Management Studio klappt es ebenfalls nicht...

Hast du dieses schon durchprobiert?

indem Fall ist es wahrscheinlich die Firewall.

War auch meine Vermutung, aber die ist auf dem Server sogar deaktiviert. Trotzdem habe ich die Regeln angelegt, sowohl unter eingehende Verbindung für den Port als auch eine weitere für das Programm. Hat leider nichts geholfen.

Hast du auf deinem Rechner oder auf dem Server eine Endpoint Protection/Antivirus o.ä.?
Ich hatte den Fall mal mit ESET. Da war die Firewall richtig konfiguriert und eine "intelligente" Automatik hat es trotzdem nicht erlaubt. Hat erst nach Deinstallation funktioniert.

Danke, Michael, dein Link hat mich weiter gebracht. Wenn ich als Servername "IP-Adresse,Portnummer" (edit: "Hostname,Portnummer" klappt auch. Der Port ist aber nicht 1433, sondern ganz ein anderer) eintrage, dann klappt's. Ist es das, was hiermit:

Eventuell ein DNS-Problem?

gemeint war?

Bei DNS geht es immer um den Servernamen. Kann man in der CMD gut mi nslookup nachvollziehen.
Kann auch sein, dass irgendwelche SPNs nicht richtig gesetzt sind. Da habe bei NAV 2009 gekämpft.
Wird die SQL Instanz mit dem selben Benutzer ausgeführt wie die normale Instanz?

Ja, ist derselbe User.

Mach mal eine CMD auf und schreibe

Code:

setspn -Q */DeinSQLServer

Da sollte irgendwo deine Instanz mit drin stehen.

Dort taucht sie nicht auf. Da werde ich wohl unseren Admin drum bitten müssen.

Eine Neuinstallation des SQL-Servers hat's gerichtet, die Instanz ist nun von außen ansprechbar und der SPN vorhanden. Der einzige mir bewusste Unterschied zum ersten Mal war das ausdrückliche Ausführen als Administrator. Allerdings sollte der User, der die erste Installation vorgenommen hat, ebenfalls Admin-Rechte auf der Maschine gehabt haben, so dass mir das nicht als so wichtig erscheint .

Vielen Dank an alle für eure Hilfe. Wieder einiges gelernt