Ne peut pas se connecter à l'instance nommée de SQL Server à partir d'un autre Serveur SQL server

J'apprécierais un peu d'aide, car j'ai été bloqué pendant 2 jours sur ce problème!

Scénario: je peux me connecter au SERVEUR\INSTANCE de ma machine de développement (et un autre collègues), mais ne peut pas se connecter à partir d'un autre Serveur SQL server. L'erreur que j'obtiens est le générique "...vérifier le nom de l'instance est correct..". Choses que j'ai fait/vérifié:

J'ai désactivé le pare-feu de la destination et la source) de serveur pour voir si c'est un problème de firewall (ce qui semble plus probable puisque je peux me connecter à partir de mon ordinateur, mais cela n'a pas aidé).
J'ai vérifié que SQL Navigateur fonctionne (ce qui est fait puisque je peux me connecter de machine de développement)
Depuis deux Serveurs SQL de plusieurs instances et codée en dur ports, j'ai même fait en sorte qu'ils étaient différents ports au cas où il y a eu quelques conflits (ce qui n'a pas aidé).
J'ai redémarré le Serveur SQL et vérifié que le navigateur /de l'instance de l'exécution de services de
Vérifié journal des événements - rien de la note
Assez intéressant si je ne suis pas connecter sur le nom de l'instance, mais se connectent via le port dynamique (c'est à dire de SERVEUR,PORT) à partir de la deuxième serveur il fonctionne très bien - ce qui me donne à penser SQL Navigateur est en faute, sauf qu'il fonctionne très bien en local sur le serveur et à partir de ma machine de développement.

Toutes les idées et suggestions? Merci.

Edit: Pour le commentaire de précisions, je vais voir les données SQL Server en tant que SQLA et la non-données SQLB.

Edit #2: Ajout de plus de cas de tests /info:

Info: Les tests ci-dessus ont toutes été faites par les SSM interface pour établir une connexion à la base de données, les bases de données concernées sont à la fois 2012.

Nouveau Cas de Test: j'ai essayé de lancer un script de configuration d'un serveur lié à la place et a constaté que l'exécution de ce script sur un Serveur SQL server 2005 boîte a bien fonctionné, mais l'exécution du même script sur le Serveur SQL server 2012 (SQLB) impossible de se connecter au SQLA avec l'erreur: SQL Server Interfaces Réseau: Erreur de Localisation du Serveur/de l'Instance Spécifiée [xFFFFFFFF].

Edit #3: Réduit le problème potentiel:

Téléchargé et exécuté PortQry et lorsqu'il est exécuté à partir de ma boîte de dev je reçois toutes les instances retournées avec l'interrogation sur le port UDP 1434, qui exécute la même requête à partir de SQLB ne retourne AUCUN cas et les états 1434 comme étant FILTRÉ alors que sur la boîte de dev, il est retourné en tant que LISTING. Je ne peux que penser que c'est le pare-feu connexes, sauf que j'ai désactivé le pare-feu sur les deux machines

Essayez de créer un DSN SYSTÈME (sur le serveur sql server qui ne conserve pas les données souhaitées) ... qui communique avec le serveur sql avec les données. C'est ma rapide et sale "cette machine peut-elle arriver à cette machine" ...
Comme dans .. le Panneau de configuration-Outils d'administration -- ODBC. Remarque, sur 64 bits machines, il est un 64 bits et un autre de 32 bits ODBC manager. Pour la version 32 bits est situé à : C:\Windows\SysWOW64\odbcad32.exe
Je peux me connecter à partir de (permet d'appeler le non-données d'un SQLB et les données SQLA) si j'utilise le port style SQLA,PORT contre SQLA/INSTANCE, il semble que lorsque vous essayez de vous connecter à l'instance qu'il est incapable de passer à travers.
Ok...laissez-moi la recherche de quelque chose..donnez-moi quelques minutes.
Qu'est-ce que votre "chaîne de connexion" (j'ai utilisé le terme vaguement) lors de la tentative de connexion filaire jusqu'SQLB à SQLA. Avez-vous fait un "sp_addlinkedserver" ? (Est-ce la façon dont vous essayez de les amener à parler les uns aux autres)

OriginalL'auteur user1839820 | 2013-06-10

sql-server sql-server-2012

15

