Conectando os Produtos System Center para Melhor Integração
Muitos que usam os produtos System Center 2012 ainda utilizam as ferramentas como nas versões 2007 e 2008, ou seja, de forma autônoma.
Assim, o Service Manager recebe incidentes manualmente quando algum tipo de alerta é gerado no Operations Manager. Os relatórios e dados de inventário (CI) precisam ser consultados no Configuration Manager.
Utilizando os conectores do Service Manager podemos integrar todos os produtos como mostra o diagrama abaixo:
Como pode ser visto no diagrama, é o Service Manager que faz o papel de integrador entre os diferentes produtos System Center. O Orchestrator também atua, porem por meio dos Runbooks que podem interagir com o desenho de atividades, mas já comentei em outro post http://www.marcelosincic.com.br/blog/post/Orchestrator-Integration-Packs-para-System-Center-2012.aspx
Criação de Conectores no Operations Manager
Os conectores precisam ser criados dos dois lados, inicialmente pelo Operations Manager em Administration –> Internal Connectors, como pode ser visto abaixo, onde os diversos conectores já estão criados, sendo que apenas um é criado no assistente e os outros criados automaticamente conforme o número de Management Packs:
O primeiro passo é definir o nome do conector e quais os grupos de computadores do SCOM serão integrados:
No passo seguinte definimos quais são os Management Packs que serão integrados com o Service Manager, sendo que no momento de criação do conector pode-se escolher todos e fazer a manutenção após o conector já criado e testado, como será mostrado no próximo tópico:
O ultimo passo ao criar o conector é definir critérios de filtro. Este item é mais importante que os dois acima (Computer Groups e Management Packs), pois permite definir de forma granular quais alertas irão gerar os incidentes no Service Manager. Por exemplo, apenas os erros são importantes em incidentes, assim como a prioridade e o estado do alerta no SCOM.
Também é importante notar que os incidentes no Service Manager podem ser abertos pelos estados resultantes dos Healthy Monitors do Operations Manager, o que amplia em muito o número de incidentes que serão gerados:
Edição do Conector no Service Manager
Criado o conector no console do Operations Manager é possivel ver o mesmo conector replicado no Service Manager em Administration –> Conectors.
Se for necessário alterar como os incidentes são abertos, registrados e auto-atualizados é necessário alterar o conector pelo console do Service Manager, como mostrado na tela abaixo:
Na tela de configuração do template definimos os critérios dos incidentes que serão sincronizados, lembrando que caso não seja configurado corretamente o conector no Service Manager, ao fechar um incidente este não será encerrado no Operations Manager e vice-versa.
No exemplo abaixo, selecionei todos os computadores pelo grupo, mas poderia ser feito um filtro pelo Management Pack, nivel de severidade, prioridade ou mesmo um campo personalizado:
Criando Conectores de Itens (CI) no Service Manager
Note que a importação dos Management Packs tem a ver com os itens de configuração e não com os alertas definidos anteriormente.
Neste caso, o que será importado são itens, computadores e dados recolhidos dos agentes pelo Operations Manager, para formar a biblioteca de dados de configuração junto com o próprio System Center Configuration Manager.
Sendo assim, criar o conector de itens de configuração não é tão importante quanto criar o conector para os alertas, principalmente em ambientes onde o System Center Configuration Manager também foi implementado e sincronizado.
De qualquer forma, recomendo que se crie o conector de CI para que máquinas monitoradas pelo Operations Manager e que não contenham agente do Configuration Manager estejam contempladas no banco de dados do Service Manager ao abrir um chamado. Alem disso, o conector permitirá ver aplicações como sites do IIS e outros serviços do Windows pelo Service Manager.
Para criar e administrar este conector, basta definir quais os Management Packs que irão enviar dados e o agendamento para esta tarefa:
Outros Conectores
Mais detalhes de cada um dos conectores pode ser vista no TechNet em http://technet.microsoft.com/en-us/library/hh524326.aspx
Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/
Atualizando System Center 2012 RTM/SP1 RC para SP1 RTM-Parte 1 (SCCM e SCOM, Orchestrator)
Com o lançamento da versão final do Service Pack 1 do System Center 2012 foi necessário fazer upgrade das versões dos produtos sem o Service Pack ou com o Service Pack 1 na versão Release Candidate (RC). Não irei abordar o Beta pois ele já estava defasado em relação aos testes em geral.
No meu caso, fiz as atualizações a partir das duas versões de todos os produtos e este será um resumo em duas partes, sendo este primeiro com o System Center Configuration Manager 2012, System Center Operations Manager 2012 e Orchestrator.
Segue uma tabela básica com o resultado e depois passo ao detalhamento:
| |
A partir do RTM |
A partir do SP1 RC |
Agentes |
| Configuration Manager |
Upgrade após desinstalar o WAIK e instalar o Windows ADK |
Upgrade sem intervenções |
Não exige o upgrade, mas relaciona os agentes no relatório das versões |
| Operations Manager |
Upgrade sem intervenções |
Upgrade sem intervenções |
Não exige o upgrade, apenas apresenta a versão correspondente em “Agent Managed” |
| Orchestrator |
Não permite upgrade, mas permite selecionar o mesmo database. |
Não permite upgrade, mas permite selecionar o mesmo database. |
Integration Packs com as novas funcionalidades do SP1 precisam ser instalados |
System Center Configuration Manager (SCCM)
Tanto a migração do RTM como do SP1 RC foram transparentes e simples, porem é importante lembrar que o SCCM 2012 ainda utilizava o Windows AIK. O SCCM 2012 SP1 já foi atualizado para utilizar o Windows ADK que era beta na ocasião do lançamento do SCCM 2012. Porem, o processo é simplesmente desinstalar o WAIK e instalar o Windows ADK.
Em ambientes com hierarquia “Parent-Child” (onde são independentes mas fazem troca de dados) pode-se iniciar a atualização em qualquer um dos sites com o risco de ser recusado o upload de dados no Parent em versões diferentes. Por outro lado, em hierarquias “Primary-Secundary” (apenas o primário tem banco de dados) o upgrade deve ser feito de cima para baixo, ou seja, primeiro atualizamos o primário para o banco de dados ser atualizado e depois os secundários, que não irão funcionar corretamente até serem atualizados. Lembrando que neste caso a atualização pode ser feita pelo próprio console do SCCM.
Importante: Um erro no timestamp do certificado usado no agente do SCCM 2012 SP1 gera um erro “Couldn't verify 'C:\WINDOWS\ccmsetup\MicrosoftPolicyPlatformSetup.msi' authenticode signature. Return code 0x800b0101”. Baixe o hotfix em http://support.microsoft.com/kb/2801987
Ao abrir o setup já é possivel ver a opção de Upgrade disponivel, sem qualquer intervenção, como mostram os dois prints a seguir.
Os sites e configurações continuam ativas sem problemas, incluindo os agentes:
System Center Operations Manager (SCOM)
Foi a migração mais simples de todas, não foi necessário qualquer atualização de componentes, nem a partir do RTM.
Em ambientes com instalação em multiplos servidores, a ordem básica se mantem como a do upgrade de versões anteriores. Iniciamos a migração pelo servidor que contem o Operational Database antes dos Management Servers e Gateway Servers.
O wizard de instalação detectou com facilidade os componentes instalados e listou o que estava sendo atualizado:
Ao realizar a atualização foram alteradas as estruturas do banco de dados, motivo pelo qual o wizard recomenda o backup das bases antes do processo de upgrade.
Ao final, o console abriu com todos os agentes saudáveis e o SCOM atualizado. Lembrando que o agente mostra a versão anterior mas não exige o upgrade:
System Center Orchestrator (SCO)
Na ordem em que eu inicie as migrações, o Orchestrator foi o primeiro a não permitir o upgrade direto das versões anteriores. Tanto a partir do RTM quanto do SP1 RC a mensagem abaixo foi o resultado:
Neste caso o processo consiste em desinstalar o Orchestrator e reinstalar o produto, porem utilizando a opção “Retain database” na seleção do banco de dados a ser utilizado.
Após isso, todos os Runbooks estavam disponiveis e funcionaram corretamente, assim como os Integration Packs que continuaram disponiveis no Runbook Designer.
Porem, é importante que para tirar proveito das novas funcionalidades do SP1 é necessário baixar os Integration Packs novos (http://www.marcelosincic.com.br/blog/post/Novos-Integration-Packs-para-Orchestrator-2012-SP1-e-Toolkit.aspx) e fazer o deploy a partir do Orchestrator Deployment Manager, que passa a mostrar a versão 7 (RTM) e as versões 7.1 (SP1):
É importante que após a instalação dos novos Integration Packs os Runbooks continuaram funcionando normalmente, como o exemplo abaixo:
