Com o lançamento oficial do System Center 2019 semana passada agora já podemos testar a migração da versão final.

https://cloudblogs.microsoft.com/windowsserver/2019/03/07/coming-soon-microsoft-system-center-2019?wt.mc_id=4029139

Nova Politica de Versões

Na nova politica de versões do System Center, não haverá os canais Semi-Anuais como Windows.

Ou seja, você terá a versão 2019 por aproximadamente 3 anos com os updates que em geral ocorrem 3 vezes por ano.

Isso significa que diferente das primeiras versões que foram o 1801 e 1807, daqui em diante não teremos mais esse mesmo tipo de nomenclatura retornando ao antigo modelo de versões com updates (2019 UR 99).

Importante: System Center Configuration Manager continua com o canal Semi-Anual

https://docs.microsoft.com/en-us/system-center/ltsc-and-sac-overview?wt.mc_id=4029139

Executando o Upgrade

No mesmo documento acima, vemos o suporte para upgrade in-place que é garantido até as ultimas 2 versões.

Isso significa que os usuários das versões 2012 R2 precisarão primeiro fazer o upgrade para a 1801 e depois para o SC 2019.

Importante: System Center Configuration Manager terá as regras de update diferentes, dependendo do canal escolhido

Assim como o upgrade da versão 2016 para a 1801 foi tranquila e já demonstrei aqui http://www.marcelosincic.com.br/post/System-Center-2019-e-Windows-Server-2019-Upgrade-in-place.aspx, a migração do 2019 tambem foi bem satisfatória.

Todos eles precisamos apenas confirmar a instalação, apenas com excessão do SCOM e VMM que é necessário o upgrade de agentes.

O DPM não executei o upgrade pois atualmente utilizo o Microsoft Azure Backup que é um subset especializado para backup no Azure.

System Center Operations Manager (SCOM)

No caso do SCOM uma mudança é agora poder ativar pela interface no “About”, antes era necessário fazer pelo PowerShell com o comando Set-SCOMLicense.

Lembrando que no caso do SCOM é necessário autorizar o upgrade do agente para todos os servidores logo após a instalação. Caso não o faça continuará havendo comunicação, mas ele irá criar alertas constantes de aviso e novos recursos podem ocasionar falha nos agentes.

System Center Service Manager (SCSM) e System Center Orchestrator (SCO)

Literalmente nada precisou ser feito ou alterado e o mesmo aconteceu com o Orchestrator.

System Center Virtual Machine Manager (SCVMM ou VMM)

O VMM já exigiu um pouco mais de trabalho, pois é necessário rever as contas no “Run-AS” que agora limita contas locais e reinstalar os agentes.

No meu caso, fiz o exercicio de desinstalar para validar se apenas utilizando o banco de dados retornaria e funcionou!

A Microsoft anunciou esta semana a retirada do MVMC como produto já no final deste ano.

https://blogs.technet.microsoft.com/scvmm/2016/06/04/important-update-regarding-microsoft-virtual-machine-converter-mvmc/

Para quem não conhece o MVMC ou não lembra sua função, ele é um plugin para converter maquinas fisicas (P2V) ou virtuais de outras plataformas (V2V) para VMs no Hyper-V.

O que usar no lugar do MVMC?

A sugestão apresentada é utilizar o Azure Recovery Site, mas ele na verdade é um serviço e não seria útil quando o desejo é subir VMs em ambiente on-premisse.

Porem, no caso do cliente que quer transformar o ambiente fisico (P2V) para nuvem (IaaS) o Azure Recovery Site é a melhor opção.

E para quem precisa fazer V2V hospedadas no VMWare para o Hyper-V pode utilizar o próprio VMM (System Center Virtual Machine Manager) que processa a conversão nativamente.

Por fim, para os casos de conversão de maquinas fisicas para virtuais (P2V) pode-se usar o Disk2VHD como já comentado em outras ocasiões e é um produto muito conhecido para gerar VHDs a partir de discos fisicos, que abordei em 2009: http://www.marcelosincic.com.br/post/Ferramenta-para-converter-HD-fisico-(em-uso)-para-VHD.aspx

Link do Disk2VHD: https://technet.microsoft.com/en-us/sysinternals/ee656415.aspx

Uma das novidades do System Center Technical Preview 2 é no Virtual Machine Manager que agora integra as VMs que você tem no Azure, o que nos deixaria orfão com o fim do AppController.

Para isso basta ir no console em Azure Subscriptions e inserir as assinaturas.

Para encontrar as assinaturas no painel web do Azure e copiar o ID da assinatura e baixar o certificado de gerenciamento que fica na aba de settings, como a imagem abaixo:

Multiplas assinaturas podem ser adicionadas no VMM:

Automaticamente o VMM irá popular a lista das VMs de cada assinatura, integrando a visualização:

A partir da integração é possivel gerar relatórios, ver as configurações, iniciar e parar VMs e automatizar com Orchestrator.

Ainda existem limitações, por exemplo não é possivel criar VMs no console do VMM o que espero ser possivel quando houver o lançamento do System Center 2016.