Vos cas de test où vous ne pouvez pas vous connecter avec "ServerName\Instance", mais SONT en mesure de se connecter au serveur via le "nom du serveur,le Port" est ce qui se passe quand vous VPN dans un réseau avec Microsoft VPN. (J'ai eu ce problème). Pour mon VPN Question, j'ai simplement utiliser la statique des numéros de port pour la contourner.

C'est appearently en raison de VPN pas de redirection des Paquets UDP, ne permettant que des Connexions TCP.

Dans votre cas, votre pare-feu ou les paramètres de sécurité ou de l'antivirus ou tout ce qui peut être le blocage.

Je vous suggère de vérifier votre réglage du pare-feu d'autoriser UDP pour les.

Navigateur Artical

Au démarrage, SQL Server Navigateur démarre et réclame le port UDP 1434. SQL
Serveur Navigateur lit le registre, identifie toutes les instances de SQL Server
sur l'ordinateur, et note les ports et les canaux nommés qu'ils utilisent.
Lorsqu'un serveur a deux ou plusieurs cartes réseau, SQL Server Navigateur
retour à tous les ports sont activés pour SQL Server. SQL Server 2005 et SQL
Serveur Navigateur prend en charge ipv6 et ipv4.

Lorsque SQL Server 2000 et SQL Server 2005 à la demande des clients SQL Server
ressources, la bibliothèque réseau de client envoie un message UDP à l'
serveur en utilisant le port 1434. SQL Server Browser répond avec le protocole TCP/IP
port ou le canal nommé de l'instance demandée. Le réseau de la bibliothèque sur
l'application cliente puis termine la connexion en envoyant un
demande au serveur en utilisant le port ou le nom de la pipe, de la
exemple.

À l'aide d'un Pare-feu

À communiquer avec le service explorateur SQL Server sur un serveur derrière un pare-feu, ouvrez le port UDP 1434 en plus le port TCP utilisé par SQL Server (par exemple, 1433).

J'ai pris le pare-feu hors de question, cependant, vous avez un point sur les VPN - je suis VPNed en SQLB afin de rendre les requêtes nécessaires (c'est malheureusement la seule façon d'accéder à la machine). Cependant que la machine elle-même n'est pas VPNed n'importe où, alors que je ne suis pas sûr que le VPN serait un problème (mon client ne fait pas l'UDP de négociation le serveur). Pouvez-vous confirmer si votre VPN question peut-être encore pertinent? À ce stade, je ne veux pas ignorer toute possibilité!
Le VPN est juste mon exemple d'un système qui empêche le trafic UDP. Si vous pouvez vous connecter par le numéro de Port, vous permet d'établir une connexion TCP/IP sans autre protocole impliqués. Si votre 2 Instances de base de données sont sur une autre machine, puis il ya un certain niveau de réseau entre eux. Sur mon réseau d'entreprise, nous avons considérable de règles de pare-feu entre les systèmes de serveur, parfois même dans le même emplacement physique. Si un routeur est entre eux et ne permet pas le trafic UDP ce système pourrait être le point de blocage. Il n'y a pas beaucoup d'autres cas qui pourrait être votre problème.
Alors que je suis d'accord avec tout ce que vous avez dit (+1), le dernier bit sur les systèmes qui n'utilisent pas les Instances de SQL Server est certainement pas true. Je travail pour un grand nombre de grandes entreprises et la grande majorité d'entre eux ne l'utilisez les noms d'Instance, et la plupart s'en servent abondamment. Et les problèmes avec leurs noms sont généralement assez rares et facilement resovable.
(Et FWIW, je me doutais de votre réponse la plus probable de corriger tout le long 🙂 )
Exactement. Je suis dans le Windows Firewall with Advanced Security et là j'ai activé ma règle entrante, ce qui était pour le port 1433 sur TCP au port, à l'intérieur de la Ports and Protocols onglet. Et cela a fonctionné. Merci!

OriginalL'auteur DarrenMB
6

Ne sais pas si c'est la réponse que vous recherchez, mais il a travaillé pour moi. Après de tourner mes roues dans le Pare-feu Windows, je suis de retour dans le Gestionnaire de Configuration SQL Server, vérifié la Configuration du Réseau SQL Server, dans les protocoles pour l'exemple, je travaillais avec un coup d'oeil à TCP/IP. Par défaut, il semble que la mine a été désactivé, ce qui a permis par exemple de connexions sur l'ordinateur local, mais pas à l'aide de SSMS sur une autre machine. Activation de TCP/IP a fait le tour pour moi.

http://technet.microsoft.com/en-us/library/hh231672.aspx

C'était exactement le problème et ta solution m'a aidé. Je suis allé le Gestionnaire de Configuration SQL Server >> Configuration du Réseau SQL Server >> Protocoles pour MSSQLSERVER20126 >> TCP/IP et l'a activé. J'ai été en mesure de se connecter à l'instance nommée à partir d'une autre machine.

