Azure ARC–Integração de Updates, Change Monitoring e Inventario
Ao utilizar o ARC como já abordamos antes (http://www.marcelosincic.com.br/post/Azure-Arc-Gerenciamento-integrado-Multi-cloud.aspx), é uma duvida comum que recebo de pessoas da comunidade como habilitar as funções de Insigths que aparecem no painel do ARC.
Criando ou Habilitando uma conta de Automação existente
Para isso, o primeiro passo é ter uma conta de automação habilitada em uma região que faça o par com a região onde está o Log Analytics integrado ao ARC.
Para saber as regiões que foram estes pares, utilize o link https://docs.microsoft.com/pt-br/azure/automation/how-to/region-mappings como por exemplo East US1 faz par com East US2 e vice-versa. Ou seja o Log Analytics precisa estar em uma das regiões e a conta de automação na outra.

Ao criar a conta de automação e o Log Analytics, vá na conta de automação e configure a integração entre elas.

No próprio painel da conta de automação já é possivel configurar os recursos de Update, Change Management e Inventários e depois no painel do ARC são visualizados já pronto.
Habilitando os recursos
Cada módulo pode ficar integrado a um Automation ou Log Analytics diferente, o que não é o meu caso.

Uma vez integrado no proprio painel da conta de automação já é possivel ver os recursos e habilitar os computadores, veja que os que possuem o agente do ARC já irão aparecer no inventário.

Para o caso de Atualizações (Updates) você precisará escolher os que desejará automatizar.

Lembrando que uma vez configurado o controle de Updates é necessário criar as regras de agendamento para a instalação desses updates.

Por fim, habilitamos o painel de Change Management indicando os computadores que queremos coletar.

Na minha opinião este é o melhor dos recursos, já que em segurança e sustentação saber as alterações realizadas em cada servidor é um item essencial.

System Center 2019 e Windows Server 2019 – Upgrade in place
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:
_thumb.png)
Após iniciado, pode-se ir pelo menu da barra superior e acompanhar toda a instalação passo a passo:
_thumb.png)
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:
_thumb.png)
_thumb.png)
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:
_thumb.png)
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:
_thumb.png)
_thumb.png)
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:
_thumb.png)
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:
_thumb.png)
_thumb.png)
_thumb.png)
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.
_thumb.png)
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.
EOL do Windows e SQL 2008–Opções de Extensão
Como já é conhecido, o ciclo de vida de produtos da Microsoft para 2019 incluem o Windows e SQL 2008 RTM e R2.


