System Center Configuration Manager 2012 - Distribuição de Software Focada no Usuário (pt-BR)

Artigo
17/01/2024

Neste artigo iremos focar as mudanças no modelo de distribuição de software para o SCCM 2012 e como distribuir pacotes e aplicações, incluindo o portal web (self portal) que é uma das novidades desta versão.

Novo Modelo de Distribuição de Software

Hoje o gerenciamento de aplicações é feito por dispositivos em muitos dos produtos de gerenciamento, onde temos um inventário do ambiente e com ele criamos as definições de software para serem distribuídos as maquinas.

Porem, com o advento da virtualização e uso de diversos dispositivos para acessar VMs corporativas com VDI (Virtual Desktop Infrastructure) passamos a ter um conceito chamado agora de Consumerização. Ou seja, o usuário poderá utilizar qualquer tipo de dispositivo compatível com RDP (Microsoft) ou ICA (Citrix) para acessar o seu desktop.

Esta mudança de paradigmas mostra que seriam necessários instalar softwares não mais para as maquinas e sim para o usuário. Por exemplo, em um pool de recursos VDI (diversas maquinas que atendem diversos usuários) as aplicações não podem ficar permanentemente instaladas, já que são perfis diferentes.

Com o SCCM 2012 podemos agora indicar que um software pertence ao usuário, com isso ele instalará o software onde o usuário de logar, seja físico ou virtual, e não apenas em uma maquina especifica, como mostra o diagrama abaixo. Este é o conceito User Centric, já que agora gerenciamos visando o usuário e não apenas a máquina:

Além disso, agora o SCCM 2012 permite utilizar regras de filtro para instalação de softwares e aplicações baseadas em chaves de registry, arquivos inventariados ou dados da maquina. Isso quer dizer que temos a possibilidade de indicar determinadas situações onde o software ou aplicação serão instaladas, o que não havia no SCCM 2007.

Incluído nos perfis também é possível indicar que uma mesma aplicação tem um CAB (para Symbian ou Windows Mobile), MSI (maquinas Windows) ou App-V package (aplicações virtualizadas) e o SCCM 2012 irá instalar a aplicação no formato necessário ou indicado conforme o dispositivo utilizado.

Por fim, outra novidade são os requerimentos. Muitos utilizam o recurso de sequencia do SCCM 2007 (indicando que um pacote instalará após outro pacote) para criar uma dependência, porem isso só era possível relacionamento 1-para-1, criando uma hierarquia difícil de ser monitorada. Agora com o SCCM 2012 podemos criar dependências 1-para-n permitindo criar hierarquias complexas entre software ou pré-requisitos do próprio Windows.

Vamos detalhar cada um destes itens e também ver como são configurados.

Criando Aplicações e Pacotes

Qual a diferença entre Aplicações e Pacotes?

Aplicações	Recurso novo do SCCM 2012	Aplicações podem ser MSI, CAB ou App-V Packages. Cada aplicação pode ser vinculada a um tipo de dispositivo ou perfil, sendo que uma mesma aplicação pode conter os 3 tipos de pacote indicado no momento da publicação qual será utilizado em um dispositivo especifico.
Pacotes	Recurso compativel com versões anteriores	Pacotes são diretórios onde indicamos o que dentro dele é executado, por exemplo, um EXE/CMD/VBS, etc.

Sendo assim, o novo recurso de aplicações passa a ser voltado para as novas instalações e programas e os pacotes quando temos compatibilidade com o SCCM 2007 ou aplicações que não sejam Windows Installer/App-V.

Aplicações

Para criar aplicações o primeiro passo é ter um dos tipos de arquivo compatíveis:

MSI – Arquivos Windows Installer que possuem um executável internamente com instruções de instalação, sendo atualmente o método padrão de empacotamento de aplicações da Microsoft
App-V Package – Criado pelo sequenciador do App-V Server, produto Microsoft parte do pacote MDOP para clientes com contratos de licenciamento
CAB – Pacote de aplicações similar ao MSI que são executados por Symbian e Windows Mobile

O processo começa pelo gerenciado do SCCM 2012 em Applications ao se clicar em Create Application na Ribbon.

O primeiro passo é identificar o local e o tipo de aplicação que será instalada:

Na sequencia o administrador indicará dados da aplicação que serão visualizados pelo usuário, como categorias, fabricante, contatos para suporte e outros:

O próximo passo é indicar o idioma em que a aplicação será visualizada e a possibilidade de criar uma descrição para cada idioma, o que é útil em caso de sites internacionais:

O próximo passo é criar os tipos de deploy para cada tipo de pacote, como explicado no inicio deste artigo. No exemplo acima, foi adicionado um tipo de deploy baseado em MSI:

Nota: É possível indicar se a instalação é realizada e mantida na maquina ou para o usuário, o que não tem a ver com o conceito de User Centric já que estamos falando do comportamento do software e da instalação e não sua distribuição.

Nesta próxima tela vemos as configurações de filtros, que é uma novidade muito bem vinda no SCCM 2012. No exemplo abaixo criamos um requerimento baseado no conceito de Primary Device onde o usuário indica se aquele dispositivo é seu primário (principal), mas falaremos disso mais a frente:

Outro exemplo de filtro é este, utilizando dados de inventários realizados:

Apesar de criar estas restrições em cada aplicação é possível cria-las em separado como objetos e utilizar em diversas aplicações. Para isso pode-se utilizar o menu Global Conditions como no exemplo abaixo, onde também temos demonstrado o editor de restrições quando a seleção são chaves de registro onde o SCCM agora permite visualizar o registry para selecionar a chave desejada:

