J'ai rencontré le même problème :lors de l'accès à un serveur distant avec l'Explorateur d'objets, SSMS se bloquait indéfiniment. Le journal des événements système de Windows afficherait l'erreur DCOM 10009 ("DCOM n'a pas pu communiquer avec l'ordinateur MACHINE_NAME à l'aide de l'un des protocoles configurés").
La solution était d'effacer l'historique MRU et d'autres paramètres de mon profil. Pour ce faire :
- Fermez toutes les instances ouvertes de SSMS 2012
- Dans l'Explorateur, ouvrez "%AppData%\Microsoft\SQL Server Management Studio"
- Renommer le dossier "11.0" en quelque chose d'autre, comme "11.0.old"
- Ouvrir SSMS 2012
Vous verrez que votre liste MRU a été effacée. Vous devriez alors pouvoir ressaisir vos informations d'identification et utiliser SSMS normalement.
Si tout fonctionne, vous pouvez supprimer le dossier renommé. Sinon, supprimez le nouveau dossier "11.0" qui a été créé et renommez l'original en "11.0".
Je ne sais pas si c'est réellement la liste MRU qui cause ce problème ou s'il s'agit d'autres données de profil.
Nous avons pu découvrir que SSMS tente d'établir une connexion DCOM via le port 135 vers SQL Server (peut-être pour SSIS, le débogage T-SQL ou autre chose). Notre pare-feu a été configuré pour bloquer le port 135. En ouvrant le port dans le pare-feu, nous avons pu utiliser SSMS (d'où la raison pour laquelle il fonctionnait avec des bases de données locales mais pas avec des bases de données distantes). Malheureusement, un port 135 ouvert est une invitation à de nombreuses attaques, ce n'était donc pas une solution pratique pour nous.
