Virtualização

Introdução a Microsoft Application Virtualization

Anthony Kinney

Este artigo se baseia em uma versão de pré-lançamento da App-V. Todas as informações deste artigo estão sujeitas a alterações.

Visão geral:

• Arquitetura da App-V
• Gerenciando aplicativos virtuais
• Usando o seqüenciador da App-V
• Integrando a App-V ao Gerenciador de Configurações

Sumário

A arquitetura da App-V
Como funciona toda a infra-estrutura da App-V
Atualizando aplicativos virtuais
Seqüenciamento
Versão 4.5

A Microsoft Application Virtualization (ou App-V) é uma querida plataforma minha. A App-V era conhecida como SoftGrid, e cheguei à Microsoft por meio da aquisição da empresa que criou a SoftGrid, chamada Softricity. Estou muito entusiasmado por ter a oportunidade de escrever este artigo para a TechNet Magazine agora, porque muita coisa mudou desde a aquisição.

A melhor forma de abordar a App-V é primeiro falar sobre os desafios enfrentados por profissionais de TI em termos de gerenciamento corporativo. Atualmente, o desktop de negócios se pauta por aplicativos. Antes da instalação de um aplicativo, ele deve passar por um longo teste de regressão para garantir que seja capaz de coexistir com os demais aplicativos instalados no sistema sem que haja impacto na possibilidade de execução apropriada. Em seguida, o aplicativo deve passar por uma série de processos de implantação antes de chegar à produção. E como um aplicativo só está disponível, essencialmente, onde está instalado, os usuários estão vinculados a computadores específicos. Isso complica ainda mais projetos complexos, embora críticos como, por exemplo, migrações de sistema operacional e aplicativo, atualizações de segurança e planejamento de recuperação de desastre.

A App-V muda tudo isso. Em vez de ser uma série complexa de etapas demoradas que esgotam recursos, a administração de desktop se torna um processo mais simples, automatizado com a App-V. É possível implantar, corrigir, atualizar e encerrar aplicativos mais facilmente e com melhores resultados.

Com a App-V, um usuário pode se sentar em qualquer desktop e acessar seus aplicativos. Os aplicativos são oferecidos sob demanda, mas executados como se estivessem instalados localmente. Por isso, não há necessidade de instalar os componentes do aplicativo ou alterar o dispositivo host.

Esse uso da virtualização poderia alterar drasticamente a forma como os profissionais de TI gerenciam desktops. Por outro lado, deixar de alterar o dispositivo host e executar os aplicativos virtualizados apresenta inúmeras vantagens, inclusive:

• menos conflitos de aplicativo
• atualizações de aplicativo mais rápidas e fáceis
• a possibilidade de executar várias versões do mesmo aplicativo lado a lado
• Aplicativos flexíveis que acompanham usuários online e offline
• Redução do teste de regressão entre aplicativos

A arquitetura da App-V

Agora observemos o que está acontecendo realmente nos bastidores da plataforma App-V. A plataforma consiste em poucos componentes principais: um seqüenciador, um banco de dados, clientes, um servidor de gerenciamento, um servidor de streaming e um console de gerenciamento (consulte a Figura 1).

Figura 1 Layout de um ambiente da App-V (Clique na imagem para ampliá-la)

No núcleo do sistema App-V está o cliente App-V. Existem dois tipos de cliente que podem ser usados: o cliente do Terminal Server e o cliente de desktop. Em ambos os casos, o cliente deve ser instalado em cada desktop e Terminal Server no qual você pretende implantar os aplicativos virtuais. O cliente ocupa, relativamente, pouco espaço em disco. Ele instala um driver e apresenta um componente de runtime do usuário visível mostrado como um indicador na bandeja.