Fonte: https://support.microsoft.com/pt-br/lifecycle/search
Porque isso é importante?
Esse é um problema típico nas grandes empresas, controlar o ciclo de vida do suporte dos produtos que estão implementados.
Esse assunto não é de menos importancia, pois ter o suporte finalizado implica:
- Novas ameaças de segurança, mesmo as que envolvem brechas de software, não são mais disponibilizadas para os sistemas expirados
- Novos recursos em novos produtos não tem garantia de funcionamento nos produtos expirados
O primeiro item é importantissimo. Imagine que sua empresa está vulnerável a um ataque como muitos que vimos, pois apenas UM SERVIDOR em seu ambiente é expirado!!!
O que fazer se tenho produtos que expiram?
Obviamente que a melhor opção é migrar (“TO-BE”), mas sabemos que nem sempre é possivel. O que pode ajudar é usar produtos como o Service Map do Log Insights (http://www.marcelosincic.com.br/post/Azure-Log-Insigths-Service-Map.aspx).
Mas para quem não pode fazer o upgrade, uma das opções é comprar o suporte via Premier para mais 3 anos, que não é barato mas é possivel negociar através do seu time de contas Microsoft.
O custo para extender o suporte POR ANO é equivalente a 75% do software full na versão mais atual.
Porem, a Microsoft disponibilizou uma opção bem interessante que é migrar para Azure “AS-IS”!!!!
Isso mesmo, quem migrar para Azure o Windows 2008 e SQL Server 2008 não precisará se preocupar pois terão gratuitamente o suporte por 3 anos adicionais.
https://azure.microsoft.com/pt-br/blog/announcing-new-options-for-sql-server-2008-and-windows-server-2008-end-of-support/
Não precisamos nem discutir que é uma estratégia para aumentar o uso de Azure, mas muito boa financeiramente para qualquer workload que possua.

Vamos Falar do Projeto Microsoft Honolulu?
O projeto Honolulu foi muito comentado a algum tempo atrás e linkado a uma nova interface gráfica do Windows ou funcionalidade.
Agora em 01/Dezembro saiu uma nova versão Preview e documentação do Honolulu e já está bem maduro e com arquitetura final definida.
O que é o projeto Honolulu?
É uma nova interface de GERENCIAMENTO para Windows Server.
Não se trata de uma substituição do Server Manager do Windows 2012/2016 e sim uma interface baseada em novos protocolos para acesso e facilidade de uso, alem da capilaridade no gerenciamento.
Quais as vantagens do Honolulu sobre o Server Manager?
O Server Manager é uma ferramenta muito boa, mas é baseada em protocolos locais (RPC, WinRM e outros) alem de ser baseada em uma GUI que precisa ser instalada.
O Honolulu é 100% baseado em web para acesso aos dados e utiliza WinRM, WMI e PowerShell para administração dos servidores.
Com o Honolulu é possivel fazer coisas que o Server Manager não faz, como executar scripts, Windows Update, administrar e monitorar VMs, etc.
Por outro lado, o Honolulu não administra tantos serviços como o Server Manager, como por exemplo File Server, DHCP, DNS, etc que continuam a ser administrados pelas ferramentas MMC.
Como instalar o Honolulu?
A instalação é muito simples, mas é preciso definir a arquitetura.
Basicamente podemos utilizar instalado em um unico servidor e vincular os outros na administração como nós, ou então instalar um servidor como Gateway para acessar os outros e facilitar o trafego quando temos muitos servidores em um farm:

Em geral para estas ferramentas o ideal é criar um servidor com pouca memoria e poder de processamento (na figura o segundo modelo) para não onerar servidores com outras funções, já que ele cria um serviço para o Honolulu:

Para baixar o Honolulu, como ainda é um Preview é necessário usar a página de avaliaçoes de produtos Windows Server em https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-honolulu
Como administrar um servidor com o Honolulu?
Vamos as telas básicas. Primeiro inserimos um servidor na lista e a partir dai é possivel por qualquer navegador ver os gráficos de uso, configurar itens, fazer conexão remota, executar comandos PowerShell, etc.
Primeiro, vamos adicionar novos servidores, clusters ou até Windows 10 Client:

Na sequencia basta indicar o usuário e escolher o servidor/cluster que deseja visualizar:

O nivel de detalhes aborda desde os itens de HW até gráficos detalhados para cada um dos itens vituais do servidor/cliente que está sendo monitorado:

Mesmo alguns itens como discos fisicos, volumes e Storage Space já podem ser administrados no Honolulu:

Uma feature interessante é poder administrar o Windows Update remotamente:

O gerenciamento de VMs em um Hyper-V tambem é um dos destaques pelo nivel de detalhamento e a interface intuitiva:


Finalizando, segue o link da documentação técnica do Honolulu: https://docs.microsoft.com/en-us/windows-server/manage/honolulu/honolulu
Software Asset Management (SAM)–Convertendo Licenciamento para Azure
Este tópico é relevante no momento em que estamos de migração para Cloud Publica em muitas empresas.
Dando continuidade a série sobre SAM, vamos pular alguns outros tópicos e dar atenção a Azure. Para ver a lista de assuntos que já abordamos acesse http://www.marcelosincic.com.br/post/Software-Asset-Management-(SAM)-com-System-Center-Configuration-Manager.aspx
Atualização: Conheça o Reserved Instance no artigo http://www.marcelosincic.com.br/post/Reducao-de-Custos-com-Azure-Reserved-Instance.aspx
1 – Utilizando o Licenciamento Normal para VMs Windows (SPLA)
Ao criar maquinas virtuais no Azure já é possivel definir que o sistema operacional é Windows e pagar o licenciamento embutido como parte do serviço.
Esse modelo de licenciamento é chamado de SPLA e permite a um provedor (não existe apenas no Azure) licenciar VMs como serviços faturado ao invés do cliente comprar a licença perpétua como acontece em ambientes on-premisse.
O custo desse licenciamento é medido por comparar valores de VMs iguais com Windows e Linux em https://azure.microsoft.com/pt-br/pricing/details/virtual-machines/linux/ e https://azure.microsoft.com/pt-br/pricing/details/virtual-machines/windows/
No dia que montei esse post o valor hora de uma VM D2 v2 Linux é de U$ 0,159 e a mesma VM com Windows U$ 0,251. Ou seja uma diferença de 43% no preço da VM.
Por essa diferença de preço que temos opções de usar outras formas de licenciamento que falaremos a seguir.
2 – Utilizando AHUB (Azure Hybrid Use Benefit)
O AHUB nada mais é do que usar a sua licença já comprada em contrato com Software Assurance (SA) no Azure e assim não pagar o licenciamento SPLA.
Note porem que sua licença deve ter SA contratado, ou seja o direito de atualização e virtualização. Se não conhece o SA veja o post http://marcelosincic.com.br/post/Software-Asset-Management-(SAM)-com-System-Center-Configuration-Manager-Windows-Desktop.aspx onde temos um tópico sobre isso.
No caso de usar o AHUB a diferença de preço calculada no item anterior não existe, já que o licenciamento passa a ser feito em contratação em Enterprise Agreement, MPSA ou mesmo OPEN. O tipo de contrato depende do valor e é adquirido junto a um parceiro de licenciamento Microsoft (LSP).

A Microsoft já disponibiliza os templates para VMs AHUB mas tambem é possivel usar PowerShell com o parametro –licencetype. No caso se usar o portal, basta criar a VM informando isso:

Porém é importante ressaltar que o AHUB é uma maquina Windows criada com a camada de preço do Linux e não é possivel fazer a alteração pelo portal. Ou seja, será necessário recriar a VM caso ela já exista no modelo normal.
Claro que existem formas mais fáceis:
- Deleta a VM, mas não delete o disco
- Crie uma nova VM como AHUB
- Anexe o disco da VM que foi deletada
3 – Utilizando CPP (Compute Pre-Purchase)
O CPP é um velho conhecido de quem usa AWS, com o nome de RI (Reserved Instance), mas com uma diferença. Veja o link a seguir, mas ele não tem muitos detalhes: https://azure.microsoft.com/pt-br/overview/azure-for-microsoft-software/faq/
Enquanto no AWS o cliente compra uma VM de determinado tipo/camada, no CPP do Azure o cliente compra horas de computação de determinado tipo/camada de VM, seguindo algumas regras:
- Equivalem a compra de 744 horas de um deterninado tipo de VM
- São compradas por 12 meses independente do aniversário do contrato (não tem pró-rata)
- Não são vinculadas a uma VM especifica, funciona como um abatimento nas horas totais
- Não podem ser utilizadas ou realocadas para outros tipos de VM como se fosse proporcional
- É paga upfront, ou seja o valor de 12 meses
A redução de custo é significativa, mas o valor depende do tipo de contrato que o cliente possui e o nivel de desconto, em alguns casos chega a 60% para clientes EA.
Para entender o cáculo, vamos usar uma tabela simples de custo HIPOTÉTICO:
VM | Quantidade | Horas Total | Valor Normal | Comprado em CPP | Pago em Commitment | Economia |
D2 v2 | 5 | 3200 | 3200 horas a U$ 0,251 U$ 803,20 | 3 VMs equivalente a 2.232 horas a U$0,16 U$ 357,12 | Saldo de 968 horas U$ 242,96 | U$ 203,12 |
Mais uma vez é importante ressaltar que essas VMs não podem ser atribuidas a outro tipo, o CPP cobre por 12 meses 744 horas mensais de um deterninado tipo de VM.
Porem, alguns clientes utilizam o CPP para upgrade uma vez que a redução de custo permite com o mesmo valor já provisionado para Azure subir de 2 a 3 camadas as VMs já existentes!
4 – Utilizando CPP + AHUB
É possivel combinar o CPP com AHUB? SIM!!!
Levando em conta que o cálculo acima do CPP foi hipotético, usamos o valor referencia de U$ 0,251 para VMs Windows no CPP com valor de U$ 0,16, ou seja uma VM com o licenciamento Windows SPLA.
Se juntar o desconto que o AHUB proporcional, você poderá comprar VMs Linux e usar o licenciamento que já possui em contrato, como exemplo o valor da mesma VM D2 v2 de U$ 0,159 Linux cairia para U$ 0,12 com Windows utilizando o licenciamento existente.
CONCLUSÃO
Com o CPP você pode economizar de 25 a 60% sem ter que fazer nenhum esforço, e com o AHUB você pode criar VMs muito mais em conta utilizando o contrato existente com Windows.
Claro que o CPP é muito mais atrativo, uma vez que ele não exige mudança no template da VM, mas tanto o AHUB quanto o CPP precisam ser incluidos em contratos de licenciamento.
Agora divirta-se, consulte seu parceiro de licenciamento e veja quanto poderá economizar com estas duas opções de licenças!!!