Como conhecido, o System Center saiu em sua nova versão, agora seguindo o mesmo conceito de Branch (Current Branch) do Windows. De agora em diante veremos as versões seguindo o numero que indica a edição:

A versão 2019 da suite não teve alterações em layouts ou funcionalidades principais, mas acrescenta diversos recursos novos.

Atualmente temos disponivel a nova versão 1801, que se aproxima muito do que será a versão 2019 que terá como build 1901 com data de lançamento previsto em Março.

Estes recursos podem ser visualizados no link: https://thesystemcenterblog.com/2018/09/25/whats-new-in-system-center-2019/

Upgrade do System Center Configuration Manager

O SCCM já desde a versão 2016 tem o upgrade como uma funcionalidade nativa e automática. Sempre foi muito estável e fácil de ser realizada, ficando disponivel em Administration –> Updates and Services:

Após iniciado, pode-se ir pelo menu da barra superior e acompanhar toda a instalação passo a passo:

Lembrando que não é possivel interagir com o upgrade após iniciado, mas em caso de se escolher deixar as features desabilitadas no menu mostrado na primeira imagem, escolha a opção Features para incluir uma das novas.

Pessoalmente sempre prefiro fazer a instalação dos upgrades sem selecionar features e depois incluir as que desejo, assim posso estudar o impacto e real necessidade de mais componentes sendo executados no servidor.

Upgrade do System Center Service Manager

Tambem simples de ser realizado, insira a midia do SCSM e ele já entrará no modo de upgrade onde você irá selecionar qual dos servidores locais está sendo atualizado. Lembrando que é importante saber a estrutura para escolher a função correta do servidor que está sendo atualizado, no meu caso o Management Server:

A atualização é bem tranquila, e ao final já está executando. O novo portal de auto-serviço agora oferece a experiencia HTML5 sem necessidade de componentes adicionais:

Upgrade do System Center Operations Manager

A Microsoft realmente aprendeu a fazer upgrades de versão com o System Center transparentes, rapidas e eficientes. O mesmo vale para o SCOM.

Similar ao SCSM, basta incluir a midia e executar o modo de upgrade:

A mensagem de Warning na tela acima existe desde as versões anteriores. Como os instaladores do System Center não pedem chave, em alguns é necessário fazer a inserção da chave posteriormente.

Para inserir a chave, execute o PowerShell do SCOM e utilize o comando, lembrando que agora a chave de instalação do System Center é a mesma para toda a suite desde a versão 2012:

Set-SCOMLicense -ProductId 'xxxxx’

Upgrade do System Center Orchestrator e Virtual Machine Manager

Para fazer o upgrade do SCO tive que primeiro desinstalar o servidor. O motivo no meu caso foi a instalação de um update no meio do ano que era beta e com isso o upgrade automático não é possivel.

Nesses casos, faça a desinstalação do servidor com a opção Retain Database ativada, mesmo sendo a do SCVMM a do Orchestrator é similar:

Depois de desinstalar a versão anterior, ou mesmo para um refresh, refaça a instalação com a opção de utilizar um banco de dados já existente:

Com isso a instalação tanto do System Center Orchestrator quanto do Virtual Machine Manager finaliza com os mesmos dados existentes.

Em muitos casos, o Orchestrator e o Virtual Machine Manager para no meio da instalação com um erro genérico de banco de dados, com a mensagem: “DBSetup.exe fails with unknown error 0x800A0E7A”

Se isso acontecer no seu caso, baixe e instale o SQL Server 2012 Native Client – QFE disponivel em https://www.microsoft.com/en-us/download/details.aspx?id=50402

Upgrade do Windows Server 2019 com Serviços de System Center

Em alguns dos servidores, antes de fazer o upgrade do Windows realizei o upgrade do System Center.

Isso porque o System Center 2019 é compativel com o Windows Server 2012 R2, mas o contrário não. Isso quer dizer que é mais confiavel primeiro o upgrade dos serviços e depois do Sistema Operacional que tambem é compativel.

Conclusão

O upgrade dos servidores System Center são estáveis, mas lembre-se de sempre ter um backup das bases de dados se ocorrer um problema nessas fases.

Tambem é importante lembrar das regras de ordem, em geral os Management Servers antes das outras funções.

Já a algum tempo que o OMS é uma ferramenta que sempre abordo em clientes e eventos.

É um produto muito bom, com analises ricas e que evoluiu bastante neste ultimo ano, chegando a ser o produto que muitos acham que substituirá no futuro o System Center.