O cliente obtém uma lista dos aplicativos virtuais do App-V Management Server e exibe os aplicativos virtuais disponíveis. Ele trata a inicialização desses aplicativos (quando iniciado pelo usuário) e o gerenciamento do cache do lado do cliente. O cliente também é responsável por gerenciar a criação do ambiente de runtime virtual e garantir que cada ambiente seja executado na bolha virtual própria. Esse ambiente virtual inclui vários componentes, inclusive um Registro virtual, um sistema de arquivos virtual e um gerenciador de serviços virtual.

Existem três opções de implantação de infra-estrutura disponíveis na App-V 4.5: infra-estrutura completa, infra-estrutura leve e modo autônomo. Quando você implanta uma infra-estrutura completa, o back-end inclui o App-V Management Server e o App-V Streaming Server (trata-se de um componente novo que abordarei brevemente). O App-V Management Server hospeda e oferece os aplicativos virtuais centralizados, bem como atualiza os aplicativos virtuais quando patches ou atualizações são aplicados.

Esse servidor de gerenciamento depende do SQL Server para hospedar o banco de dados da App-V, que contém a configuração e as definições de aplicativos virtuais. Você deve usar grupos do Active Directory como a ferramenta de gerenciamento centralizada para provisionar e controlar permissões para aplicativos virtuais.

Para gerenciar as definições e a configuração, a plataforma App-V fornece um Web service do Microsoft .NET Framework que pode ser carregado no mesmo servidor, desde que o IIS esteja instalado. Esse Web service funciona como um elo entre o App-V Management Console – um snap-in do Console de Gerenciamento Microsoft (MMC) – e o banco de dados da App-V. Os administradores podem usar o console para publicar e gerenciar aplicativos virtuais, atribuir grupos do Active Directory e controlar configurações do servidor, bem como executar relatórios de uso dos aplicativos virtualizados (consulte a Figura 2).

Figura 2 Console de gerenciamento (Clique na imagem para ampliá-la)

A infra-estrutura leve inclui o servidor de streaming da App-V, que habilita recursos de streaming como, por exemplo, atualização de pacote/ativo. Essa opção não exige o Active Directory ou o SQL Server; ela não tem nenhum serviço de configuração de desktop e não conta com recursos de licenciamento e medição. No entanto, a infra-estrutura leve não permite que recursos de streaming sejam adicionados ao System Center Configuration Manager (SCCM) e a outras soluções em implantação de software corporativo (ESD) de terceiros.

No modo autônomo, o seqüenciador da App-V pode criar um arquivo MSI que automatiza a adição do aplicativo virtual (consulte a Figura 3). O arquivo MSI contém metadados que permitem a qualquer sistema ESD reconhecê-lo e controlar o aplicativo virtualizado. Esse modo exige que o cliente acesse o modo autônomo, que só permite atualizações baseadas em MSI dos aplicativos virtuais, e o streaming não é permitido no modo autônomo. Esse modo dá às organizações a possibilidade de usar os recursos de isolamento da App-V.

Figura 3 Seqüenciador da App-V (Clique na imagem para ampliá-la)

Os arquivos MSI são muito flexíveis; eles podem ser executados de maneira totalmente autônoma com apenas um cliente App-V, não exigindo nenhum componente de servidor. Isso significa que eles podem ser implantados manualmente, com um disco ou por meio de ferramentas de implantação tradicionais.

Na App-V 4.5, HTTP e HTTPS agora são protocolos com suporte para streaming. Isso possibilita um melhor desempenho do streaming, com um protocolo adotado mais amplamente, em especial do streaming em ambientes de rede de longa distância (WAN) e na Internet.

Como funciona toda a infra-estrutura da App-V

Um usuário faz logon em um dispositivo que apresenta um dos clientes (serviços de terminal da App-V ou cliente de desktop) instalados, e o cliente envia uma solicitação para o servidor a fim de obter uma lista de aplicativos atribuídos ao usuário atual. O servidor se comunica com o Active Directory para determinar de quais grupos o usuário é membro e, em seguida, retorna a lista dos aplicativos para o cliente. O cliente começa a criar anúncios para os aplicativos virtuais atribuídos a esse usuário em especial.

Nesse processo de publicação, várias ações são realizadas:

• os arquivos de configuração são copiados
• os ícones da área de trabalho são criados
• os links Enviar Para são criados
• as pastas no menu Iniciar são criadas
• os tipos de arquivo são configurados

Esse processo é muito rápido e, o que é mais importante, garante que o ambiente seja exatamente como o usuário espera, sem nenhuma alteração visual. Os aplicativos virtuais funcionam como se estivem instalados localmente, mas, é claro, não alteram a máquina host. Os ícones, em vez de apontar para executáveis que residam no diretório de arquivos de programa, apontam para o cliente da App-V, que depende de um arquivo de inicialização (um arquivo OSD) para a configuração.

É importante observar que esse processo tem um impacto mínimo sobre a rede porque, diferentemente das implantações de software tradicionais, nada é instalado. Isso tem benefícios enormes, especialmente em ambientes de usuário móveis, porque os aplicativos estão disponíveis para o usuário, mas nada é efetivamente oferecido até a inicialização de um aplicativo. Esse método de anúncio também é o que fornece os recursos de aplicativo sob demanda e móveis da App-V.

Quando o usuário inicia um aplicativo virtual, o cliente lê um arquivo de configuração OSD, armazenado na máquina local. Isso informa ao cliente qual protocolo usar durante a comunicação com o servidor de gerenciamento da App-V e em qual servidor o aplicativo reside.

O servidor apropriado responde ao cliente transmitindo o limite de inicialização inicial, normalmente entre 20 e 40 por cento de todo o aplicativo. Após a transmissão de todo o limite de inicialização (mais uma vez, apenas de 20 a 40 por cento do aplicativo), o aplicativo virtual está pronto para ser executado.

A transmissão é, de fato, um dos principais elementos da mudança de paradigma introduzida com a App-V. Ela pode enviar o suficiente de um aplicativo de forma que ele possa ser executado sem desperdiçar uma parte importante da largura de banda da rede. Todos os dados passados para o cliente residem em um arquivo de cache local no dispositivo e qualquer inicialização subseqüente do aplicativo acontece no cache local, o que elimina tráfego de rede adicional.

Após a conclusão da transmissão do aplicativo virtual, o cliente cria um ambiente isolado que impede o aplicativo de alterar a máquina local (em outras palavras, o aplicativo não apresenta superfície do cliente). No entanto, o cliente permite ao aplicativo virtual acessar o sistema de arquivos local ao salvar e editar arquivos, além de também permitir a interação do aplicativo com serviços locais (como, por exemplo, a impressão), desde que o usuário tenha os privilégios apropriados no sistema local. Mas qualquer alteração feita por um aplicativo virtual nos arquivos do sistema local e no Registro é redirecionada para o ambiente virtualizado para que o dispositivo host permaneça inalterado.

Quando o aplicativo está em execução, todos os recursos que não foram usados anteriormente são fornecidos conforme necessário e armazenados em cache tendo em vista o uso subseqüente. A vantagem disso é que apenas os componentes exigidos pelo usuário são carregados durante a primeira inicialização, e os recursos que não são necessários não consomem recursos de rede. (A nova versão fornece algumas melhorias no cache do lado do cliente que possibilitam um uso mais inteligente do cache e streaming em segundo plano.)

Considere o Microsoft Office Word, por exemplo. Praticamente todos os usuários usam verificador ortográfico (caramba, não poderia ter escrito este artigo sem ele!); por isso, ele faria parte da primeira inicialização. Mas e o recurso Ajuda do Word? Nem tantos usuários usam esse recurso e, por isso, ele não precisaria ser oferecido durante a primeira inicialização. Na verdade, ele seria enviado para um usuário na primeira vez em que fosse acessado.

Quando o usuário termina e fecha o aplicativo, o cliente desativa o ambiente virtual e armazena todas as configurações do usuário em um local específico do usuário para que o ambiente possa ser mantido e recriado durante a próxima inicialização. Qualquer porcentagem do aplicativo virtual transmitida permanece no cache local, sendo disponibilizada na próxima inicialização. E caso outro usuário faça logon no mesmo sistema host e inicie o mesmo aplicativo virtual, o novo usuário aproveita o aplicativo já armazenado no cache.

Para remover os anúncios de aplicativo virtual, basta remover o usuário do grupo do Active Directory. E para desinstalar completamente o aplicativo virtual de um desktop, basta limpar o cache. Como o aplicativo jamais foi, de fato, instalado localmente, não há avisos incômodos perguntando "Deseja remover este componente compartilhado?".

Observe que, mesmo que um aplicativo virtual seja armazenado em cache, isso não significa que todos os usuários tenham acesso a ele. Diferentemente dos aplicativos instalados localmente em que os usuários podem simplesmente pesquisar ou procurar executáveis para os quais não tenham direitos, não existem representações visuais ou físicas de que o aplicativo virtual exista, a menos que o usuário tenha recebido direitos explícitos por meio dos grupos do Active Directory.

Atualizando aplicativos virtuais

A atualização é feita usando o seqüenciador. Depois de ser revisado para incluir uma atualização, um aplicativo é colocado no servidor de gerenciamento da App-V ao lado da versão anterior. Em seguida, o servidor notifica o cliente, durante a próxima inicialização, que foi feita uma alteração. Caso a versão anterior ainda esteja sendo usada, o usuário continua tendo acesso a essa versão até que o aplicativo virtual seja fechado. Durante a próxima inicialização, as deltas que constituem a atualização são transmitidas para o cliente e carregadas no cache, o que resulta em uma versão atualizada do aplicativo.

Digamos que haja mil usuários executando o Word 2000. Como precisa atualizar o Word 2000 (word2K.sft) para o Word 2000 SP3, a administradora copia o arquivo word2K.sft para a estação de seqüenciamento e seleciona Open for Package Upgrade no seqüenciador. Selecionando Open for Package Upgrade, a administradora começa a trabalhar usando o estado do pacote mais recente. Em seguida, ela pode copiar DLLs, executar atualizações ou patches no aplicativo virtual a fim de atualizá-lo para Word 2000 SP3. Depois, a administradora salva esse pacote atualizado.

O seqüenciador atribui automaticamente um novo nome de arquivo, word2K_2.sft, para impedir nomes de arquivo duplicados e indicar a versão do seqüenciamento. Esse novo pacote é colocado no mesmo diretório do pacote anterior no servidor de gerenciamento da App-V de forma que o Word 2000 (word2K.sft) e o Word 2000 SP3 (word2K_2.sft) acabem residindo no mesmo diretório. Em seguida, a administradora usa o console de gerenciamento da App-V para vincular esses dois arquivos SFT.

No lado do cliente, os usuários que tenham uma sessão ativa do Word 2000 sem o SP3 aberto continuam funcionando normalmente. Os usuários que iniciarem uma nova sessão do aplicativo depois que a administradora terminar essa vinculação receberão uma mensagem de que foi detectada uma alteração. Em seguida, o cliente começa a transmitir apenas as alterações delta entre word2K.sft e word2K_2.sft, atualizando automaticamente o aplicativo para o Word 2000 SP3.

Por conta da natureza dinâmica dos aplicativos virtuais, a reversão também é bem fácil. Basta retornar ao console de gerenciamento da App-V e remover a versão recém-adicionada. Isso faz com que o cliente seja revertido para a versão anterior durante a reinicialização. Para garantir que não haja crossover dos dados do pacote, o cliente limpa automaticamente o cache e retransmite o arquivo STF apropriado. Trata-se de um compromisso justo quando você considera o que deve ser feito para reverter uma atualização de aplicativo instalada fisicamente usando ferramentas de implantação de software mais tradicionais.

Para obter os benefícios da App-V, você deve criar pacotes de aplicativos virtuais. É aí que entra em cena o seqüenciador da App-V. Todo conhecimento e experiência que você tem em script e criação de pacotes para ferramentas de implantação de software tradicionais facilitará a transição para o seqüenciamento. (Devo ressaltar aqui que o seqüenciamento poderia estar em todo um artigo.)

A maior parte das soluções em implantação de software depende de scripts que capturam a forma como um aplicativo se instala e, em seguida, duplica o processo em outras máquinas, eliminando a necessidade de visitar todas as máquinas para instalar ou atualizar aplicativos. Após a instalação do aplicativo, as ferramentas de implantação de software comuns deixam de lado o pacote. Em seguida, você deve instalar todas as dependências das quais o aplicativo pode depender, executar outros scripts ou executar etapas manuais para configurar o aplicativo de acordo com as necessidades.

A alteração fundamental na App-V é que o processo de seqüenciamento gera uma imagem de um aplicativo já instalado, completo com dependências e configurações. Ela pode ser "executada" pelo cliente da App-V sem alterar o dispositivo em que está sendo executada.

O seqüenciador gera vários arquivos, sendo o mais importante deles o STF, que contém todos os ativos do aplicativo, as dependências e as informações de configuração. Em alguns casos, ele pode conter vários aplicativos. Não é de surpreender que esse arquivo seja bem grande. Há algumas opções de compactação, mas um bom conhecimento do desempenho da rede e do dispositivo é essencial. O arquivo de ícone (.ico) criado pelo seqüenciador é usado para anunciar o aplicativo virtual de forma que ele funcione como se estivesse instalado localmente.

O arquivo OSD também é muito importante, e as opções são inúmeras. Por padrão, trata-se de um arquivo baseado em XML usado para informar ao cliente da App-V como iniciar o aplicativo virtual. O arquivo OSD também pode ser modificado para configurar e controlar como o aplicativo virtual é iniciado e executado. Sugiro que você leia o Sequencing Admin Guide e o documento Sequencing Best Practices para se familiarizar com as propriedades e os valores disponíveis no arquivo OSD.

Por fim, o novo arquivo manifest.xml contém informações de configuração baseadas em pacote e podem ser usadas para integração com soluções ESD de terceiros e implantações de MSI. O seqüenciador também pode gerar um arquivo MSI para o pacote de aplicativo virtual. Ele pode ser usado para carregar os aplicativos virtuais em clientes autônomos (sem servidor) e por meio de um sistema ESD.

O próprio seqüenciador é uma ferramenta baseada em assistente que orienta você, o gerenciador, em meio ao processo de instalação de um aplicativo e transformação em um aplicativo virtual (consulte a Figura 4). A primeira etapa permite configurar propriedades padrão para o pacote. Entre essas propriedades, armazenadas no arquivo OSD, estão o nome do pacote e os comentários. Algumas das configurações avançadas permitem especificar o servidor de transmissão, o diretório de conteúdo e a quais sistemas operacionais o pacote oferece suporte.

Figura 4 O assistente de seqüenciamento (Clique na imagem para ampliá-la)

A segunda etapa é instalar, configurar e testar o aplicativo. Durante a instalação, o seqüenciador captura todas as alterações feitas no sistema local, inclusive no sistema de arquivos, no Registro e no sistema. Também existem alguns utilitários nesse assistente que permitem, por exemplo, a integração com o Windows Update.

A próxima etapa é configurar as associações do tipo de arquivo e especificar onde os atalhos devem ser colocados. Entre locais padrão estão o menu Iniciar, a área de trabalho e a barra de início rápido, mas também é possível criar locais personalizados.

Em seguida, você precisa iniciar o aplicativo e configurar o limite da primeira inicialização. Trata-se da etapa em que a App-V determina a parte inicial do aplicativo que precisa ser apresentada ao cliente para permitir a inicialização do aplicativo.

Para configurar esse código inicial (conhecido normalmente como bloco de recurso 1, ou FB1), basta iniciar o aplicativo e usar os recursos mais comuns exigidos pelos clientes. Por exemplo, inicie o Word e, em seguida, o verificador ortográfico. Qualquer DLL, arquivo ou chave do Registro chamado pelo aplicativo durante essa fase é designado automaticamente como parte do FB1. Todos os arquivos, as configurações ou os componentes não usados a essa altura são adicionados ao FB2. Em seguida, quando o aplicativo for usado, o cliente receberá um mapa do arquivo STF que indica onde o FB1 começa e termina e onde estão os demais arquivos no FB2 para que o cliente possa recuperá-los quando exigidos pelo aplicativo.

A etapa final do processo de seqüenciamento é garantir que tudo esteja configurado corretamente. O seqüenciador exibe a caixa de diálogo mostrada na Figura 5, que representa o SFT e permite fazer todas as adições finais ou alterações no pacote.

Figura 5 Confirmando e ajustando um pacote final (Clique na imagem para ampliá-la)

Versão 4.5

Após dois anos de criação, a App-V 4.5 está pronta para ser lançada neste ano. Trata-se da primeira versão Microsoft do produto a ser lançada, e a promessa é de elevar a virtualização de aplicativo introduzindo várias melhorias importantes como, por exemplo, a interação do aplicativo virtual dinâmico, a escalabilidade estendida e o melhor alinhamento com os requisitos de internalização e segurança Microsoft.

A interação do aplicativo virtual dinâmico permite que aplicativos virtualizados interajam entre si. Essa interação é conhecida como Dynamic Suite Composition (DSC). A DSC não substitui a possibilidade de adicionar vários aplicativos ao mesmo pacote. Na verdade, ela oferece uma forma de integrar dependências, middleware e plug-ins compartilhados entre aplicativos virtuais.

Os administradores podem especificar quais aplicativos virtualizados podem interagir entre si. Por exemplo, vamos supor que você tenha cinco aplicativos Web que exijam a mesma versão Java. Na App-V 4.1, você teria que adicionar essa mesma versão Java a todos os cinco pacotes separados. E vamos supor que a versão Java precisasse de um patch. O administrador teria que corrigir os cinco pacotes diferentes. Usando a DSC, o Java pode ser empacotado uma vez e, em seguida, configurado como um pacote a ser usado por todos os cinco aplicativos Web. Dessa forma, o patch Java exigiria que o administrador corrigisse o pacote Java apenas uma vez.

O mesmo cenário se aplica a middleware e plug-ins. Pretendo blogar outros cenários de caso de uso na medida em que a Microsoft se aproximar do lançamento e finalizar todas as adições mais recentes.

Melhorias feitas na escalabilidade envolvem transmissão e infra-estrutura de back-end. Os componentes de back-end foram modificados para oferecer melhor suporte a cenários de clustering e failover, e a transmissão está mais amigável a WAN e LAN. As melhorias vêm de várias adições principais.

A primeira é o Streaming Server Component, que possibilita o streaming sem a necessidade de uma infra-estrutura de back-end do Active Directory do SQL Server. Você ainda tem os grandes benefícios de uma entrega sob demanda e da atualização centralizada de pacotes, mas sem os grandes requisitos de back-end. Isso será muito usado em cenários de filial e na integração com soluções em ESD de terceiros.

O cliente da App-V também recebeu algumas melhorias. Por exemplo, agora o cliente armazena todas as informações de uso localmente de forma que elas possam ser controladas, independentemente do sistema cliente estar dentro ou fora da rede. O cache do cliente também foi expandido e melhorado tendo em vista um melhor desempenho em cenários com espaço em disco limitado. Agora também existe suporte ao seqüenciamento de aplicativos que não estejam em inglês, executando a App-V em sistemas operacionais que não estejam em inglês e a localização em vários outros idiomas.

Integrando a App-V ao Gerenciador de Configurações

Várias melhorias e novos recursos da App-V 4.5 foram projetados para integrar a App-V ao SCCM 2007 R2. Como já abordei, a virtualização e o streaming oferecem alguns recursos para fornecer aplicativos que as ferramentas de implantação de software tradicionais não conseguem. Não estou querendo dizer que a App-V substituirá essas ferramentas, e sim que pode complementar e estendê-las.

Com essa integração, você tem toda a escalabilidade, os relatórios, o reconhecimento de dispositivo e os recursos WAN do SCCM com todos os recursos de streaming e isolamento da App-V. Eis algumas das áreas que aproveitam a integração dessas duas tecnologias:

Entrega do aplicativo A integração do SCCM R2 oferece suporte a todos os recursos de entrega sob demanda, aplicativos móveis, limites de inicialização inicial e implantação de aplicativos sem alterar PCs clientes.

Atualizações Os Pontos de Distribuição (DPs) do SCCM podem implantar apenas as alterações delta dos aplicativos virtuais quando os pacotes são atualizados. Isso introduz a possibilidade centralizada de reverter aplicativos virtualizados para versões anteriores com um único clique.

Gerenciamento A versão R2 introduziu um novo assistente de anúncio de aplicativo virtual que permite aos administradores implantar aplicativos virtualizados, bem como pacotes de software tradicionais e anúncios em um único console.

Empacotamento Não há necessidade de empacotar novamente os aplicativos ao integrar a App-V com o SCCM. A seqüência inicial de um aplicativo precisa ser feita usando a seqüência da App-V fora do SCCM, mas os administradores têm a possibilidade de atualizar os pacotes existentes usando o SCCM.

Licenciamento Os aplicativos virtuais podem ser controlados em termos de licenciamento e medição usando as ferramentas existentes no SCCM.

BITS O SCCM oferece um novo método para implantar aplicativos virtualizados no App-V usando o protocolo BITS, padrão do setor. Muito embora os DPs do SCCM possam transmitir, há casos em que o streaming não é o método ideal para implantar aplicativos virtualizados. Ao implantar usando SCCM, você tem duas opções. É possível usar o streaming padrão ou os recursos de Qualidade de Serviço (QoS) do BITS para implantação de maneira muito mais controlada. Isso também é útil em cenários nos quais você gostaria de pré-carregar o cache antes da inicialização do aplicativo virtual pelos usuários.

Implantações em máquina O SCCM fornece a possibilidade de implantar aplicativos virtualizados em máquinas específicas, bem como de continuar oferecendo suporte à abordagem de destino baseada no usuário da plataforma App-V. Isso pode ser benéfico quando você implanta aplicativos virtuais em laptops, quiosques e máquinas de laboratório. Isso também é útil para ajudar no controle de licença quando o software pode ser licenciado por dispositivo, e não por usuários nomeados.

Escalabilidade A necessidade de implantar duas ferramentas separadas com muita sobreposição é uma preocupação comum. Integrando a escalabilidade e os benefícios de WAN do SCCM aos de isolamento e streaming da APP-V, é possível usar o SCCM existente, que fornece uma única ferramenta para tratar o gerenciamento e a implantação sem que seja necessário adicionar mais complexidade.

Anthony Kinney é profissional de vendas técnico responsável pelo Microsoft Desktop Optimization Pack. Anthony ingressou na Microsoft em 2006 com a aquisição da Softricity. Ainda na Softricity, Anthony escreveu e projetou o primeiro programa de treinamento em SoftGrid (agora App-V). Entre em contato com ele pelo email Anthony.kinney@microsoft.com.