Recebo o seguinte erro ao tentar conectar o SSMS ao Integration Services usando um nome de rede específico do cluster do SQL Server:
A conexão com o serviço Integration Services no computador 'FooDB' falhou com o seguinte erro: "Acesso negado".
Esse erro ocorre quando o computador não foi configurado para permitir conexões remotas por meio de DCOM ou o usuário tem permissão para acessar o serviço SQL Server Integration Services por meio de DCOM.
Este é um problema rotineiro com uma solução bem documentada. Por exemplo, veja as soluções aqui e aqui .
No entanto, tentei todas as soluções que conheço e o problema persiste.
Mais detalhadamente, fiz o seguinte:
Verificado que os usuários conectados têm as permissões DCOM listadas nos artigos vinculados acima em MsDtsServer100:
Permissões de inicialização e ativação: Permitir inicialização local, permitir inicialização remota, ativação local, ativação remota
Permissões de acesso: Permitir acesso local, permitir acesso remoto
Permissão de configuração: Permitir leitura
Confirmado com um sniffer de pacote que todo o tráfego relacionado à conexão está vindo com sucesso através do firewall. O último pacote mostrado antes da conexão TCP ser interrompida é uma resposta do servidor contendo o código de status do Windows para 'acesso negado' dentro de um cabeçalho MSRPC.
Testado adicionando os usuários ao grupo 'Distributed COM Users' e/ou ao grupo de administradores locais e, em seguida, reiniciando os servidores. Isso permitiu que os usuários se conectassem ao SSIS a partir do SSMS usando os nomes dos nós locais (FooDBN1, FooDBN2), mas ainda recebiam um erro de 'acesso negado' ao se conectarem ao nome da rede do cluster (FooDB), que é o que eles estão acostumados usar e o que funciona em nossos outros clusters.
Além disso, não achei necessário alterar a associação desses grupos em outros clusters.
Nos outros clusters que verifiquei, posso conectar o SSMS ao SSIS usando o nome do cluster sem nenhuma configuração não padrão.
Sei que isso pode ser mais apropriado para ServerFault e estou bem com a questão de ser migrada, se necessário, mas também é um problema do SQL Server e acho que os usuários aqui podem ter lidado com isso antes.
Detalhes da plataforma:
- Windows Server 2008 R2 SP1
- SQL Server 2008 R2 SP2
- Cluster ativo-passivo de 2 nós com uma única instância do SQL Server
Alguém poderia sugerir o que eu deveria estar olhando a seguir aqui?
Atualização : isso misteriosamente começou a funcionar hoje, mas apenas para membros do grupo de administradores locais. Nada mudou, tanto quanto eu posso dizer.
Talvez um tiro no escuro, mas vale a pena verificar o arquivo
\Arquivos de programas\Microsoft SQL Server\100\DTS\Binn\MsDtsSrvr.ini
ou o equivalente em sua configuração. Você pode ter que editá-lo manualmente com o nome da instância. Caso contrário, as conexões SSIS podem estar procurando um msdb de uma instância SQL padrão que não existe.
O problema tem algo a ver com permissões no servidor subjacente e não SSIS ou MSDB. Nós tivemos o mesmo problema. Adicionar temporariamente a conta AD do usuário ao grupo de administradores locais corrigiu isso para nós. Adicionar sua conta AD a usuários avançados ou usuários não; no entanto, tenho certeza de que poderíamos ter encontrado o que faltava na Política de Segurança Local para que isso acontecesse.