[bing_translator]
A utilização de Proxy Account para execução de pacotes SSIS dentro do SQL Server Agent é um procedimento para utilização de usuários que não são SYSADMIN executarem pacotes com outras credencias que não é a da conta de serviço do SQL Server Agent.
Existem varias referencias de como criar e utilizar Proxy Account porem eu passei por um problema com a utilização desse cenário.
Cenario:
Um pacote SSIS , que está armazenado em file system, com uma funcionalidade que deve ler um arquivo EXCEL em uma pasta compartilhada na rede e carregar os dados para outro lugar usando um login Windows.
A pasta compartilhada está em um domínio (Domínio A) e a servidor de Integration Services está em outro domínio (Domínio B)
Problema:
Tudo parecia perfeito, credencial criada, proxy account criada e associada corretamente , job criado correto porem na hora de executar o job o seguinte erro era apresentado:
Error:
Code: 0xC0202009
Source: Excel Source [705]
Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
End Error
Error:
Code: 0xC02020E8
Source: Excel Source [705]
Description: Opening a rowset for “Plan1$” failed. Check that the object exists in the database.
End Error
Error:
Code: 0xC004706B
Source: SSIS.Pipeline
Description: “component “Excel Source” (705)” failed validation and returned validation status “VS_ISBROKEN”.
End Error
A primeira tentativa de solucionar foi validar a mensagem de erro que dizia que ao abrir a “Plan1$” a operação falhou! Abri o pacote, verifiquei todas a conexões, tentei alterar algumas configurações do pacote e nada adiantou, tudo correto!
Solução:
Depois de um tempo pude perceber que o primeiro erro não estava na falha ao tentar abrir o arquivo “Plan1$” e isso era consequência.
Comecei a analisar a primeira mensagem: Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
Após pesquisar um pouco na internet achei o seguinte artigo:
Quando cheguei ao item C apareceu um luz no fim do túnel para mim. Porem agora o problema era saber qual pasta dar permissão.
Nesse momento fui validar as variáveis de ambiente para tentar descobrir onde ficaria a pasta TEMP que o artigo dizia que deve ter permissão.
Imagem 01
Agora sim!!! Tinha todas as informações e concedido acesso de leitura e escrita para o usuário do proxy account nessa pasta especifica. Hora de testar o JOB e adivinhem: mesmo erro novamente! Sinceramente não sabia o motivo do erro, pois uma vez que dei permissão na pasta e tudo o que o artigo falava estava correto, não sabia o motivo de não funcionar .
Sem saber o que fazer, surgiu a ideia de usar o Process Monitor (sysinternal) para tentar validar o que estava acontecendo no Windows. Depois de algum tempo analisando o processo e o erro consegui achar a seguinte informação:
Acesso negado em um pasta!!! Mais uma vez uma luz apareceu porem sem saber o motivo do processo usar o usuário “Default” e a pasta “Temporary Internet Files”.
Enfim, para resolver o problema concedi permissão de escrita e leitura dentro da pasta “C:\User\Default\AppData\Local” para o usuário do Proxy Account e executei novamente o JOB que dessa vez terminou com sucesso!!!
Não sou especialista em SSIS para entender o funcionamento interno, porem somente com uso da ferramenta Process Monitor foi possível verificar o que realmente o processo fazia e onde ele precisava de permissão.