Мне интересно, есть ли политика, которая может быть продвинута, по умолчанию клиент всегда динамически определяет порт для подключения. Я имею дело с настраиваемым приложением C #, которое подключается к удаленному серверу SQL.
Сведения о SQL Server Экземпляр SQL Server 2008 R2 STD Windows Server 2008 STD Строка подключения SQL приложения C # жестко запрограммирована для использования значения по умолчанию 1433 для подключения к данным. Однако имя сервера \ экземпляра - это настраиваемый параметр. SQL Server настроен для привязки экземпляра к определенному IP-адресу и порту 1433 через диспетчер конфигурации. Экземпляр также настроен на разрешение удаленных подключений, и проблем с брандмауэром нет, и я могу проверить это с помощью portqury.exe. Я также могу проверить, что sqlserver.exe прослушивает 1433 через netstat –abn. На сервере есть только один экземпляр, и ни один из IP-адресов интерфейсов не настроен для динамической конфигурации порта. Я хочу добавить, что получаю те же результаты с включенным и отключенным браузером sql. Но поскольку существует только один экземпляр и я не использую динамический порт, мне не нужно использовать службу браузера SQL. Думаю, я должен также добавить, что порт 1434 был открыт и доступен, пока я тестировал с включенной службой браузера. Конфигурация SQL не подлежит сомнению.
Поэтому при тестировании с помощью приложения C # я не могу попасть на сервер базы данных и получить другую ошибку из нескольких систем. Однако, когда я тестирую подключение к экземпляру SQL через ODBC, я могу выполнить аутентификацию в системе (SQL Auth) и попасть в требуемую базу данных. Однако мне нужно внести изменения в конфигурацию клиента при добавлении соединения ODBC для тестирования. Выбор опции для SQL Auth, а затем переход к параметрам конфигурации клиента и снятие флажка для «Динамически определять порт», чтобы он указывал порт 1433 для соединения. После того, как это было добавлено, клиентское программное обеспечение может подключаться без каких-либо дополнительных проблем даже после удаления соединения ODBC, которое я использовал для тестирования.
Здесь и возникает мой главный вопрос. Существует ли политика, которая может заставить все соединения SQL из системы Windows XP, Windows 7 всегда использовать динамический порт для подключения к данным? Почему приложение по-прежнему подключается к SQL через порт 1433 после удаления ODBC-соединения? Думаю, я мог бы пойти немного дальше и провести трассировку процесса с помощью проводника процессов и использовать TCPView для проверки подключения из нового окна к экземпляру SQL, прежде чем удалять параметр из подключений ODBC для «Динамически определять порт» в клиентской системе. .
Любая информация или дополнительные моменты для проверки и дальнейшего исследования были бы замечательными. Я отправил это суперпользователю, так как это, похоже, проблема на стороне клиента, а не проблема конфигурации сервера.
Сторона сервера настроена и привязана к порту 1433 на определенном IP-адресе. Проблема конкретно в том, что клиентская сторона пытается согласовать динамический порт, когда он настроен на статический порт на сервере. В конечном итоге это была настройка клиента в их AV-продукте, не разрешающая подключение к порту 1434 для конкретного приложения.
Я смог динамически запросить порт через ODBC, но не смог сделать это с помощью специального приложения. У меня не было доступа к серверу управления AV или паролю на стороне клиента для просмотра заблокированных соединений. Поскольку я работал в среде, с которой я не справлялся полностью.
Настройка ODBC-соединения на клиентском компьютере (работающем от имени администратора) должна позволить вам установить порт на *, если я правильно помню.
Я предполагаю, что вы проверили это в Microsoft: Как настроить SQL Server для прослушивания определенного порта http://support.microsoft.com/kb/823938
Или, если подумать, Server Client Network Util на самом сервере?