Изпитах същия проблем:при достъп до отдалечен сървър с Object Explorer, SSMS ще виси за неопределено време. Регистърът на системните събития на Windows ще покаже DCOM грешка 10009 („DCOM не успя да комуникира с компютъра MACHINE_NAME, използвайки някой от конфигурираните протоколи.“).
Решението беше да изчистя историята на MRU и други настройки от моя профил. За да направите това:
- Затворете всички отворени екземпляри на SSMS 2012
- В Explorer отворете „%AppData%\Microsoft\SQL Server Management Studio“
- Преименувайте папката „11.0“ на нещо друго, като „11.0.old“
- Отворете SSMS 2012
Ще видите, че вашият MRU списък е изчистен. След това трябва да можете да въведете отново своите идентификационни данни и да използвате SSMS както обикновено.
Ако всичко работи, можете да изтриете преименуваната папка. В противен случай изтрийте новата папка „11.0“, която е създадена, и преименувайте оригиналната обратно на „11.0“.
Нямам представа дали всъщност списъкът с MRU причинява този проблем или това са някакви други профилни данни.
Успяхме да открием, че SSMS се опитва да направи DCOM връзка през порт 135 към SQL Server (може би за SSIS, T-SQL отстраняване на грешки или нещо друго). Нашата защитна стена беше конфигурирана да блокира порт 135. Чрез отваряне на порта в защитната стена успяхме да използваме SSMS (оттук и причината да работи срещу локални бази данни, но не и отдалечени). За съжаление, отворен порт 135 е покана за много атаки, така че това не беше практично решение за нас.