OriginalL'auteur Francisco Garcia
4

J'ai enfin trouvé le problème ici. Même si le pare-feu a été éteint à la fois les lieux, nous avons trouvé qu'un routeur dans le SQLB centre de données a été activement blocage UDP 1434. J'ai été en mesure de déterminer par l'installation de la PorQry outil par Microsoft (http://www.microsoft.com/en-ca/download/details.aspx?id=17148) et l'exécution d'une requête sur le port UDP. Puis j'ai installé WireShark (http://www.wireshark.org/) pour afficher la connexion réelle de détails et trouvé le routeur en question qui a été refusant de transmettre la demande. Depuis ce routeur concerné uniquement SQLB c'est ce qui explique pourquoi tous les autres de la connexion a bien fonctionné.

Merci à tous pour vos suggestions et de l'aide!

Pas de problème. Il serait agréable d'être marqué comme "réponse". c'est ce que j'ai proposé était votre question 🙂

OriginalL'auteur user1839820
3

Vous avez essayé beaucoup de choses. Et je me sens pour vous.
Voici une idée. J'ai un peu suivi tout ce que vous avez essayé.
La note mentale que j'ai dans ma tête qui va comme ceci:
"Lorsque Sql Server ne se connecte pas quand vous avez tout essayé, le fil de vos règles de pare-feu par le programme, pas le port"

Je sais que vous avez dit que vous avez désactivé le pare-feu.
Mais quelque chose me dit de donner à ceci un essai de toute façon.

Je pense que vous devez ouvrir le pare-feu "par programme", et non pas par le port.

http://technet.microsoft.com/en-us/library/cc646023.aspx
```
To add a program exception to the firewall using the Windows Firewall item in Control Panel.


On the Exceptions tab of the Windows Firewall item in Control Panel, click Add a program.


Browse to the location of the instance of SQL Server that you want to allow through the firewall, for example C:\Program Files\Microsoft SQL Server\MSSQL11.<instance_name>\MSSQL\Binn, select sqlservr.exe, and then click Open.


 Click OK.
```
MODIFIER..........

http://msdn.microsoft.com/en-us/library/ms190479.aspx

Je suis un peu nuageux qui "programme" vous essayez de l'utiliser sur SQLB?

Est-il SSMS sur SQLB? Ou d'un programme client sur SQLB ?

MODIFIER...........

Aucune idée si cela va aider.
Mais je l'utilise pour de ping "ports" ... et quelque chose qui est en dehors de la SSMS monde.

http://www.microsoft.com/en-us/download/details.aspx?id=24009

Désolé j'aurais du être plus clair dans les deux cas (à partir de SQLB ou ma machine de dev), je me connecte via SSMS afin de tester la connexion (à l'aide de sa considération dans l'Authentification SQL Server).
Je viens d'essayer votre suggestion et a ajouté l'exécutable de SQL Server pour qu'une instance pour le pare-feu, mais cela n'a pas aidé non plus. Il doit y avoir quelque chose de spécial avec SQLB qui est à l'origine d'avoir de la difficulté avec du SQLA SQL Navigateur mais je ne vois pas de quoi!
Vous ne savez pas si cela aide ou les causes de la confusion, mais j'ai essayé de connecter à l'instance par défaut (pas de nom de l'instance) et SQLB peut se connecter à SQLA bien, mais si j'essaie de me connecter à l'instance par défaut le nom de l'instance qu'il échoue.
Qui êtes-vous à l'aide de SSMS sur SQLB? Comme, lorsque les informations d'identification de l'écran (quand vous commencez à SSMS), allez-vous mettre en servername\instance (en se référant à SQLA) et nom d'utilisateur pour un utilisateur qui existe sur SQLA? OU êtes-vous en vous connectant à SQLB comme "sa"...puis, à l'aide de TSQL en essayant de se connecter de nouveau à SQLA ?
Vous devez marquer l'une des réponses comme "la Réponse" et upvote les réponses de la personne qui vous a donné des informations utiles. Ouais, pas sûr de vous l'avez vu, mais je l'ai mentionné microsoft.com/en-us/download/details.aspx?id=24009 comme l'outil PortQry qui raconte une histoire rapide sur la façon de parler à une autre IP:Port (je sais que c'est seulement une partie de ce que vous avez trouvé)

OriginalL'auteur granadaCoder
2

Avez-vous Client des Alias définis sur votre Machine de Développement? Si oui, alors les définir de la même manière sur SQLB aussi. Plus précisément, je soupçonne que vous avez Alias Clients en format InstanceName définissant les ports, contournant ainsi le réel, les noms d'Instance et de la nécessité pour SQL Navigateur (partiellement). Il y a d'autres possibilités avec les Alias Clients aussi bien, alors assurez-vous juste que ce sont les mêmes.

Pour vérifier les Alias Client SQL, utilisez le Gestionnaire de Configuration SQL Server, microsoft sql server, le Programme du menu Démarrer). Là, allez dans la Configuration du Client, puis des "Alias".

D'autres choses à vérifier:
1. Que SQLA et SQLB sont soit dans le même domaine, ou qu'il n'est pas un manque de Confiance entre eux.
2. Assurez-vous que SQLB TCP/IP est activé en tant que Client de Protocole (c'est aussi dans le Gestionnaire de configuration SQL).
Par certains de vos réponses, je pense que vous l'avez raté le point de mes déclarations sur Domaines et Approbations. Vous ne pouvez pas vous connecter à SQL "Serveur\Instance" sauf s'il y a suffisamment de confiance entre le client et le serveur. C'est parce que la totalité de l'Instance-schéma d'affectation de noms SQL Sevrer utilise dépend de noms principaux de service (spn) pour la découverte, l'emplacement et d'autorisation, et les noms principaux de service sont stockées dans l'ANNONCE. Donc, à moins que le client est sur la même case, l'instance doit être capable d'inscrire son nom principal de service et le client doit être en mesure de naviguer ce que AD forêt de l'instance de serveur enregistré de nom principal de service.

Si vous ne pouvez pas faire cela, alors les noms d'Instance effectivement ne fonctionne pas et que vous devez utiliser le numéro de Port (ou nom de canal) à la place. C'est ce que je viens de suspect se passe.

Merci pour le commentaire - je n'ai pas tous les alias définis et j'ai été en mesure de reproduire le "bon" comportement sur une instance de SQL Server 2005, j'ai où j'ai réussi à ajouter un serveur lié à "SQLA". Le même script sur SQLB n'ont pas reçu le paquet UDP. C'est presque comme SQLB ne peut pas négocier (malgré l'absence de pare-feu activé) à SQLA - mais il peut négocier avec son propre Navigateur SQL fine (il peut accéder sans problème)
Je ne pense pas que SQL Navigateur est nécessaire pour les connexions locales.
ça, c'est intéressant et valable au point, sur le système local, il n'aurait pas besoin de le service explorateur SQL donc mon test a été entaché d'irrégularités.

OriginalL'auteur RBarryYoung
2
1. J'ai eu de spécifier un port dans le gestionnaire de Configuration SQL > TCP/IP
2. Ouvrir le port sur votre pare-feu
3. Puis se connecter à distance à l'aide: "nom du serveur\autre instance de base de données,(numéro de port)"
4. Connecté!
OriginalL'auteur Armand G.
1

bien après avoir passé environ 10 jours à essayer de résoudre ce problème, j'ai finalement pensé à elle aujourd'hui, et de décider à poster la solution

dans le menu démarrer, tapez EXÉCUTER, de l'ouvrir
le dans la boîte de dialogue exécuter, tapez SERVICES.MSC, cliquez sur ok

veiller à ce que ces deux services sont démarrés
SQL Server(MSSQLSERVER)
SQL Server Vss writer

OriginalL'auteur PEN SOLUTIONS

J'ai besoin de faire 2 choses à se connecter avec le nom de l'instance

1. Enable SQL Server Browser (in SQL server config manager)
2. Enable UDP, port 1434 trong file wall (if you using amazon EC2 or other service you need open port in their setting too)

Le redémarrage de sql et fait

OriginalL'auteur Grey Wolf

0

Pour résoudre cela, vous devez vous assurer des conditions suivantes est remplie sur la machine qui héberge le Serveur de SQL...
1. Assurer Server Browser service est en cours d'exécution
2. Assurer la communication TCP/IP est activé pour chaque instance que vous souhaitez communiquer sur le réseau.
3. Si l'exécution de plusieurs instances, s'assurer que chaque instance est d'utiliser un port différent, et que le port n'est pas en cours d'utilisation. e.g pour les deux instance 1433 (port par défaut pour l'instance par défaut, 1435 pour une instance nommée.
4. Assurer le pare-feu dispose d'une entrée pour permettre la communication avec SQL Server browser sur le port 1434 sur le UDP protocole.
5. Assurer le pare-feu dispose d'une entrée pour permettre la communication avec les instances de SQL Server sur les ports qui leur est attribué dans l'étape 3 sur la TCP protocole
OriginalL'auteur Mick

Vous devez vous connecter pour publier un commentaire.