Novo Modelo de Updates do SCCM 2016

03 outubro 2016 msincic Configuration Manager, System Center, Operations Manager, Service Manager
Como já havia escrito a algum tempo, uma das mais interessantes novidades do System Center 2016 é a capacidade dos produtos em se atualizarem automaticamente. No System Center Operations Manager (SCOM) e Service Manager (SCSM) são so Management Packs e no System Center Configuration Manager (SCCM) a atualização inclui os binários do servidor, agente e console.   Atualização Automática do SCCM Pelo console do SCCM acesse Administration –> Cloud Services –> Updates and Servicing e será possivel ver a lista de atualizações, que no caso do SCCM são os Builds, uma vez que ele não possui mais versões. Clique sobre a versão que está disponivel, o SCCM irá manter o histórico das atualizações já realizadas. Ao selecionar a atualização é possivel ver os novos recursos que a atualização irá fazer, a lista de Knowlegde Bases: Um item interessante ao iniciar atualização é que podemos ignorar os pré-requisitos como pode ser visto na tela abaixo no checkbox para ‘forçar” a atualização. Claro que é importante deixar que os requisitos sejam testados, instalar uma atualização que não está com o ambiente completo pode gerar problemas e indisponibilidade permanente. Outro item importante é a possibilidade de escolher as features que serão incluidas no SCCM com a atualização. Por exemplo, o Apple Volume Purchase é instalado nesse momento como se fossem as features pelo console em “Site Roles and Services”. Caso não opte por instalar as features no momento da instalação da atualização, é possivel executar novamente mais tarde pelo mesmo caminho: Como as atualizações “carregam” as novas features podemos escolher quais iremos habilitar como em outras configurações de roles: Por fim após o update o SCCM poderá pedir para reiniciar o console e finalizar a instalação:   Conclusão Realmente é um recurso excelente ter as atualizações a mão de forma tão simples e confiável. Esse recurso tornará mais fácil manter o SCCM e outros produtos System Center saudáveis com as ultimas atualizações.

Windows Defender ATP–Entenda o Novo Produto

