Impossible de se connecter à l'instance nommée SQL Server à partir d'un autre serveur SQL
J'apprécierais de l'aide car je suis coincé depuis 2 jours sur cette question!
Scénario: Je peux me connecter à SERVER\INSTANCE à partir de mon ordinateur de développement (et d'un autre collègue), mais je ne peux pas me connecter à partir d'un autre serveur SQL. L'erreur que je reçois est le générique "... vérifie que le nom de l'instance est correct ..". Choses que j'ai faites/vérifiées:
J'ai désactivé le pare-feu sur le serveur de destination (et source) pour voir s'il s'agit d'un problème de pare-feu (cela semble le plus probable puisque je peux me connecter à partir de ma machine mais cela n'a pas aidé).
J'ai vérifié que le navigateur SQL fonctionnait (ce qui est le cas depuis que je peux me connecter depuis la machine de développement).
Étant donné que les deux serveurs SQL ont plusieurs instances et ports codés en dur, je me suis même assuré qu'il s'agissait de ports différents en cas de conflit (cela n'a pas aidé).
J'ai redémarré SQL Server et vérifié que les services de navigateur/instance sont en cours d'exécution
Journal d'événements vérifié - rien à noter
Curieusement, si je ne me connecte pas via le nom de l’instance mais que je me connecte via le port dynamique (c’est-à-dire SERVER, PORT) du second serveur, cela fonctionne très bien - ce qui me suggère que le navigateur SQL est en cause, sauf que cela fonctionne correctement localement. serveur et de ma machine de développement.
Des idées et des suggestions? Merci.
Edit: pour clarifier les commentaires, nous allons faire référence aux données SQL Server en tant que SQLA et à la base de données non-SQLB.
Éditer # 2: Ajouter plus de cas de test/informations:
Info: Tous les tests ci-dessus ont été effectués via l'interface SSMS afin d'établir une connexion à la base de données. Les bases de données concernées sont toutes deux 2012.
Nouveau cas de test: j'ai essayé d'exécuter un script pour configurer un serveur lié et j'ai constaté qu'exécuter le script sur une boîte SQL Server 2005 fonctionnait correctement, mais que l'exécution du même script sur le serveur SQL Server 2012 (SQLB) n'a pas réussi à se connecter à SQLA avec l'erreur: Interfaces réseau SQL Server: Erreur lors de la 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 zone de développement, toutes les instances renvoyées avec l'interrogation 1434 sur UDP sont renvoyées. L'exécution de la même requête à partir de SQLB ne renvoie AUCUNE instance et indique 1434 comme étant FILTRÉ alors que sur la zone de développement, il est renvoyé sous LISTING. Je ne peux que penser que cela est lié au pare-feu, sauf que j'ai désactivé le pare-feu sur les deux machines.
Vos cas de test où vous ne pouvez pas vous connecter avec "NomServeur\Instance" mais SONT POUVANT vous connecter au serveur via "NomServeur, Port" est ce qui se produit lorsque vous utilisez un réseau VPN sur un réseau avec Microsoft VPN. (J'ai eu ce problème). Pour mon problème VPN, j'utilise simplement les numéros de port statiques pour le contourner.
Ceci est apparemment dû au fait que le VPN ne transfère pas les paquets UDP et n'autorise que les connexions TCP.
Dans votre cas, votre pare-feu, vos paramètres de sécurité, votre antivirus ou tout autre élément susceptible de bloquer UDP.
Je vous suggère de vérifier le réglage de votre pare-feu pour autoriser spécifiquement UDP.
Au démarrage, SQL Server Browser démarre et revendique le port UDP 1434. SQL Navigateur de serveurs lit le registre et 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 dispose de deux cartes réseau ou plus, SQL Server Browser utilisera renvoyer tous les ports activés pour SQL Server. SQL Server 2005 et SQL Navigateur de serveurs supporte ipv6 et ipv4.
Lorsque les clients SQL Server 2000 et SQL Server 2005 demandent SQL Server ressources, la bibliothèque réseau du client envoie un message UDP au serveur utilisant le port 1434. Le navigateur SQL Server répond avec le protocole TCP/IP port ou canal nommé de l'instance demandée. La bibliothèque réseau sur l'application client complète ensuite la connexion en envoyant un demande au serveur en utilisant le port ou le canal nommé du fichier souhaité exemple.
Utiliser un pare-feu
Pour communiquer avec le service SQL Server Browser sur un serveur protégé par un pare-feu, ouvrez le port UDP 1434 en plus du port TCP utilisé par SQL Server (par exemple, 1433).
Je ne sais pas si c'est la réponse que vous recherchiez, mais cela a fonctionné pour moi. Après avoir tourné mes roues dans le Pare-feu Windows, je suis retourné dans le Gestionnaire de configuration SQL Server, vérifié la configuration réseau de SQL Server, dans les protocoles de l'instance avec laquelle je travaillais ainsi que TCP/IP. Par défaut, il semble que le mien soit désactivé, ce qui permet par exemple les connexions sur la machine locale mais n'utilise pas SSMS sur une autre machine. Activer TCP/IP a fait l'affaire pour moi.
J'ai enfin trouvé le problème ici. Même si le pare-feu a été désactivé aux deux endroits, nous avons constaté qu'un routeur du centre de données SQLB bloquait activement UDP 1434. J'ai pu le déterminer en installant l'outil PorQry de Microsoft ( http://www.Microsoft .com/fr-ca/download/details.aspx? id = 17148 ) et exécuter une requête sur le port UDP. Ensuite, j'ai installé WireShark ( http://www.wireshark.org/ ) pour afficher les détails de la connexion et trouver le routeur en question qui refusait de transmettre la demande. Comme ce routeur n'affecte que SQLB, cela explique pourquoi toutes les autres connexions fonctionnent correctement.
Merci à tous pour vos suggestions et votre aide!
Vous avez essayé beaucoup. Et je ressens pour toi ... Voici une idée. J'ai un peu suivi tout ce que vous avez essayé ... La remarque mentale que j'ai dans ma tête est la suivante: "" Lorsque Sql Server ne se connecte pas lorsque vous avez tout essayé, connectez vos règles de pare-feu au programme, et non Le port"
Je sais que vous avez dit que vous avez désactivé le pare-feu ... Mais quelque chose me dit d'essayer cela de toute façon.
Je pense que vous devez ouvrir le pare-feu "par programme", et non par 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 sur le "programme" que vous essayez d'utiliser sur SQLB?
Est-ce SSMS sur SQLB? Ou un programme client sur SQLB?
MODIFIER...........
Aucune idée si cela aidera… .. Mais j'utilise cela pour cingler des «ports»… et quelque chose qui est en dehors du monde SSMS.
http://www.Microsoft.com/en-us/download/details.aspx?id=24009
Avez-vous des alias de clients définis sur votre machine de développement? Si tel est le cas, définissez-les également sur SQLB. Plus précisément, je soupçonne que vous avez des alias de clients au format InstanceName qui définissent les ports, contournant ainsi les noms d’instance réels et la nécessité (partielle) du navigateur SQL. Cependant, il existe d'autres possibilités avec les alias client, alors assurez-vous qu'ils sont identiques.
Pour rechercher des alias de clients SQL, utilisez le Gestionnaire de configuration SQL Server (dans le menu Démarrer du programme Microsoft SQL). Dans ce menu, accédez à Configuration du client, puis à "Alias".
Autres choses à vérifier:
Que SQLA et SQLB appartiennent au même domaine ou qu’il n’ya pas de problèmes de confiance entre eux.
Assurez-vous que TCP/IP est activé en tant que protocole client dans SQLB (il s’agit également du gestionnaire de configuration SQL).
Dans certaines de vos réponses, je pense que vous avez peut-être oublié le sens de mes déclarations sur les domaines et les trusts. Vous ne pouvez pas vous connecter à un SQL " Serveur\Instance " sauf si la confiance entre le client et le serveur est suffisante. Cela est dû au fait que l'ensemble du schéma de dénomination d'instance utilisé par SQL Sevrer dépend des SPN (noms de principal de service) pour la découverte, l'emplacement et l'autorisation, et que les SPN sont stockés dans l'AD. Par conséquent, à moins que le client ne se trouve sur la même boîte, l'instance doit pouvoir enregistrer son SPN et le client doit pouvoir parcourir la forêt AD dans laquelle l'instance de serveur a enregistré son SPN.
Si vous ne pouvez pas faire cela, les noms d'instance ne fonctionnent pas et vous devez utiliser le numéro de port (ou le nom du canal) à la place. C'est ce que je soupçonne à présent.
- Je devais spécifier un port dans le gestionnaire de configuration SQL> TCP/IP
- Ouvrez le port sur votre pare-feu
- Puis connectez-vous à distance en utilisant: "nom du serveur\autre instance de la base de données, (numéro de port)"
- Connecté!
après avoir passé environ 10 jours à tenter de résoudre ce problème, je l’ai finalement compris aujourd’hui et décidé d’afficher la solution.
dans le menu Démarrer, tapez RUN, ouvrez-le Dans la boîte d'exécution, tapez SERVICES.MSC, cliquez sur OK
assurez-vous que ces deux services sont démarrés SQL Server (MSSQLSERVER) SQL Server Vss writer
J'ai besoin de faire 2 choses pour me connecter avec le nom d'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)
Redémarrer SQL et terminé