O que mudou na interface?

A interface anterior era mais simples e em um portal a parte como está no post abaixo:

http://www.marcelosincic.com.br/post/Adquirindo-e-Licenciamento-o-Azure-OMS-Operation-Management-Suite.aspx

Agora a interface é integrada no painel do Azure, permite criar novos dashboards facilmente. Alem disso é possivel acessar individualmente cada um dos monitores.

Com essa integração na interface do Azure ficou muito mais fácil e funcional.

E como ficou o licenciamento?

No post onde já havia abordado o OMS falamos sobre a aquisição que era complexa pois cada modulo fazia parte de um bundle, e cada bundle se soluções era pago separado. Havia a opção de comprar por nó ou por upload de log, mas havia limitação de soluções e modulos no modelo de pagamento por upload.

Agora ficou muito mais fácil, só existe um modo de cobrança que é por upload de dados.

Ou seja, agora você pode pagar pelo tamanho dos logs que envia, o que é bem mais prático e simples!

https://azure.microsoft.com/pt-br/blog/introducing-a-new-way-to-purchase-azure-monitoring-services/

Se não utiliza o Log Insights por não entender como pagar, agora ficou simples e bem mais barato!

Já falamos anteriormente sobre o Microsoft ATA (Advanced Threat Analytics) em http://www.marcelosincic.com.br/post/Microsoft-Advanced-Thread-Analytics-(ATA).aspx

Agora houve uma grande atualização com a versão 9 que tornou o ATA mais leve em demanda de recursos e visualização dos reports.

Porem, durante a migração é possivel que ocorram perdas de conexão ao MongoDB e ser necessário fazer o backup e restore.

O mesmo processo talvez seja necessário quando se troca de servidor ATA.

Importante: Os dados do Security Log do Windows é enviado ao Machine Learning para gerar os incidentes e alertas, mas ficam hospedados localmente. Portanto se perder o servidor não terá mais os reports e incidentes já registrados.

Realizando o Backup do ATA

Para fazer o backup da configuração do ATA é utilizado a cópia do arquivo SystemProfile_yyyymmddhhmm.json que fica na pasta de instalação do ATA em um subdiretório Backup junto com as ultimas 300 cópias dos dados.

Esse arquivo SystemProfile é a base de dados do MongoDB em formato JSON, eliminando a necessidade de fazer backup a partir do Atlas ou outra ferramenta especifica para administração do MongoDB. Isso é muito bom, pois não é comum conhecermos adminsitração do MongoDB.

Para funcionar deve-se ter a cópia do certificado usado para criptografia do arquivo JSON, que é gerado durante a instalação (Self-signed).

A cópia do certificado só precisa ser feita uma vez, abra o console do MMC com o snap-in Certificados e encontre o certificado de nome Central do ATA na área de certificados Pessoas em Local Machine.

Com estes passos temos o backup das configurações do servidor que são o JSON e o certificado. Mas e os dados do ATA?

Para fazer backup do ATA é necessário como já falado conhecer as ferramentas do MongoDB e talvez você deva pensar se precisará deles uma vez já resolvidos.

Se a sua necessidade é manter os alertas e incidentes, siga a documento em https://docs.mongodb.com/manual/core/backups/ de como fazer backups da base.

Realizando o Restore do ATA

A parte de restore do ATA em um novo servidor ou configuração de uma nova versão é um pouco mais complicado que o backup que é bem simples.

Primeiro é necessário importar o certificado exportado no passo anterior na mesma árvore da qual fez no passo anterior.

Em seguida é necessário reinstalar normalmente o novo servidor ATA com o mesmo nome e IP anterior e no momento que ele pedir o certificado desativar a opção Create Self-signed” para escolher o certificado original.

Em sequencia precisamos parar o serviço Centro ATA para podermos abrir o MongoDB e importar o arquivo JSON com os seguintes comandos:

• mongo.exe ATA
• db.SystemProfile.remove({})
• mongoimport.exe --db ATA --collection SystemProfile --file "<Arquivo JSON> --upsert

Observação: Primeiro comando abre a instancia, o segundo remove as configurações vazias e o terceiro importa a nova configuração.

Não é necessário recriar os Gateways pois eles são mapeados automaticamente quando se restaura as configurações.

Caso você tenha feito backup da base de dados do MongoDB siga o procedimento de restore da base antes de reiniciar o serviço do ATA.

Referencia: https://docs.microsoft.com/pt-br/advanced-threat-analytics/disaster-recovery