A reportagem abaixo é interessante, de fato vemos que estes dados se aplicam a profissionais que vem de fora, mas para nós, os "produtos nacionais", a realidade infelizmente é outra... uma pena não sermos valorizados...
http://www.networkworld.com/news/2013/032613-microsoft-dynamics-268111.html
Mostrando postagens com marcador Microsoft SQL Server 2012. Mostrar todas as postagens
Mostrando postagens com marcador Microsoft SQL Server 2012. Mostrar todas as postagens
segunda-feira, 20 de maio de 2013
terça-feira, 30 de abril de 2013
Dicas para Sizing do Dynamics AX.
Pessoal, publico este artigo afim de discutir com vocês quais os melhores caminhos para se gerar um documento de Sizing o mais correto possível. Espero que o conteúdo abaixo agregue conhecimento a vocês e que, a partir deste, muitas dicas sejam feitas afim de que eu possa entender e aprender como vocês trabalham para criar o Sizing para seus clientes!
Desta forma acredito que teremos um resultado final útil a todos nós!
Creio que o primeiro passo para criarmos um sizing conciso, que faça sentido frente ao cliente e que o faça se sentir seguro do investimento a ser feito, nós precisamos conhecer a arquitetura do Dynamics AX. Não conhecer estes pontos prejudicará o resultado final do sizing.
Sugiro então a leitura dos links abaixo:
http://go.microsoft.com/fwlink/?LinkId=286895
http://go.microsoft.com/fwlink/?LinkId=286896
Após a leitura acima, podemos dizer que o AX2012 trabalha com uma arquitetura de 03 camadas (Three-Tier Architecture). Esta arquitetura separa os componentes de Banco de Dados, Aplicação e Client, que são os 03 componentes básicos para a instalação do Dynamics AX.
O SQL Server fica na camada de banco de dados e armazena os dados da aplicação em tabelas.
A aplicação (AOS) fica na camada de mesmo nome, e é responsável por executar as logicas contidas nos objetos da aplicação, tais como métodos de tabelas e classes.
A ultima camada é o Client, responsável por exibir os objetos da aplicação tais como formulários e relatórios.
Outros componentes como Workflow, BI, Enterprise Portal, AIF e Help Server precisam ser avaliados e levados em consideração.
Tendo o conhecimento da arquitetura do Dynamics AX e de seus componentes, o responsável pela criação do sizing deverá questionar o cliente até entender por completo suas necessidades e caracteristicas para somente após poder criar este documento de sizing.
Algumas perguntas que devem ser feitas:
Qual o volume máximo de transações esperados por hora durante o horário maior utilização do AX?
Toda a arquitetura de sizing do Dynamics AX deve ser desenhada para suportar o maior numero possível de transações por hora no dia de maior movimento da empresa.
Todas as transações abaixo, mas não somente elas, devem ser consideradas:
Este dado é de extrema importância, obtendo esta informação poderemos estimar o tamanho inicial do banco de dados do Dynamics AX, e com isso dimensionar corretamento o disco correto para o servidor de banco de dados.
Quais módulos serão utilizados no Dynamics AX?
Obter esta informação nos permite determinar a quantidade ideal de servidores, tendo em vista que cada modulo aumenta a quantidade de transações no AX.
Haverá integração do AX com sistemas terceiros?
Entender as necessidades de integração do AX com programas terceiros é importante na construção do sizing. Algumas perguntas podem ajudar a determinar os requisitos de hardware para uma correta integração com o Dynamics AX:
Determinar se customizações serão necessárias ajudará a definir como elas serão implementadas. Vejam este link para entender do que estou falando!
Quantos usuários utilizarão o Microsoft Dynamics AX?
Saber quantos usuários utilizarão o sistema e como eles o acessarão nos ajudará a definir a quantidade correta de servidores de AOS. Também é importante saber se o Enterprise Portal será utilizado e quantas integrações existirão.
O Dynamics AX será acessado de fora da empresa?
Não é recomendado utilizar o Dynamics AX sem a utilização de programas específicos para publicação de aplicações tais como o Remote Desktop Services. Em caso de necessidade de acesso externo, mais servidores serão necessários, e caso existe a necessidade de alta disponibilidade do acesso a este recurso, a quantidade necessária de servidores aumenta.
Obs: Se a latência na rede for maior do que 50ms o uso do Remote Desktop services é aconselhavel.
O Enterprise Portal será utilizado? De que forma?
O Enterprise Portal é utilizado para a exibição do Role Center para o Dynamics AX Client e pode ser utilizado para o acesso a recursos via navegador, Internet Explorer. Analisar a utilização do Enterprise Portal e a necessidade ou não de alta disponibilidade deste recursos é importante.
Haverão muitos trabalhos em lotes?
Dependendo da quantidade de trabalhos em lotes, servidores dedicados serão necessários. também precisamos avaliar qual a disponibilidade requerida para os servidores de lotes do AX. Pode ser necessário a criação de um cluster de AOS para os trabalhos em lotes.
A empresa precisa de um cluster de AOS dedicado?
O Microsoft Dynamics AX permite a criação de cluster de AOS para o balanceamento de carga e alta disponibilidade deste serviço. Para mais informações sobre servidores de Load Balance para AOs consultem este link.
Quantos ambientes serão utilizados na implementação do AX?
Em uma implementação padrão é comum utilizarmos 03 ambientes, Desenvolvimento, Homologação e Produção. Contudo, outros ambientes podem ser uteis e ajudam a evitar problemas. Ambientes como os descritos abaixo podem ser disponibilizados para a implementação caso aprovado pelo cliente.
Treinamento - Ambiente dedicado a treinamento dos usuários. Este é um ambiente simples e limpo, sem customizações ou dados. Este ambiente também é útil para identificar problemas e como o ambiente trabalha de forma nativa.
Pré-Produção - Este é um ambiente idêntico ao ambiente de produção, utilizado para a validação de customizações antes de estar serem migradas em definitivo para a produção. Este também pode servir como um ambiente de testes para identificar problemas em customizações aplicadas em produção de forma errada.
A empresa necessita de alta disponibilidade dos serviços de IIS?
Sabemos que o serviço de IIS é utilizado por vários componentes do AX tais como Web Services, Enterprise Portal e Help Server. Caso a empresa necessite de alta disponibilidade para qualquer destes componentes o numero de servidores aumentará.
A alta disponibilidade de banco de dados é necessária?
Havendo a necessidade de alta disponibilidade de qualquer um dos itens acima, obviamente também será necessário configurar a alta disponibilidade dos serviços de banco de dados! Desta forma deveremos configurar corretamente a quantidade e configuração do hardware para banco de dados. Para mais detalhes sobre alta disponibilidade de SQL Server consultem este link.
Qual o nível de Disaster Recovery exigido pelo cliente?
Todas as implementações do Dynamics AX deveriam incluir um plano de Disaster Recovery. No caso de falha de qualquer dos componentes do Dynamics AX precisamos ser capazes de recuperar as informações e disponibilizar o sistema o quanto antes. O Clustes de SQL Server nos ajuda a ter mais segurança em relação ao banco de dados, mas algumas outras perguntas devem ser feitas:
Qual a estrategia de backup a ser utilizada?
A estrategia de backup deve incluir qual o melhor tipo de backup (Full, Diferencial ou Transaction Log), a frequência do backup e onde os arquivos de backup serão armazenados. Logicamente a estrategia deve envolver o processo de restore deste backup em um ambiente de testes afim de validar a integridade dos backups. Analise também o espaço em disco necessário para um backup full e se a compressão de arquivo será utilizada nas rotinas de backup. Outras dicas podem ser encontradas neste link.
Para nos ajudar a construir o sizing ideal existem alguns Guidelines que podem nos ajudar. Atenção a este ponto pois cada sizing varia de acordo com as necessidades de cada cliente, os guidelines indicados aqui servem somente como um parâmetro inicial e devem ser considerados como tal.
Database Server Sizing Guidelines
O sizing para o banco de dados do Microsoft Dynamics AX deverá ser baseado no volume de transações concorrentes. É mais importante entender a quantidade e carga das transações do que saber a quantidade de usuários concorrentes.
O guideline para banco de dados inclui o seguinte:
O servidor deverá ser dedicado ao banco de dados do Dynamics AX.
CPU - O servidor deverá possuir um núcleo de processador para cada 4 ou 12 mil transações por hora, com um minimo de 04 núcleos. Por exemplo, uma empresa que insere 48mil transações por hora deverá possuir um servidor com 04 a 12 núcleos de processador.
Memoria - Para cada núcleo de processador é necessário ter de 02 a 04GB RAM. Portanto, em um servidor com 08 núcleos precisaríamos de um minimo de 16GB RAM ou máximo de 32GB.
Storage - Arquivos de dados, logs e tempdb devem ser armazenados em RAID 10. Logicamente o disco deverá possuir espaço o suficiente para suportar o volume de dados do AX.
Application Object Server (AOS) Sizing Guidelines
Este guideline deverá ser utilizado como ponto de partida, mas outros elementos como módulos a serem utilizados, integrações e customizações devem ser levadas em considerações na geração do sizing final.
Assim como o servidor de banco de dados, o AOS Server deve ser configurado tendo como base o volume de transações, logicamente a quantidade de usuários deverá ser levada em consideração.
CPU - O servidor deverá possuir um núcleo de processador para cada 4 ou 12 mil transações por hora. Um núcleo também deverá existir para cada 25/100 usuários concorrentes.
Memoria - 04GB ou 08GB RAM devem ser alocados para cada AOS.
Obs: Uma alternativa é criar servidores de AOS com 04 núcleos de processador e 08GB RAM e adicionar mais servidores de AOS a cada 48mil transações por hora ou a cada 250 usuários concorrentes.
Batch Server - Servidores de AOS utilizados como servidores de lotes devem possuir de 01 a 04 threads alocados para cada núcleo.
Enterprise Portal Sizing Guidelines
CPU - O servidor de Enterprise Portal deverá possuir de 2 a 16 núcleos dependendo do numero de usuários e complexidade das transações. Normalmente 01 núcleo para cada 120 usuários deve ser adicionado.
Memoria - 02GB RAM devem ser alocados para cada núcleo de processador.
Terminal Server Sizing Guidelines
Ao criar o sizing para este serviço é necessário, logicamente, considerar a quantidade de usuários que vão utilizar este serviço para determinar a configuração do servidor. Este servidor possivelmente terá aplicativos como o Microsoft Office e outros e por esta razão a configuração do servidor sofrerá alterações.
CPU - Um minimo de 02 núcleos devem ser alocados para servidores de RDS.
Memoria - Um minimo de 04GB RAM devem ser alocados para este servidor. Deverão ser alocados 200MB para cada usuário a que vai acessar este servidor.
Rede - Caso a latência da rede local seja maior do que 50ms ou seja necessário efetuar o acesso ao AX de fora da rede é indicada a utilização do RDS.
Benchmarks
Para ajudar a construir sizing ideal é indicado a utilização dos documentos de benchmark gerados pela Microsoft. Estes documentos podem ser adquiridos através deste link. A leitura destes documentos é importante!
Espero que este post gere uma discussão saudável e que o final dela seja a melhor pratica para a geração do sizing para o Microsoft Dynamics AX.
Este post foi baseado em diversas documentações da Microsoft, ao encontrar falhas no post como erros de português ou mesmo informações incorretas ficarei grato se me corrigirem! Erros acontecem!
Este post será constantemente atualizado visando melhorar o conteúdo e também meu entendimento sobre os assuntos aqui escritos.
"Este post foi criado baseado em diversas documentações da Microsoft, mas apesar disso este post reflete apenas a minha opinião de forma que a empresa Microsoft nada tem a ver com o que escrevi aqui."
Desta forma acredito que teremos um resultado final útil a todos nós!
Creio que o primeiro passo para criarmos um sizing conciso, que faça sentido frente ao cliente e que o faça se sentir seguro do investimento a ser feito, nós precisamos conhecer a arquitetura do Dynamics AX. Não conhecer estes pontos prejudicará o resultado final do sizing.
Sugiro então a leitura dos links abaixo:
http://go.microsoft.com/fwlink/?LinkId=286895
http://go.microsoft.com/fwlink/?LinkId=286896
Após a leitura acima, podemos dizer que o AX2012 trabalha com uma arquitetura de 03 camadas (Three-Tier Architecture). Esta arquitetura separa os componentes de Banco de Dados, Aplicação e Client, que são os 03 componentes básicos para a instalação do Dynamics AX.
O SQL Server fica na camada de banco de dados e armazena os dados da aplicação em tabelas.
A aplicação (AOS) fica na camada de mesmo nome, e é responsável por executar as logicas contidas nos objetos da aplicação, tais como métodos de tabelas e classes.
A ultima camada é o Client, responsável por exibir os objetos da aplicação tais como formulários e relatórios.
Outros componentes como Workflow, BI, Enterprise Portal, AIF e Help Server precisam ser avaliados e levados em consideração.
Tendo o conhecimento da arquitetura do Dynamics AX e de seus componentes, o responsável pela criação do sizing deverá questionar o cliente até entender por completo suas necessidades e caracteristicas para somente após poder criar este documento de sizing.
Algumas perguntas que devem ser feitas:
Qual o volume máximo de transações esperados por hora durante o horário maior utilização do AX?
Toda a arquitetura de sizing do Dynamics AX deve ser desenhada para suportar o maior numero possível de transações por hora no dia de maior movimento da empresa.
Todas as transações abaixo, mas não somente elas, devem ser consideradas:
- Linhas Ordens de Venda
- Linhas de Ordem de Compra
- Linhas de Ordens de Produção
Este dado é de extrema importância, obtendo esta informação poderemos estimar o tamanho inicial do banco de dados do Dynamics AX, e com isso dimensionar corretamento o disco correto para o servidor de banco de dados.
Quais módulos serão utilizados no Dynamics AX?
Obter esta informação nos permite determinar a quantidade ideal de servidores, tendo em vista que cada modulo aumenta a quantidade de transações no AX.
Haverá integração do AX com sistemas terceiros?
Entender as necessidades de integração do AX com programas terceiros é importante na construção do sizing. Algumas perguntas podem ajudar a determinar os requisitos de hardware para uma correta integração com o Dynamics AX:
- Qual sistema será integrado ao Microsoft Dynamics AX?
- Qual o método de transporte a ser utilizado?
- O método de transporte ajudará a definir quantos servidores serão necessários para a integração. Por exemplo, a utilização do sistema de arquivos para um sistema externo talvez exija a utilização de um servidor de FTP. Ou a utilização do AIF vai exigir a utilização de um servidor de IIS.
- O método de comunicação deverá ser Síncrono ou Assíncrono?
- Se documentos precisam ser enviados ou recebidos em uma determinada ordem a comunicação síncrona será exigida para que um documento não seja enviado até que o primeiro não seja recebido por completo.
Determinar se customizações serão necessárias ajudará a definir como elas serão implementadas. Vejam este link para entender do que estou falando!
Quantos usuários utilizarão o Microsoft Dynamics AX?
Saber quantos usuários utilizarão o sistema e como eles o acessarão nos ajudará a definir a quantidade correta de servidores de AOS. Também é importante saber se o Enterprise Portal será utilizado e quantas integrações existirão.
O Dynamics AX será acessado de fora da empresa?
Não é recomendado utilizar o Dynamics AX sem a utilização de programas específicos para publicação de aplicações tais como o Remote Desktop Services. Em caso de necessidade de acesso externo, mais servidores serão necessários, e caso existe a necessidade de alta disponibilidade do acesso a este recurso, a quantidade necessária de servidores aumenta.
Obs: Se a latência na rede for maior do que 50ms o uso do Remote Desktop services é aconselhavel.
O Enterprise Portal será utilizado? De que forma?
O Enterprise Portal é utilizado para a exibição do Role Center para o Dynamics AX Client e pode ser utilizado para o acesso a recursos via navegador, Internet Explorer. Analisar a utilização do Enterprise Portal e a necessidade ou não de alta disponibilidade deste recursos é importante.
Haverão muitos trabalhos em lotes?
Dependendo da quantidade de trabalhos em lotes, servidores dedicados serão necessários. também precisamos avaliar qual a disponibilidade requerida para os servidores de lotes do AX. Pode ser necessário a criação de um cluster de AOS para os trabalhos em lotes.
A empresa precisa de um cluster de AOS dedicado?
O Microsoft Dynamics AX permite a criação de cluster de AOS para o balanceamento de carga e alta disponibilidade deste serviço. Para mais informações sobre servidores de Load Balance para AOs consultem este link.
Quantos ambientes serão utilizados na implementação do AX?
Em uma implementação padrão é comum utilizarmos 03 ambientes, Desenvolvimento, Homologação e Produção. Contudo, outros ambientes podem ser uteis e ajudam a evitar problemas. Ambientes como os descritos abaixo podem ser disponibilizados para a implementação caso aprovado pelo cliente.
Treinamento - Ambiente dedicado a treinamento dos usuários. Este é um ambiente simples e limpo, sem customizações ou dados. Este ambiente também é útil para identificar problemas e como o ambiente trabalha de forma nativa.
Pré-Produção - Este é um ambiente idêntico ao ambiente de produção, utilizado para a validação de customizações antes de estar serem migradas em definitivo para a produção. Este também pode servir como um ambiente de testes para identificar problemas em customizações aplicadas em produção de forma errada.
A empresa necessita de alta disponibilidade dos serviços de IIS?
Sabemos que o serviço de IIS é utilizado por vários componentes do AX tais como Web Services, Enterprise Portal e Help Server. Caso a empresa necessite de alta disponibilidade para qualquer destes componentes o numero de servidores aumentará.
A alta disponibilidade de banco de dados é necessária?
Havendo a necessidade de alta disponibilidade de qualquer um dos itens acima, obviamente também será necessário configurar a alta disponibilidade dos serviços de banco de dados! Desta forma deveremos configurar corretamente a quantidade e configuração do hardware para banco de dados. Para mais detalhes sobre alta disponibilidade de SQL Server consultem este link.
Qual o nível de Disaster Recovery exigido pelo cliente?
Todas as implementações do Dynamics AX deveriam incluir um plano de Disaster Recovery. No caso de falha de qualquer dos componentes do Dynamics AX precisamos ser capazes de recuperar as informações e disponibilizar o sistema o quanto antes. O Clustes de SQL Server nos ajuda a ter mais segurança em relação ao banco de dados, mas algumas outras perguntas devem ser feitas:
- Que tecnologia será utilizada na criação do plano de Disaster Recovery?
- Qual o intervalo aceitável de perda de dados?
- Quanto o tempo aceitável para a disponibilização do sistema?
- Onde serão disponibilizados os dados de backup? Onde será o Disaster Recovery Site?
- Este local deverá sempre ser fora da infra estrutura da empresa de forma a evitar problemas físicos e desastres naturais!
Qual a estrategia de backup a ser utilizada?
A estrategia de backup deve incluir qual o melhor tipo de backup (Full, Diferencial ou Transaction Log), a frequência do backup e onde os arquivos de backup serão armazenados. Logicamente a estrategia deve envolver o processo de restore deste backup em um ambiente de testes afim de validar a integridade dos backups. Analise também o espaço em disco necessário para um backup full e se a compressão de arquivo será utilizada nas rotinas de backup. Outras dicas podem ser encontradas neste link.
Para nos ajudar a construir o sizing ideal existem alguns Guidelines que podem nos ajudar. Atenção a este ponto pois cada sizing varia de acordo com as necessidades de cada cliente, os guidelines indicados aqui servem somente como um parâmetro inicial e devem ser considerados como tal.
Database Server Sizing Guidelines
O sizing para o banco de dados do Microsoft Dynamics AX deverá ser baseado no volume de transações concorrentes. É mais importante entender a quantidade e carga das transações do que saber a quantidade de usuários concorrentes.
O guideline para banco de dados inclui o seguinte:
O servidor deverá ser dedicado ao banco de dados do Dynamics AX.
CPU - O servidor deverá possuir um núcleo de processador para cada 4 ou 12 mil transações por hora, com um minimo de 04 núcleos. Por exemplo, uma empresa que insere 48mil transações por hora deverá possuir um servidor com 04 a 12 núcleos de processador.
Memoria - Para cada núcleo de processador é necessário ter de 02 a 04GB RAM. Portanto, em um servidor com 08 núcleos precisaríamos de um minimo de 16GB RAM ou máximo de 32GB.
Storage - Arquivos de dados, logs e tempdb devem ser armazenados em RAID 10. Logicamente o disco deverá possuir espaço o suficiente para suportar o volume de dados do AX.
Application Object Server (AOS) Sizing Guidelines
Este guideline deverá ser utilizado como ponto de partida, mas outros elementos como módulos a serem utilizados, integrações e customizações devem ser levadas em considerações na geração do sizing final.
Assim como o servidor de banco de dados, o AOS Server deve ser configurado tendo como base o volume de transações, logicamente a quantidade de usuários deverá ser levada em consideração.
CPU - O servidor deverá possuir um núcleo de processador para cada 4 ou 12 mil transações por hora. Um núcleo também deverá existir para cada 25/100 usuários concorrentes.
Memoria - 04GB ou 08GB RAM devem ser alocados para cada AOS.
Obs: Uma alternativa é criar servidores de AOS com 04 núcleos de processador e 08GB RAM e adicionar mais servidores de AOS a cada 48mil transações por hora ou a cada 250 usuários concorrentes.
Batch Server - Servidores de AOS utilizados como servidores de lotes devem possuir de 01 a 04 threads alocados para cada núcleo.
Enterprise Portal Sizing Guidelines
CPU - O servidor de Enterprise Portal deverá possuir de 2 a 16 núcleos dependendo do numero de usuários e complexidade das transações. Normalmente 01 núcleo para cada 120 usuários deve ser adicionado.
Memoria - 02GB RAM devem ser alocados para cada núcleo de processador.
Terminal Server Sizing Guidelines
Ao criar o sizing para este serviço é necessário, logicamente, considerar a quantidade de usuários que vão utilizar este serviço para determinar a configuração do servidor. Este servidor possivelmente terá aplicativos como o Microsoft Office e outros e por esta razão a configuração do servidor sofrerá alterações.
CPU - Um minimo de 02 núcleos devem ser alocados para servidores de RDS.
Memoria - Um minimo de 04GB RAM devem ser alocados para este servidor. Deverão ser alocados 200MB para cada usuário a que vai acessar este servidor.
Rede - Caso a latência da rede local seja maior do que 50ms ou seja necessário efetuar o acesso ao AX de fora da rede é indicada a utilização do RDS.
Benchmarks
Para ajudar a construir sizing ideal é indicado a utilização dos documentos de benchmark gerados pela Microsoft. Estes documentos podem ser adquiridos através deste link. A leitura destes documentos é importante!
Espero que este post gere uma discussão saudável e que o final dela seja a melhor pratica para a geração do sizing para o Microsoft Dynamics AX.
Este post foi baseado em diversas documentações da Microsoft, ao encontrar falhas no post como erros de português ou mesmo informações incorretas ficarei grato se me corrigirem! Erros acontecem!
Este post será constantemente atualizado visando melhorar o conteúdo e também meu entendimento sobre os assuntos aqui escritos.
"Este post foi criado baseado em diversas documentações da Microsoft, mas apesar disso este post reflete apenas a minha opinião de forma que a empresa Microsoft nada tem a ver com o que escrevi aqui."
domingo, 4 de novembro de 2012
Cluster SQL Server 2008 R2 SP2
Passei por um problema enquanto configurava o serviço de Cluster para o SQL Server 2008 R2 em um cliente e deixo aqui a dica de como resolver este problema...
O problema ocorreu no momento em que defini o IP e nome do Cluster, ao clicar em avançar o processo era finalizado mas o serviço do Cluster não era iniciado, ao verificar o Event Viewer havia o seguinte erro:
Resumindo, a conta de usuário que eu estava utilizando ultrapassou o limite para criação de objetos na unidade organizacional do AD, sem poder criar objetos no AD eu não poderia concluir o Cluster...
Para corrigir este problema foi necessário utilizar a ferramenta ADSIEDIT.MSC e alterar o numero de objetos que a minha conta de usuário poderia criar no AD.
Abra a ferramenta ADSIEDIT.MSC conect-se ao seu dominio e expanda os nós como na imagem abaixo clicando com o botão direito do mouse e escolhendo a opção "propriedades".
Agora nesta janela encontre a opção "ms-DS-MachineAccountQuota 0", note que o valor está em "0" (Zero), selecione-a e clique em "Edit",
Altere o valor conforme a necessidade e clique em "aplicar" e depois clique em "Ok".
Depois de seguir os passos acima pude prosseguir normalmente e finalizar a instalação do SQL Server 2008 R2 SP2 em Cluster Multi-Instancia para realizar a instalação do Microsoft Dynamics AX2009 RU8!!!
Fonte: Microsoft
O problema ocorreu no momento em que defini o IP e nome do Cluster, ao clicar em avançar o processo era finalizado mas o serviço do Cluster não era iniciado, ao verificar o Event Viewer havia o seguinte erro:
Resumindo, a conta de usuário que eu estava utilizando ultrapassou o limite para criação de objetos na unidade organizacional do AD, sem poder criar objetos no AD eu não poderia concluir o Cluster...
Para corrigir este problema foi necessário utilizar a ferramenta ADSIEDIT.MSC e alterar o numero de objetos que a minha conta de usuário poderia criar no AD.
Abra a ferramenta ADSIEDIT.MSC conect-se ao seu dominio e expanda os nós como na imagem abaixo clicando com o botão direito do mouse e escolhendo a opção "propriedades".
Agora nesta janela encontre a opção "ms-DS-MachineAccountQuota 0", note que o valor está em "0" (Zero), selecione-a e clique em "Edit",
Altere o valor conforme a necessidade e clique em "aplicar" e depois clique em "Ok".
Depois de seguir os passos acima pude prosseguir normalmente e finalizar a instalação do SQL Server 2008 R2 SP2 em Cluster Multi-Instancia para realizar a instalação do Microsoft Dynamics AX2009 RU8!!!
Fonte: Microsoft
quinta-feira, 4 de outubro de 2012
Upgrade de licença SQL Server 2008R2!
Deixo abaixo uma dica útil sobre como fazer um upgrade de licença do SQL Server 2008 R2, esta dica é valida nos casos onde temos um SQL Server Trial ou Evaluation Version e adquirimos uma licença Standard ou Enterprise, ou até mesmo quando queremos mudar do Standard para Enterprise!
Então vamos lá!
Insira o DVD de instalação do SQL Server ou execute o Setup de instalação, na tela inicial escolha a opção Maintenance, no painel da esquerda, veja o exemplo da imagem abaixo:
Agora, do lado direito, clique em "Edition Upgrade" e aguarde.
Clique em OK.
No meu caso este teste foi feito em uma VM, sendo assim este alerta exibido não é valido!
Caso tudo esteja ok clique em NEXT.
Digite o novo serial e clique em NEXT.
Basta continuar com o Setup e no fim teremos o serial inserido no SQL e este será atualizado!
Execute este setup uma vez para cada instancia do SQL Server!
domingo, 18 de março de 2012
SPED PIS/COFINS Parte 9 - Instalando Service Pack
Com o serviço iniciado devemos agora aplicar o Service pack, acesse o portal da Sonda e efetue o download do aqruivos, o download deve ser feito selecionando o arquivo e clicando no botão "Baixe uma Cópia", nunca efetue o download clicando sobre o arquivo.
Acesse o diretorio como na imagem abaixo e execute o "ServerConfig.exe".
Preencha os campoas como na imagem abaixo e clique no botão "Carregar Arquivos".
Caso tenha duvidas sobre qual o arquivo de conexão, acesse o diretorio como na imagem abaixo para verificar.
Clique em "Sim. Desejo Carregar um arquivo Compactado".
Selecione o arquivo que fizemos download.
Após clicar em executar aguarde o processo, veja que na imagem abaixo todos estão verdes, se aparecer algum vermelho algo errado ocorreu, repita o processo de aplicação do service pack até que não haja nenhum ponto vermelho!
Após a aplicação do service pack vamos aplicar mais alguns arquivos de atualização.
Você deve se perguntar porque aplicar tanta atualização? Quando descobrir esta resposta por favor me avise!!!
Clique em "Sim. Desejo Carregar um arquivo Compactado".
Selecione o arquivo que fizemos download.
Após clicar em executar aguarde o processo, veja que na imagem abaixo todos estão verdes, se aparecer algum vermelho algo errado ocorreu, repita o processo de aplicação do service pack até que não haja nenhum ponto vermelho!
Você deve se perguntar porque aplicar tanta atualização? Quando descobrir esta resposta por favor me avise!!!
quinta-feira, 2 de fevereiro de 2012
SPED PIS/COFINS Parte 8 - Criação do Serviço no Windows
Após instalar o PW.SPED PIS/COFINS devemos criar corretamente o serviço para o SPED PIS/COFINS, para isso é necessário para o serviço que é iniciado após a instalação, verifique ao lado do relógio do Windows o ícone, clique com o botão direito do mouse sobre ele e feche-o
Abra o Command Prompt como administrador para não haver erros!
Acesse o diretorio do .NET Framework 4 de acordo com a versão do seu sistema operacional.
Versão 32 bits:
cd c:\Windows\Microsoft.NET\Framework\v4.0.30319
Versão 64bits:
cd c:\Windows\Microsoft.NET\Framework64\v4.0.30319
Após acessar o diretório correto vamos executar o comando para a criação do serviço no Windows para o SPED PIS/COFINS, muita atenção neste comando...
O comando é o seguinte:
InstallUtil.exe /i /name="SPED_PISCOFINS" /config="AX5-W8-01_9500.xml" "C:\Program Files\Sonda Software\Sonda Software Application Server 1.5\Servers\ProcworkServiceFrame.exe"
Neste comando precisamos mudar 3 parâmetros, são eles:
SPED_PISCOFINS - Este é o nome do serviço a ser criado no Windows, mude o nome caso queira!
AX5-W8-01_9500.xml - Este é o nome do arquivo de conexão criado na Parte 7 do tutorial, você pode verificar o nome deste arquivo acessando o seguinte diretório no servidor: C:\Arquivos de programas\Sonda Software\Sonda Software Application Server 1.5\Servers\Connections
E por ultimo o diretório C:\Arquivos de programas\Sonda Software\Sonda Software Application Server 1.5\Servers, você deve informar o caminho da pasta onde está localizado o arquivo ProcworkServiceFrame.exe, altere este diretório de acordo com o seu sistema operacional.
No meu caso, em uma VM da Microsoft, o comando ficou exatamente como mostrado na imagem abaixo:
Se o comando for executado corretamente a mensagem abaixo deverá ser exibida. Caso ocorram erros verifique o comando dando atenção a espaços e aspas (") na linha.
Após executar com sucesso o comando, abra o "services.msc" e inicie o serviço criado.
Acesse o diretorio do .NET Framework 4 de acordo com a versão do seu sistema operacional.
Versão 32 bits:
cd c:\Windows\Microsoft.NET\Framework\v4.0.30319
Versão 64bits:
cd c:\Windows\Microsoft.NET\Framework64\v4.0.30319
Após acessar o diretório correto vamos executar o comando para a criação do serviço no Windows para o SPED PIS/COFINS, muita atenção neste comando...
O comando é o seguinte:
InstallUtil.exe /i /name="SPED_PISCOFINS" /config="AX5-W8-01_9500.xml" "C:\Program Files\Sonda Software\Sonda Software Application Server 1.5\Servers\ProcworkServiceFrame.exe"
Neste comando precisamos mudar 3 parâmetros, são eles:
SPED_PISCOFINS - Este é o nome do serviço a ser criado no Windows, mude o nome caso queira!
AX5-W8-01_9500.xml - Este é o nome do arquivo de conexão criado na Parte 7 do tutorial, você pode verificar o nome deste arquivo acessando o seguinte diretório no servidor: C:\Arquivos de programas\Sonda Software\Sonda Software Application Server 1.5\Servers\Connections
E por ultimo o diretório C:\Arquivos de programas\Sonda Software\Sonda Software Application Server 1.5\Servers, você deve informar o caminho da pasta onde está localizado o arquivo ProcworkServiceFrame.exe, altere este diretório de acordo com o seu sistema operacional.
No meu caso, em uma VM da Microsoft, o comando ficou exatamente como mostrado na imagem abaixo:
Se o comando for executado corretamente a mensagem abaixo deverá ser exibida. Caso ocorram erros verifique o comando dando atenção a espaços e aspas (") na linha.
Após executar com sucesso o comando, abra o "services.msc" e inicie o serviço criado.
Com o serviço corretamente criado e iniciado, vamos ao próximo passo!!
segunda-feira, 21 de novembro de 2011
Microsoft SQL Server 2012!
Now it is possible to download the Microsoft SQL Server 2012 versions from the Microsoft Download Center. You can see the difference between versions and download the release candidate from the following page:
http://www.microsoft.com/sqlserver/en/us/future-editions/sql2012-editions.aspx
http://www.microsoft.com/sqlserver/en/us/future-editions/sql2012-editions.aspx
Assinar:
Postagens (Atom)