Neste post eu compartilharei com você um problema que enfrentei durante a implementação do AX2012 R2 em um cliente no qual atuei durante a ultima semana do mês de Agosto.
Vou primeiramente explicar como está construida a estrutura de servidores para o Dynamics AX2012 R2 de produção.
Criei neste ambiente um cluster de SQL Server 2012 utilizando 02 servidores físicos com Windows Server 2012. O Cluster está funcionando perfeitamente e o AX2012 R2 já esta acessível.
Criei também um cluster de Hyper-V 3.0 utilizando 03 servidores físicos com Windows Server 2012.
Todos os servidores que possuem componentes do AX2012 R2 são virtualizados e possuem o Windows Server 2008 R2 como sistema operacional.
A estrutura ficou basicamente da seguinte forma:
Para terminar a instalação do AX2012 na estrutura descrita acima me falta apenas instalar o componente de Reporting extensions e efetuar o deploy dos reports padrões do AX2012, é ai que me deparei com um problema que me tomou alguns dias de testes e pesquisas.
No servidor de Reporting Services, com Windows Server 2008 R2 SP1 Enterprise, eu executei o setup do SQL Server 2012 e instalei apenas o componente de Reporting Services. Depois da instalação eu abri o Reporting Services Configuration Manager e executei as configurações necessários como criação do banco de dados do SSRS, criação das URL's de serviço e gerenciamento e a contfiguração da conta de execução do SRSS. Utilizei neste caso a mesma conta configurada como BCPROXY no AX2012 R2.
Durante a configuração acima eu criei os bancos apontando para o nome virtual do Cluster de SQL Server, não houve nenhum problema nisso, procedimento normal e que ja fiz diversas vezes.
Após as configurações as URL's estavam totalmente acessiveis, não houve exatamente nenhum problema durante o setup do componente SSRS do SQL Server 2012.
Lembrando que utilizei um Windows Server 2008 R2 SP1 x64 Enterprise para instalar o Reporting Services do SQL Server 2012.
Com tudo "corretamente" configurado eu executei o setup do AX2012 R2 para instalar o componente de Reporting Extensions.
Durante a execução do setup a mensagem de erro abaixo foi exibido:
The reporting server is not set up correctly, and cannot be configured by Setup. For information about setting up a reporting server, see SQL Server Books Online.
Revalidei todas as configurações e tudo estava funcionando perfeitamente, por isso executei novamente o setup do AX e o mesmo erro foi exibido.
Ao analisar os logs gerados durante o setup encontrei a seguinte entrada:
An error occurred during setup of Reporting Services extensions.
Reason: Unable to back up the SQL Server Reporting Services encryption key. The operation failed with error code 2147945104.System.InvalidOperationException: Unable to back up the SQL Server Reporting Services encryption key. The operation failed with error code 2147945104.
Reason: Unable to back up the SQL Server Reporting Services encryption key. The operation failed with error code 2147945104.System.InvalidOperationException: Unable to back up the SQL Server Reporting Services encryption key. The operation failed with error code 2147945104.
A mensagem de erro acima me levou a efetuar varios testes com a "encryption key". Eu consegui efetuar o backup dela manualmente, consegui deleta-la e restaura-la, consegui criar uma nova e após todos estes passos as URL's do SSRS continuavam acessíveis e sem problemas. Após cada passo eu executava novamente o setup do AX2012 R2 e sempre o mesmo erro era logado.
Nestes testes devo ter executado o setup umas 15 vezes ou mais.
Cheguei a reinstalar todo o Reporting Services com novos bancos, mesmo erro com o setup do AX.
Reinstalei novamente o Reporting Services mas agora com uma instancia de SQL local, ou seja, fora do cluster de SQL 2012. Mesmo erro com o setup do AX...
Após esgotar quase todas as minhas possibilidades e também de estar bem próximo do meu prazo para a entrega deste ambiente ao cliente, eu abri um chamado na Microsoft... Infelizmente este é um erro novo e a Microsoft ainda não conseguiu me ajudar com ele, sendo assim, continuei com meus próprios testes...
Em uma nova onda de testes eu resolvi fazer o seguinte:
Por solicitação da Microsoft eu reinstalei o Reporting Services utilizando a conta BCPROXY, isso mesmo, executei o setup do SQL Server e instalei o componente de Reporting Services utilizando a conta BCPROXY, e logo após instalar o Reporting Services eu executei o setup do AX, neste caso eu precisei importar a conta BCPROXY e coloca-la como Administradora de Sistema no AX para seguir com o setup pois caso contrario eu não conseguiria finalizar o setup do AX..... mesmo erro novamente.....
Utilizei o Windows Server 2008 R2 SP1 Enterprise e instalei o Reporting Services do SQL Server 2008 R2 apontando o banco de dados do Reporting Services para o Cluster de SQL 2012.
Mesmo erro no setup do AX...
Depois eu criei um novo servidor com o Windows Server 2012 e instalei nele o Reporting Services do SQL Server 2012 apontando o banco para o cluster do SQL 2012.
Efetuei as 02 configurações acima utilizando também um SQL Server local, standalone... mesmo erro no setup do AX.
Hoje, dia 03/09, finalmente o problema foi resolvido... infelizmente só sei a solução, a causa do problema continua um misterio... caso eu descubra esta causa com certeza eu a compartilharei com vocês.
A solução:
A conta BCPROXY que foi importada para o AX em um passo anterior foi removida da lista de usuários do AX, após isso executei novamente o setup do AX e desta vez a mensagem de erro exibida passou a ser apenas um Warning e com isso consegui instalar os componentes de relatorios.....
Isso mesmo, apenas removi a conta bcproxy da lista de usuários do AX e o componente foi instalado...
Minhas perguntas:
Porque o erro ocorria mesmo quando esta conta não era usuário no AX?
Porque ao remove-la o setup funcionou?
Porque a mensagem de erro passou a ser um warning após remover esta conta do AX?
Não estou convencido de que o problema era a configuração da conta bcproxy no AX, no inicio do setup ela não estava lá e o erro ainda assim ocorria... esta conta foi colocada lá após a abertura do chamado na Microsoft...
Em resumo, o problema foi resolvido, mas a causa real do problema continua desconhecida...
Espero que este post seja útil!
Nenhum comentário:
Postar um comentário