Ao gerar estes itens de verificação e dependência o SCCM 2012 permite criar e visualizar graficamente os requisitos, como mostra o gráfico abaixo com as dependências indicadas:

Retornando a criação dos métodos de deploy da aplicação, o próximo passo é definir dependências de outros pacotes:

Esse processo e configurações podem ser realizadas clicando em propriedades após a finalização da aplicação, como mostra a imagem abaixo, onde acrescentamos uma sobreposição, ou atualização, a aplicação anteriormente criada:

No exemplo acima, a aplicação Joule Meter é sobreposta pela aplicação SharedView e como mostra o gráfico abaixo:

Nota: Estes gráficos de dependência e atualização são acessados pelo menu de contexto da aplicação:

Pacotes

A criação de pacotes continua igual ao SCCM 2007, primeiro definimos a origem do “pacote” que é um diretório no servidor onde estão os arquivos que desejamos distribuir:

Na sequencia é possível definir se estamos apenas distribuindo arquivos (Do not create a program), para um celular (Program for device) ou o modelo tradicional indicando o executável ou batch:

Neste caso, utilizar o modelo tradicional onde definimos dentro do diretório de origem do pacote quais são os aplicativos ou executáveis que serão iniciados no cliente no processo de deploy. No exemplo abaixo defini um pacote que contem uma série de pequenos aplicativos e um deles é o TeamViewer que irá executar com interação com o usuário já que ele não permite arquivo de resposta, o que evitaria a interação:

Na sequencia definimos os requisitos do programa, o que é bem diferente das aplicações, permitindo apenas definir o sistema operacional e um pacote que deve ser executado antes, criando uma “dependência” forçada:

Após isto é possível no console ver o pacote criado e detalhes sobre ele:

Deploy de Aplicações e Pacotes

O processo de deploy pode ser iniciado clicando com o botão direito sobre um pacote ou aplicação e definindo as regras. O deploy tem o mesmo wizard para aplicações e pacotes, já que as diferenças estão em cada um dos tipos e não em como são distribuídos, como por exemplo, restrições ou dependências.

Iniciando o deploy o administrador deverá indicar o pacote e para quem. É aqui que está um das grandes diferenças no deploy, pois note na primeira tela abaixo que está sendo selecionado um grupo de máquinas:

Já nesta segunda captura de tela vemos que agora a seleção está sendo feita por grupos (coleção) de usuários, o que é parte do conceito User Centric apresentado no inicio deste artigo:

Na sequencia definimos quais servidores da estrutura serão utilizados para distribuir o pacote aos clientes, ou seja, servidor como servidor de arquivos (File Share) para a cópia dos dados da aplicação:

O passo seguinte consiste em indicar se a aplicação estará sendo disponibilizada (Available) no portal, que será abordado a frente neste artigo, ou será instalado de forma automática (Required):

Após definir o tipo de instalação o próximo passo é definir os horários em que a instalação deverá ser realizada para os casos de obrigatória (required) ou a data de “validade” no caso de disponível (available):

Nota: Poderá ser definido em Rerun behavior o que acontecerá no próximo logon do usuário ou evento indicado em Assigment, por exemplo, caso a programa seja na verdade um script que deverá executar a cada logon ou a cada intervalo de tempo.

O passo seguinte é indicar se o usuário será notificado, o que já é selecionado conforme o tipo de instalação, e o comportamento que será realizado, evitando que a máquina reiniciei sem o usuário ser notificado:

A definição seguinte é importante para definir se a aplicação será executada diretamente no servidor pelo UNC de rede ou se deverá ser copiada nas áreas temporárias para depois ser executada. Aplicações mais novas podem ser executadas diretamente da rede, porem em geral, o ideal é fazer o download para o temporário e depois executar por questões de segurança e performance:

Por fim indicamos (se houver um SCOM na estrutura) se este pacote ou aplicação irá gerar alertas e avisos para o administrador:

Após todas as configurações é possível verificar nos dashboards quantas maquinas estarão recebendo o pacote e nos relatórios acompanhar os processos, como a imagem abaixo do dashboard da aplicação:

Simulação

O SCCM 2012 introduziu o recurso de simulação, permitindo que o administrador crie uma regra de distribuição rápida, sem a necessidade de todo o processo acima descrito, bastando para isso usar o botão Simulate Deploy disponível no Ribbon:

Portal de Aplicações

O SCCM 2012 removeu o RAP (Run Advertised Programs) e colocou estas funções no portal de aplicações que é baseado na web com recursos de escolha de aplicações, verificação das aplicações instaladas, remoção de aplicações instaladas e seleção do dispositivo primário:

Nota: Um dos filtros possíveis nas aplicações é o dispositivo primário, como mostrado na parte de aplicações acima.

Após o cliente solicitar uma aplicação em “Catálogo de Aplicativos” o administrador, ou outros usuários com a segurança necessária, poderá liberar utilizando o menu Approval Requests em Application Manager.

Configuração do Portal de Aplicações

O administrador do SCCM precisa adicionar este papel a um dos servidores, sendo simples de configurar, bastando identificar o servidor, nome da aplicação web e se o protocolo será HTTP ou HTTPS:

Histórico e Versionamento

Agora podemos verificar quem alterou um pacote ou aplicação, utilizando o menu de contexto:

Este recurso é muito bom para entender mudanças, retornar versões ou comparar modificações ao longo do tempo, o que não era possível no SCCM 2007, sendo necessário copiar o pacote antes de alterá-lo para os casos da necessidade de manter um histórico.

Conclusão e Referências

Neste artigo vimos as mudanças em distribuição de software e como estas novas funcionalidades tornaram mais simples e realmente voltado ao usuário (User Centric).