Я получаю следующую ошибку при попытке подключить SSMS к службам Integration Services с использованием сетевого имени конкретного кластера SQL Server:
Соединение со службой Integration Services на компьютере «FooDB» завершилось ошибкой: «Доступ запрещен».
Эта ошибка возникает, когда компьютер не настроен на разрешение удаленных подключений через DCOM или у пользователя есть разрешение на доступ к службе SQL Server Integration Services через DCOM.
Это обычная проблема с хорошо документированным решением. Например, посмотрите решения здесь и здесь .
Однако я перепробовал все известные мне решения, и проблема остается.
Более подробно я сделал следующее:
Проверено, что у подключающихся пользователей есть разрешения DCOM, перечисленные в статьях, на которые есть ссылки на MsDtsServer100:
Разрешения на запуск и активацию: разрешить локальный запуск, разрешить удаленный запуск, локальную активацию, удаленную активацию
Разрешения на доступ: разрешить локальный доступ, разрешить удаленный доступ
Разрешение конфигурации: разрешить чтение
С помощью анализатора пакетов подтвердил, что весь трафик, связанный с подключением, успешно проходит через брандмауэр. Последний пакет, показанный перед разрывом TCP-соединения, является ответом сервера, содержащим код состояния Windows для «Отказано в доступе» внутри заголовка MSRPC.
Проверено добавление пользователей в группу «Распределенные пользователи COM» и / или группу локальных администраторов, а затем перезапуск серверов. Это позволило пользователям подключаться к SSIS из SSMS с использованием имен локальных узлов (FooDBN1, FooDBN2), но они по-прежнему получают ошибку «Отказано в доступе» при подключении к имени сети кластера (FooDB), к чему они привыкли к использованию, и что работает на других наших кластерах.
Кроме того, я не нашел, что изменение членства этих групп необходимо в других кластерах.
На других кластерах, которые я проверил, я могу подключить SSMS к SSIS, используя имя кластера без какой-либо нестандартной конфигурации.
Я понимаю, что это может быть более подходящим для ServerFault, и я согласен с вопросом переноса, если это необходимо, но это также проблема SQL Server, и я думаю, что пользователи здесь, скорее всего, уже сталкивались с этим раньше.
Детали платформы:
- Windows Server 2008 R2 SP1
- SQL Server 2008 R2 с пакетом обновления 2
- Двухузловый активно-пассивный кластер с одним экземпляром SQL Server
Может ли кто-нибудь подсказать, на что мне следует смотреть дальше?
Обновление : это таинственно только сегодня начал работать, но только для членов группы локальных администраторов. Насколько я могу судить, ничего не изменилось.
источник
Ответы:
Длинный выстрел возможно, но стоит проверить файл
\ Программные файлы \ Microsoft SQL Server \ 100 \ DTS \ Binn \ MsDtsSrvr.ini
или эквивалент по вашей настройке. Возможно, вам придется вручную редактировать его с именем экземпляра. В противном случае соединения SSIS могут искать msdb экземпляра SQL по умолчанию, который не существует.
источник
Эта проблема связана с разрешениями на базовом сервере, а не с SSIS или MSDB. У нас была такая же проблема. Временное добавление учетной записи AD пользователя в группу локальных администраторов исправило это для нас. Добавление своей учетной записи AD в PowerUsers или пользователей не сделал; однако я уверен, что мы могли бы найти то, чего не хватало в Политике локальной безопасности, чтобы это произошло.
источник