24 julho 2016 msincic Active Directory, Azure, Microsoft Azure, System Center, Windows 10, Segurança, Windows ATP, Windows ATA
Parte dos novos recursos do Windows 10 é a capacidade de detalhamento na segurança e integração com recursos do Microsoft DCU (Digital Crime Unit), que é a unidade da Microsoft que trabalha com o departamento de defesa para gerar e identificar ataques ao redor do mundo (https://blogs.windows.com/windowsexperience/2016/03/01/announcing-windows-defender-advanced-threat-protection/). Tipos de Proteção Disponiveis Em geral os antivírus são baseados em DAT que são arquivos com assinaturas de vírus e conseguem identificar programas que tenham atividades ou parte destes códigos considerados perigosos. Nessa categoria estão todos os antivírus atuais, o que inclui o Windows Defender. Já os sistemas de proteção avançados contem com análise comportamental interna e externa, ou seja, eles identificam potenciais ameaças por comportamentos como fazem alguns produtos da Symantec e McAfee, que identifica maquinas enviando pacotes para outras maquinas, logins com força bruta, etc. Já os sistemas de proteção comportamental com análise externa são produtos bem diferentes. Eles analisam comportamentos de maquinas no ambiente e comunicações externas. Com isso é possível identificar: Um grupo de maquinas recebendo pacotes de uma determinada maquina com conteúdo suspeito Pacotes oriundos de países onde o ataque de phishing e similares são comuns Pacotes oriundos de maquinas já identificadas como “zumbi” Ou seja, com base na análise do próprio ambiente e de comportamento de hackers, é possível identificar que determinado hacker está tentando invadir uma empresa ao analisas que este hacker está enviando pacotes para a rede da empresa alvo.   O que é o ATA e o ATP Nos produtos Microsoft esse produto é o ATA (Advanced Thread Analisys) que trabalha no Active Directory e logins, e o ATP (Advanced Thread Protection) que trabalha com Machine Learning (análise de dados) sobre os logs das maquinas individuais. Na prática o Windows Defender ATP trabalha com o mesmo log que o Windows Defender, mas online e com base nas análises e dados do DCU. Com isso é possível identificar ameaças que não são encontradas nos tradicionais DAT ou com base apenas em uma única maquina que é a forma como os antivírus tradicionais trabalham. O ATA é parte do EMS (Enterprise Mobility Suite), mas pode ser adquirido a parte: https://www.microsoft.com/pt-br/server-cloud/products/advanced-threat-analytics/overview.aspx O ATP ainda está em preview com acesso por solicitação: https://www.microsoft.com/en-us/WindowsForBusiness/windows-atp   Overview do ATP Como já possuo acesso ao ATP, vamos ver como ele funciona. Para pedir esse acesso, entre na página acima e complete com seus dados. É possível incluir maquinas de seu ambiente, mas o sistema gera algumas maquinas com vírus e problemas para testes automaticamente. Note nas telas abaixo que o usuário utilizado é gerado pela Microsoft para os testes. Ao receber o acesso, o primeiro passo é indicar tempo de retenção e perfil da empresa que serve para elaborar threads por tipo de segmento: Na sequencia geramos o pacote ou o script para distribuição das configurações. Note que é possível criar os pacotes para distribuição por GPO, SCCM, Intune ou Local que é o que utilizarei nos meus testes: O passo seguinte é baixar o pacote, no meu caso o Local Script: O script contem um arquivo CMD para ser executado manualmente nas maquinas que desejo que o log do Defender seja enviado para o ATP. Esse script cria uma chave no registro para indicar o meu tenant e ativar o ATP: A partir de agora as suas maquinas passarão a enviar dados para o ATP em algumas horas. No caso do meu teste, posso utilizar os dados da maquina que a Microsoft gera com testes e ver os alertas e o dashboard. A primeira tela é o Dashboard que indica o comportamento geral no ambiente monitorado: Neste caso não tenho alertas gerados nos últimos 30 dias, mas tenho os de criação do tenant para demonstrar como utilizar o gerenciamento de alertas: Cada alerta pode ser ignorado, marcado como resolvido ou suprimido em todo o tenant ou apenas para esta maquina específica:   Conclusão Este tipo de análise dos dados é essencial para a segurança da corporação. Em breve disponível como serviço no Azure, o ATP é uma nova forma de analisar e garantir seu ambiente.

Utilizando o Azure Log Analytics (OMS) e o SCOM na Mesma Maquina

09 julho 2016 msincic Microsoft Azure, System Center, Operations Manager, Windows Azure, OMS, Azure, Log Analytics
Para utilizar o Log Analytics, antigo Operational Insights, junto com o System Center Operations Manager é possível fazer isso pelo console do próprio SCOM. Essa forma de integração já em Março/2014: http://www.marcelosincic.com.br/post/Integrando-o-SCOM-ao-System-Center-Advisor.aspx Apesar de ter alterado o nome de System Center Advisor, depois para Operational Insights e agora Log Analytics, o processo de integração com o SCOM se manteve o mesmo. Porem a uma limitação no processo de integração do SCOM, pois ele só permite uma conta de OMS/Log Analytics por organização. Em muitos casos é necessário usar mais de uma conta, por exemplo: Provedores de serviço e CSC em que cada cliente tem uma conta diferente no Azure Quando utilizamos múltiplas assinaturas para monitorar um mesmo ambiente físico Quando uma das contas é beneficio de Visual Studio com créditos limitados e desejamos separar os servidores em contas diferentes Nestes casos podemos utilizar os dois métodos os mesmo tempo, instalar o agente do SCOM e não vincular a uma conta do Log Analytics e fazer o processo apenas nas maquinas desejadas. Para isso, o primeiro passo é abrir o Log Analytics e copiar o Workspace ID e o Primary Key. Veja no exemplo abaixo que já tenho meu SCOM integrado ao Log Analytics. O passo seguinte é ir até a maquina que deseja monitorar e abrir o agente de monitoração do SCOM (Microsoft Monitoring Agent): Ao abrir as configurações do agente note a aba Azure Operational Insigths (nome anterior a Log Analytics). Veja nesse print que já tenho a maquina sendo reportada ao SCOM: Insira os dados da sua conta do Log Analytics e pronto, agora é possível ter a monitoração com várias contas ou individual: Agora os meus dados de Active Directory que antes não estavam sendo populados passam a estar devidamente preenchidos e monitorados:

Instalando o System Center Service Manager Authoring

29 junho 2016 msincic System Center, Service Manager, Visual Studio
Na versão Technical Preview ou 2012 R2 do Service Manager Authoring é comum não conseguir passar do ponto abaixo da verificação de pre-requisitos: Mesmo clicando e deixando o instalador rodar o Visual Studio Shell 2008, a mensagem de que ele não está presente continua. Para resolver isso é importante entender o motivo. O Shell do Visual Studio não é apenas um componente, mas sim um conjunto. O que acontece é que o Check do Service Manager Authoring não faz a instalação de todos os componentes, apenas o Shell que precisa de outros requisitos. Para resolver baixe o Shell, execute e vá até o diretório criado pelo instalador e execute o aplicativo VS_Shell_Isolated.enu Veja que vários componentes serão instalados e atualizados e por isso que o instalador Service Manager Authoring não completa o processo de pré-requisitos: Após a execução do Shell, execute novamente o instalador do Service Manager Authoring e agora passara pela verificação com sucesso!

Reinstalação do DPM pós-Avaliação ou Technical Preview

29 junho 2016 msincic System Center, Data Protection Manager, vNext
Uma das duvidas comuns que me mandam é quando se instalou o System Center Data Protection Manager, seja uma versão avaliação ou um Technical Preview, ao tentar desinstalar para atualizar o DPM ocorre o erro de que o DPM já está presente ou que ele está instalado como avaliação. Esse erro acontece em vários casos, mas o corriqueiro é quando se utilizou um Technical Preview e a desinstalação mantem a chave de licença. Para resolver o problema basta apagar a chave de licença que “sobra”: Abra o Editor de Registro (RegEdit.exe) Vá até a chave HKEY_CLASSES_ROOT\Licenses Delete a chave 830D982D-9ADC-4479-85CE-6474F7D00BB1 Após a remoção da licença do DPM, a instalação ocorre com sucesso!

Microsoft Virtual Machine Converter (MVMC)–Retirada do Produto

08 junho 2016 msincic Cloud computing, Hardware, Hyper-V, Microsoft Azure, System Center, Virtual Machine Manager, Virtualizaçao
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

Software Asset Management (SAM) com System Center Configuration Manager–Software Metering (Parte IV)

26 maio 2016 msincic Configuration Manager, SAM, System Center
Neste quarto artigo sobre como utilizar o SCCM para falar de SAM (Software Asset Management) vamos falar sobre o Asset Software Metering (métricas de software). Para lembrar da nossa pauta e a agenda dos itens, use o link de introdução: http://www.marcelosincic.com.br/post/Software-Asset-Management-(SAM)-com-System-Center-Configuration-Manager.aspx Introdução do Software Metering Quando precisamos gerir uso de software é importante controlar quem precisa e realmente usa um determinado ativo de software. Muitas vezes nos deparamos com a situação de usuários que pedem e instalam diversos softwares, ou até colocamos isso em imagens, e a empresa passa a pagar a conta por algo que nunca foi usado. Anteriormente até a versão 2007 R3 era possível indicar quantas execuções simultâneas podiam ser executadas de um software, porem este tipo de licenciamento não existe mais. Nas regras de licenciamento atual conta-se a instalação de um software e não a execução dele. Empresas que ainda utilizam o método de execução simultânea utilizam logs no servidor ou então keylocks específicos. Um bom exemplo da necessidade do Metering são produtos como Access, Visio e Project. Muitas instalações de Visio e Project foram feitas para uma única ocasião que o usuário precisou e lá ficou consumindo licença e consequentemente dinheiro. O caso do Access é a diferença entre o Office Standard e o Office Professional, que em valores são muito diferentes (Professional chega a ser mais que o dobro de preço do Standard) mas em funcionalidade a principal diferença é Access e Skype For Business full. Poucos usuários realmente usam o Access, a maioria poderia usar apenas o engine de Runtime. No caso do SfB pode-se usar a versão Basic que só não funciona para VoIP ou conferencia multi-ponto, que são recursos pouco usados no dia a dia da maioria dos usuários. Habilitando a Função Software Metering não é uma role de servidor e sim uma feature que é controlada pelo Management Point. O funcionamento básico do Metering pode ser descrito como: Habilita-se a regra de Metering nas configurações de agentes Criamos ou habilitamos quais softwares inventariados serão medidos O agente recebe as regras de metering e passam a controlar o uso dos softwares indicados Periodicamente estes dados são enviados ao Management Point que irá consolidar Para habilitar a regra, basta ir em Administration –> Client Settings e alterar a regra default ou criar uma especifica: No exemplo acima habilitei o Metering e indiquei que os agentes irão reportar a cada 7 dias. Esse tempo é importante dentro de seu cronograma de gestão de ativos, se você controla ativos mensalmente pode aumentar o período para quinzenal, mas é importante lembrar que se o período de coleta for alto poderá ter dados atrasados. Por exemplo, se o período de coleta for de 20 dias e um determinado agente fez o report dos dados no dia 14, ele só irá reportar novamente no dia 4 do mês seguinte. Se seus relatórios são gerados no primeiro dia do mês, ele estará com dados incompletos para este agente do exemplo. Portanto, em geral escolha o período de 7 ou 5 dias. Depois de habilitado a regra do agente podemos indicar no servidor qual o período de retenção dos dados e se desejamos que a lista de software seja copulada automaticamente: Note que é possível indicar que um software só apareça automaticamente na lista se estiver em mais de 10% dos computadores, para evitar que a lista fique tão grande com qualquer executável que exista nas maquinas. Também note que podemos definir um limite e após este (no exemplo 100 softwares) não irá mais ser criada a regra para novos softwares. Definindo os Softwares que serão medidos O Metering se aproveita do inventário de software para gerar uma lista, trazendo todos como desabilitados: A forma mais fácil de trabalhar o Metering é habilitando para os softwares desejados, porem isso tem como inconveniente a versão do arquivo (File Version) pois o inventário gera as regras por versão. Isso pode ser útil para empresas que possuem diversas licenças de softwares em edições diferentes, por exemplo o Visio 2010, 2013 e 2016. Nestes casos é possível saber quem utiliza o Visio na versão especifica. Porem, na maioria dos casos isso é irrelevante. Não controlamos quem usa cada versão, pois a quase totalidade dos softwares não permitem edições diferentes na mesma maquina. Sendo assim, é possível alterar os dados ou criar regras novas usando coringas como “*” para indicar que qualquer versão, idioma ou nome vale para a regra. Por exemplo, podemos alterar a regra de versão acima do VMConnect.exe para “*” ou “6.*” e assim aumentar o range de medição ao invés de criar uma regra para cada versão. Além disso, é possível criar suas próprias regras como o exemplo abaixo: Neste caso estamos medindo o uso do Word em qualquer idioma e versão de Office. Relatórios do Software Metering Existem atualmente 13 relatórios para o Metering: Alguns são muito interessantes e merecem destaque. O primeiro deles é o “Total Usage for all metered software programs” que fornece dados resumidos de todos os softwares com regra habilitada, separando por uso local ou pelo Remote Desktop: Como o licenciamento de TS/RDS é diferente de licenciamento local, estes dados são muito importantes para gerar um licenciamento otimizado para a empresa. Outro relatório que parece não ter muita valia mas serve para propósitos administrativos é “Time of day usage summary for a specific metered software program" pois fornece uma visão de demanda: Por exemplo, essa informação pode ser útil para medir performance de rede relativa para aplicações cliente servidor como SAP, TOTVS ou outros que sofrem picos de uso durante o dia. Outros relatórios também fornecem dados interessantes: Computers that have a metered program installed but not run in time – Permite ver computadores que tem, por exemplo Project e não o usam durante o mês inteiro Computers that run a specified metered software program – É o inverso do anterior, demonstrando quem utilizou o programa durante o mês Total usage trend analysis for a specific metered software program – Este relatório detalha o anterior, pois mostra quantas vezes um determinado software foi usado e por quanto tempo. Este relatório permitirá identificar alguém que usou um software e ficou com ele aberto por 10 segundos, indicando que na verdade abriu por engano. Conclusão O Software Metering não é uma parte do SAM, pois não representa dados de licenciamento como faz o Asset Intelligence. Porem, o Software Metering é essencial para reduzir e otimizar o licenciamento que as empresas pagam, por permitir saber quem realmente usa um determinado software para trabalho.

Software Asset Management (SAM) com System Center Configuration Manager–Asset Intelligence (Parte III)

18 maio 2016 msincic Configuration Manager, SAM, System Center
Neste terceiro artigo sobre como utilizar o SCCM para falar de SAM (Software Asset Management) vamos falar sobre o Asset Intelligence (AI) ou Ativos Inteligentes. A diferença entre inventário e controle/gestão de ativos é a inteligência sobre os dados coletados, o que é feito pelo Asset Intelligence no System Center Configuration Manager. Para lembrar da nossa pauta e a agenda dos itens, use o link de introdução: http://www.marcelosincic.com.br/post/Software-Asset-Management-(SAM)-com-System-Center-Configuration-Manager.aspx Ativando a Role (Feature) Para ativar o AI é necessário ativar a role em um dos servidores do Site System, neste caso utilizo o meu servidor primário: A configuração da role AI é muito simples, apenas se habilita e define o agendamento:                Configurando a Feature A configuração da role AI é tão simples quanto foi a ativação, na prática basta usar o botão “Enable or Disable Asset Intelligence Syncronization Point”. Essa sincronização é necessária para montar a tabela de produtos, categorias e requisitos de produtos. Como pode ser visto no menu acima, o AI trabalha com essas informações para montar dados de inventários inteligentes indicando os computadores que estão com softwares não adequados e mesmo para montar a lista de licenciamento dos produtos Microsoft. O resultado da sincronização é demonstrado no quadro abaixo: Veja que 31 dos softwares instalados no meu ambiente inventariado foram identificados, outros 51 não estão no cadastro da Microsoft, e podem ser vistos clicando-se no numero 51: Pode-se notar que neste caso a maioria dos softwares são Microsoft, mas não estão identificados pois como pode ser visto na primeira tela do AI, ele não sincronizou nos ultimos 6 meses  Podemos manualmente identificar os itens clicando em propriedades e inserindo os dados como categorias e familias de software. Esse dado não é essencial para licenciamento ou inventário, mas essencial para gestão de ativos uma vez que categorizar e dividir em familias é parte dos relatórios sintéticos apresentados. Note tambem que temos a possibilidade de usar Label 1-3 para customizar relatórios desejados com produtos ou outra informação que seja importante na sua organização. Por fim no menu temos a opção Hardware Requeriments que obviamente identifica os requisitos que um software precisa. Também é util quando desejamos executar relatórios para gestão de ativos de hardware, priorizando computadores que estão aquem da necessidade dos softwares nele instalados: Por fim, no menu Catalog podemos incluir as categorias, familias e labels customizados. É importante manter essa tabela alinhada com suas necessidades de relatórios, mas não é essencial ao funcionamento ou a prática de gestão de ativos: Importação de Licenças A importação de licenças é feita para criar os relatórios de gestão e licenciamento. Para isso clique no botão Import Software Licenses: Onde esse arquivo pode ser encontrado ou criado? Para clientes corporativos é possivel usar o site VLSC que lista todas as compras de softwares realizadas, e tem a opção de importar para XML. Basta pegar o arquivo gerado e importar para dentro do SCCM. Se for montar este arquivo manualmente, pode-se utilizar o modelo disponivel em https://technet.microsoft.com/en-us/library/hh427341.aspx. Basicamente criamos uma planilha em Excel e exportamos para CSV. A dificuldade neste caso é criar o arquivo com os nomes exatos de softwares, fabricantes e informações de versão e edição. Mas uma vez criado o arquivo, a manutenção é muito simples. Relatórios de Hardware Os relatórios do AI ficam na categoria própria e podem ser visualizados pelo Filter como demonstrado na lista de relatórios abaixo: Os primeiros relatórios são os de Hardware onde o AI utiliza dados coletados para gerar relatórios com diferenças significativas dos relatórios de inventário normal. Destaque para alguns relatórios: 03A Primary computer users – O AI identifica qual o principal computador de cada usuário, isso é baseado em quem utiliza o computador por mais de 66% do tempo 04A Computers with multiple users – Em computadores onde não existem um usuário que fica logado por mais de 66%, isso é indicação de um computador compartilhado por vários usuários 10A Computers in … have changed memory – Lista de computadores que tiveram alterações de memória, que é a comparação entre diferentes inventários de hardware e identifica a mudança 10B Changes on a specified computer… – Lista o que foi alterado em um determinado periodo de tempo em um computador selecionado, o que é util para identificar mudanças em um computador de referencia ou estratégico Importante: Para funcionarem os relatórios 03A e 04A é importante que o Log de segurança do Windows esteja habilitado: https://technet.microsoft.com/en-us/library/gg712322.aspx#BKMK_EnableSuccessLogonEvents Relatórios de Software A segunda parte dos relatórios são os de software: Alguns relatórios são mais importantes de software, apesar de todos serem especialmente necessários: 04A/B/C Autorun – São relatórios que permitem ao administrador visualizar os softwares que estão em auto-execução nos computadores, o que é importante em um grande ambiente 07A/B/C Recently used executable by Computers – São relatórios interessantes para a gestão de ativos, mas normalmente usamos os relatórios de Software Metering, que é um requisito para funcionarem 08A/B/C Recently used executable by Users – São relatórios como os da série 07, mas baseado no numero de usuários 09A/B Infrequently used software – Esse relatório é o mais importante desta categoria, pois dele é que decidimos onde desinstalar um software com licenças insuficientes ou decidir a compra de um software. Por exemplo Viso, Project e principalmente Visual Studio tem alto custo e saber onde não são usados é uma economia significativa Importante: Para os relatórios de software do AI funcionarem é necessário que esteja habilitado o Software Metering https://technet.microsoft.com/en-us/library/gg712306.aspx Relatórios de Licenciamento Estes relatórios são os que importam nessa série. Podemos destacar os mais importantes: 01A/B/C/D Microsoft VL ledger – São relatórios que nos permite visualizar o resumo do licenciamento que foi importado, principalmente quando o arquivo foi importado do VLSC estes relatório nos darão a visão do licenciamento total 02A/B/C Nearing expiration – São relatórios uteis quando os softwares tem data de expiração, o que pode acontecer com Office 365 e outros produtos comprados em contrato EAS que anualmente precisam ser renovados 06A/B Per-Processos licensed – Estes relatórios são essenciais para o licenciamento de SQL Server e Windows Server que possuem o licenciamento por processador (Windows) ou Core (SQL Server). No caso do SQL o licenciamento também pode ser no modelo Server+CAL e isso só pode ser controlado manualmente 14B – List of MS SW…not found – Util para validar produtos que não estão em uso e podem ser substitutos de outros que estão com licenciamento estourado, por exemplo trocar a versão do Office Professional pelo Standard 14A e 15A Reconciliation – São os mais importantes, os que resumem o licenciamento Abaixo estão os mais importantes. O primeiro identificando as compras e o canal (a legenda fica na ultima página), lista dos produtos inventariados que precisam de licença que é util para criar o arquivo de licenças manual junto com o terceiro onde vemos os produtos que não foram encontrados no arquivo de licenças: Por fim, o mais importante deles é o relatório de conciliação. Como pode ser visto, boa parte do trabalho manual já é realizada pelo SCCM: