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/
System Center 2012 SP1 Configuration Analyzer
O SC2012 CA é uma ferramenta baseada no MBCA (Microsoft Baseline Configuration Analyzer) que tem a função de verificar se um ou mais servidores estão configurados de forma segura e com os updates essenciais.
Com o SC2012 CA é possivel estender as funções do MBCA para aplicar também recomendações nas ferramentas da suite System Center 2012.
O primeiro passo é baixar o MBCA 2.0 em http://www.microsoft.com/en-us/download/details.aspx?id=16475 e o SCCA em http://www.microsoft.com/en-us/download/details.aspx?id=36796
Executando o System Center 2012 Configuration Analyzer
Note que ao abrir o menu não terá uma opção para o SCCA, uma vez que ele é um plugin do MBCA, como pode ser visto abaixo:
O passo seguinte é selecionar os computadores que serão validados. Porem, para validar alguns servidores remotos pode ser necessário fazer o registro de segurança com Setspn. Se você não sabe como utilizar, pode usar as instruções do próprio SCCA, como mostrado nos tópicos a frente:
Os resultados são mostrados em duas abas, sendo possivel ver um resumo ou detalhamento dos dados analisados. No exemplo abaixo executei em um SCSM 2012 SP1 e o resultado inicial é que não há pendencias e permitindo exportar o relatório que pode ser revisado posteriormente depois de salvo com a opção “Open Report” no primeiro pront.
Utilizando a opção Collected Data é possivel ver os dados utilizados pelo SCCA para validar o SCSM:
Servidores Remotos
Instalar o MBCA e o SCCA em um único servidor é uitl para evitar a instalação em uma farm de servidores ou mesmo para maquinas com acesso limitado. Porem, em alguns casos nao é possivel executar o SCCA remotamente tendo como resultado a mensagem abaixo:
A função Credssp permite que o servidor onde o SCCA está instalado tenha acesso ao servidor que está sendo analisado, sendo simples de ser executado.
Atualizando System Center 2012 RTM/SP1 RC para SP1 RTM-Parte 2 (SCVMM, SCDPM, SCSM e AppController)
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 o primeiro com o System Center Configuration Manager 2012, System Center Operations Manager 2012 e Orchestrator (http://www.marcelosincic.com.br/blog/post/Atualizando-System-Center-2012-RTMSP1-RC-para-SP1-RTM-Parte-1-(SCCM-e-SCOM-Orchestrator).aspx).
Este segundo post abordarei o System Center Virtual Machine Manager, System Center Data Protection Manager, System Center Service Manager e System Center AppController.
| | A partir do RTM | A partir do SP1 RC | Agentes |
| Data Protection Manager | Upgrade sem intervenções | Upgrade sem intervenções | Exige upgrade, desabilita os jobs até que seja atualizado |
| Virtual Machine Manager | Não permite upgrade, mas permite selecionar o mesmo database | Não permite upgrade, mas permite selecionar o mesmo database | Atualiza os agentes automaticamente |
| Service Manager | Permite o upgrade, desde que esteja com o Cumulative Update 2 instalado | Não permite upgrade, mas permite selecionar o mesmo database | -- |
| AppController | Não permite upgrade, mas permite selecionar o mesmo database | Não permite upgrade, mas permite selecionar o mesmo database | Recomendado que o VMM 2012 seja atualizado para o SP1 |
Data Protection Manager (DPM)
Dos 4 produtos que migrei nesta onda o DPM é o unico que permite a migração de forma automática. Basta colocar o instalador e o upgrade ocorrerá sem problemas:
Porem, é importante que após a migração do servidor seja realizado o upgrade dos agentes, o que pode exigir que o servidor seja reiniciado:
Importante: O Windows Server 2012 possui um hotfix para evitar que o CSV fique offline durante operações de backup disponivel em http://support.microsoft.com/kb/2799728
Virtual Machine Manager (VMM)
A migração do VMM não é permitida, exigindo que seja desinstalada a versão anterior:
Porem, a solução de manter o mesmo banco de dados (Retain Database) resolve o problema permitindo que a estrutura anteriormente seja configurada seja aproveitada. Para isso escolha a opção apropriada quando for detectado pelo instalador que já existe um database no SQL Server:
Na tela posterior será possivel confirmar o banco de dados e permitir o upgrade:
Por fim, indique que deseja utilizar o mesmo Library existente:
Assim o ambiente fica operacional e no console será mostrado um warning nos hosts indicando que existe uma nova versão de agente, porem não impossibilita o gerenciamento.
Service Manager (SCSM)
O Service Manager pode ser atualizado desde que esteja o Cumulative Update 2 na versão RTM. Se for a versão SP1 Beta/RC o upgrade não é possivel.
Ao iniciar o instalador será possivel escolher a opção de upgrade que ocorre sem muitos problemas, como acontece com o DPM no tópico acima.
Quando temos um servidor com o SP1 beta ou RC a mensagem será de erro como abaixo:
AppController
O AppController não permite upgrade, mas permite a reutilização da base de dados na reinstalação do produto.
O processo é desinstalar a versão existente e reinstalar a nova. Note que não é possivel mudar o banco, as informações aparecem desabilitadas pois o instalador detecta que já havia a configuração anteriormente:
