Discussion :

[agdid04]

Bonjour,

Dans 1er temps, je cherche à savoir si y a moyen de simuler une connection distance en LOCAL ?

Puis, à partir d'un autre server j'ai essayé de joindre ma base mais j'ai cette erreur voir copie ecran en pieèce-jointe.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
A network-related or instance-specific error occurred while establishing a connection to SQL Server.
The server was nout found or was not accessible ....
Provider: SQL Network Interface, error: 26- Error Locating Server/Instance dpecified)

J'ai bien le port d'écoute ouvert, TCP activé et les connexions à distance ok ....

Je viens de lancer cette requ^te:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT session_id,net_transport,local_net_address,local_tcp_port
FROM sys.dm_exec_connections;

J'ai NULL à la place de port tcp (copie ecran 2 pasport) alors dans Configuration Manager j'ai bien un port et qui est ouvert ...

Est ce qu'il faut rebooter le server car je viens d'installer mon instance ...?


MERCI.

A+

[Michel.Priori]

Est ce qu'il faut rebooter le server car je viens d'installer mon instance ...?

Dans le doute reboote
Au moins redémarrer le service (le conseil est normalement affiché, de mémoire)

D'autre part est-ce que
- les informations de connexions sont les mêmes entre le test en local et le test distant ?
- nslookup du nom du serveur (ou un ping) atteste bien de la résolution IP ?

[agdid04]

Bonsoir,

Merci, j'ai bien redémarré le service, le ping de server répond bien ....j'attends une fenetre pour rebooter car server mutualisé ....

A+

[SQLpro]

Avez vous regardé que dans le "SQL Server configuration manager" (gestionnaire de configuration de SQL Server) les protocoles réseaux soient bien activés pour votre instance ?

Avez-vous activé l'accès distant dans la configuration de votre instance ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

EXEC sp_configure 'remote access'

Plus généralement, vérifiez ces éléments :
https://docs.microsoft.com/fr-fr/sql...ql-server-2017

A +

[StringBuilder]

C'est vrai que j'ai jamais pigé pourquoi sur les versions Express et Developper, les protocoles réseau sont activés par défaut, mais pas sur la version Professional...

[agdid04]

Bonjour,

Merci.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
EXEC sp_configure 'remote access'
 
name	minimum	maximum	config_value	run_value
remote access	0	1	1	1

A+

[SQLpro]

C'est vrai que j'ai jamais pigé pourquoi sur les versions Express et Developper, les protocoles réseau sont activés par défaut, mais pas sur la version Professional...

Pour des raisons de sécurité. En général Express est dédié à des activités non professionnelles. Tandis que la version Enterprise…. comme son nom l'indique….

A +

[StringBuilder]

Je suis d'accord sur la sécurisation au max...
Sauf que :
1/ En vue d'harmoniser les comportements, il faudrait aussi le bloquer par défaut sur Express, et intégrer cette configuration à l'installeur
2/ SQL Server, comme son nom l'indique, et comme Microsoft le recommande, est censé tourner sur un serveur, dédié qui plus est, et donc on n'y accédera que par le réseau, d'autant plus pour les éditions destinées à la production

Du coup je trouve ça moyennement cohérent

[Michel.Priori]

donc on n'y accédera que par le réseau

Effectivement le conseil est de l'installer sur un serveur dédié.
Parallèlement, je pense que M$ sait très bien ce qu'on fait de ses conseils (ne pas l'installer sur un DC, revoir les paramètres de l'antivirus, appliquer les mises à jours, et j'en passe ...).

Du coup le seul protocole autorisé par défaut est bien "memory" qui suppose justement que le serveur ne soit pas dédié.
Mais ça a l'avantage d'alerter sur les trucs à faire après installation

[StringBuilder]

Je trouve juste pas logique que les versions de dev ne soient pas configurées par défaut de la même manière.

D'autant qu'autant un serveur de PROD, même si les chances sont réduites, on a quelques chances qu'un DBA et qu'un SysAdmin qui ait passé quelques minutes pour vérifier la configuration... autant un poste de DEV, c'est certain que personne se souciera de la sécurité... pourtant on y trouve à peu près toutes les mêmes informations que sur le serveur de PROD.

Et autre point, les DEV sont trop souvent peu éduqués à propos de la sécurité (et des performances). Les plonger dans le vif du sujet directement sur leur machine de dev est pourtant une bonne méthode pour les sensibiliser à la chose.

Dommage donc.

Et accessoirement, effectivement, je suis tombé sur ça lors de l'installation d'une solution ERP chez un de nos clients...
Après m'être fait bouler par le support car j'avais osé installer SQL Server et le serveur de traitement sur deux machines différentes, j'ai quelque peu eu le palpitant en arrêt quelques minutes...



Ou comment justifier de ne pas respecter les pré-requis de SQL Server parce que le bouzin fait des milliers de requêtes dans des boucles au lieu de faire des jointures...