Exportar (0) Imprimir
Expandir Tudo

Implementação do Volume Activation 2.0 para Windows Vista e Windows Server 2008

Situação

A ativação do produto é uma nova exigência aos clientes de licenciamento por volume da Microsoft. A Microsoft queria oferecer a esses clientes uma ferramenta que permitiria que cumprissem esse requisito de maneira simples e automatizada.

Solução

A Microsoft IT trabalhou em conjunto com uma equipe de desenvolvimento de produtos para testar e aprimorar as ferramentas de ativação por volume. O resultado desse trabalho é o Volume Activation 2.0.

Benefícios

  • Ativações automatizadas por volume
  • Baixa sobrecarga e utilização de recursos
  • Capacidade de um modelo de ativação para atender a maioria das necessidades de ativação

Produtos e Tecnologias

  • Volume Activation 2.0
  • Windows Vista
  • Windows Server 2008
  • Windows Server 2003
  • Microsoft Operations Manager 2005
  • Serviço Servidor DNS

Publicado em: maio de 2008

O Volume Activation versão 2.0 (VA 2.0) automatiza e gerencia o processo de ativação das edições licenciadas por volume dos sistemas operacionais Windows Vista® e Windows Server® 2008. Usando o Volume Activation 2.0 ,a Microsoft encontrou um modelo para executar ativações na maioria dos ambientes de rede.

A ativação do produto é o processo de validar o software com o fabricante. Antes , a ativação de produto do Windows® era exigida somente para o software Microsoft adquirido em lojas de varejo e fabricantes originais de equipamentos (OEMs). As licenças de software adquirido por meio de programas de licenciamento por volume da Microsoft não exigiam ativação. Entretanto , a natureza e uso das chaves de produto para licenças de volume tornou o controle de seu uso difícil. Por esse motivo ,as chaves de produto das edições licenciadas por volume dos Windows XP e Windows Server 2003 tornaram-se a fonte principal de software pirateado. Na verdade , mais de 80 por cento da pirataria do Windows XP se deve à divulgação das chaves de produto emitidas aos clientes de volume.

Muitos usuários que adquirem uma cópia falsificada do software da Microsoft são vítimas involuntárias de um crime , geralmente usando inadvertidamente chaves de produto furtadas de clientes de volume legítimos. Embora o impacto do software falsificado seja sérios aos fabricantes e fornecedores de software , o impacto vai além da perda de receita a essas organizações. O software falsificado está se tornando progressivamente um meio de distribuição de vírus e software mal-intencionado que podem visar usuários desatentos , potencialmente expondo-se a corrompimento ou perda de dados pessoais ou profissionais e furto de identidade.

Para neutralizar essa ameaça , a diretiva de ativação da Microsoft exige que os clientes ativem todas as edições dos sistemas operacionais Windows Vista e Windows Server 2008 , incluindo aquelas obtidas por meio de um programa de licenciamento por volume. Essa exigência se aplica aos Windows executados em computadores físicos e máquinas virtuais. O VA 2.0 é um novo conjunto de ferramentas que ajudam os clientes a automatizar o processo de ativação em computadores que executem edições de volume dos Windows Vista e Windows Server 2008. A ativação por volume está disponível como opção de ativação somente se o software for licenciado por meio de um programa de Licenciamento por Volume da Microsoft. Os clientes que adquirem o Windows Vista ou Windows Server 2008 por meio de uma loja de varejo ou OEM os ativam usando outros métodos.

Esse estudo de caso descreve como a Microsoft Information Technology (Microsoft IT) implementou o VA 2.0 desde as edições iniciais do Windows Vista até o lançamento no mercado do Windows Server 2008 e as lições aprendidas da implementação. Ele inclui explicações dos problemas encontrados e as melhores práticas que requerem as menores sobrecargas administrativas. Esse documento foi criado para diretores-executivos de informação ,diretores de TI, arquitetos de soluções e tomadores de decisões técnicas que queiram saber como a Microsoft integrou o VA 2.0 em sua própria rede.

Situação

Entre os usuários aos quais a Microsoft IT oferece suporte estão muitos adotantes iniciais de novos sistemas operacionais. Esse suporte ofereceu à Microsoft IT a oportunidade de testar as ferramentas de ativação por volume quando o Windows Vista estava na fase beta, antes que o ciclo de desenvolvimento das ferramentas de ativação por volume estivesse concluído. O objetivo da Microsoft IT ao implementar a ativação por volume era trabalhar com a equipe de desenvolvimento de produtos do VA 2.0 para não apenas testar uma implementação em grande escala,mas também refinar e aprimorar a solução de ativação a ser oferecida aos clientes.

Objetivos da implementação

A Microsoft IT trabalhou com a equipe de desenvolvimento de produtos para realizar estes objetivos durante a implementação da ativação por volume:

  • Ativar os sistemas operacionais Windows Vista e Windows Server 2008 de maneira transparente para os usuários

  • Aprimorar a configuração do VA 2.0 necessária para reduzir custos administrativos e minimizar o custo total de propriedade (TCO)

  • Aumentar a utilidade do Pacote de Gerenciamento do Serviço de Gerenciamento de Chaves (KMS) do Microsoft Windows para o Microsoft Operations Manager 2005

  • Testar a carga dos servidores host KMS

  • Descobrir os melhores métodos para controlar o comportamento automático dos clientes KMS

  • Medir como as ativações afetam o tráfego da rede

  • Encontre o número ideal de servidores host KMS

Método de ativação

O VA 2.0 oferece dois modelos diferentes para a implementação das ativações por volume: KMS e MAK (Chave de ativação múltipla). O KMS ativa sistemas operacionais em sua rede local , eliminando a necessidade de que computadores individuais se conectem à Microsoft para ativação. Para isso, o KMS utiliza um modelo cliente/servidor. Os clientes KMS conectam-se a um servidor KMS, denominado host KMS,para solicitar ativação ou renovação de uma ativação atual. A MAK é usada para ativações únicas através dos serviços de ativação hospedados na Microsoft. A MAK requer ativação direta com a Microsoft ou permite que um computador faça uma solicitação de ativação centralizada em favor de vários computadores usando somente uma conexão à Microsoft.

A Microsoft IT decidiu usar o KMS como modelo de ativação principal por dois motivos essenciais. Primeiro, o KMS foi criado para se o método de ativação dos computadores conectados à rede principal de uma organização. A Microsoft IT planejava ativar computadores que fossem adotantes antecipados do Windows Vista, todos conectados à rede principal da organização. Segundo, a Microsoft IT criou essa implementação para para oferecer à equipe de produto do VA 2.0 informações reais de como o KMS se comportaria em uma implementação em grande escala. A Microsoft IT pôde trabalhar em conjunto com a equipe de desenvolvimento de produtos para identificar problemas, bem como simplificar e aprimorar o processo de ativação do KMS. A Microsoft IT pôde usar a MAK como método de ativação de backup para sistemas que tiveram falhas de ativação com o KMS.

Solução

A Microsoft IT implementou o VA 2.0 em cinco fases antes de entregá-lo às equipes de operações. O foco dessa implementação era usar e aprimorar os recursos automatizados do VA 2.0.

Fase 1: Teste em laboratório

A Fase 1 da implementação do VA 2.0 foi desenvolvida para testar a instalação dos hosts KMS e testar a funcionalidade básica apenas do serviço KMS. Essa fase ocorreu em ambiente de laboratório, que é uma floresta separada do resto da rede de produção. O plano da Microsoft IT para a Fase 1 era instalar dois hosts KMS: um em um computador individual e um em um controlador de domínio. Posteriormente, a Microsoft IT monitoraria as ativações de aproximadamente 100 clientes KMS ,m localizados no ambiente do laboratório de testes. A Fase 1 durou três semanas. Durante esse tempo, a Microsoft IT ativou todos os clientes com o KMS; nenhuma ativação por MAK foi necessária.

Requisitos da configuração do DNS

O comportamento padrão de um cliente KMS é consultar o DNS (Domain Name System) para obter o nome de um host KMS. Esse nome é mantido em um registro de serviço (SRV) que publica o serviço KMS. A versão do KMS usada para a Fase 1 fez com que a Microsoft IT criasse manualmente um registro SRV no servidor DNS. Após a criação desse registro , os clientes KMS localizaram os hosts KMS e os ativaram sem ações administrativas adicionais.

Limites de ativação

Testando uma pequena quantidade de clientes KMS,a Microsoft IT concluiu que é possível ter muitos hosts KMS. Isso se deve aos limites de ativação do KMS. O KMS foi desenvolvido para ambientes de rede médios e grandes. Por esse motivo,o KMS requer um número mínimo de computadores físicos em um ambiente de rede, denominado limite de ativações. A organização deve ter cinco ou mais computadores físicos para ativar o Windows Server 2008 e vinte e cinco computadores físicos para ativar os clientes que executem o Windows Vista usando o KMS. O host KMS conta a quantidade de computadores físicos que requerem ativação na rede e os clientes KMS são ativados somente após o limite ser alcançado.

Cada host KMS mantém uma contagem individual do limite de ativações. Se não houver computadores físicos suficientes em uma rede, os hosts KMS individuais podem parar de ativar clientes porque o limite de ativação não foi atendido. A Microsoft IT descobriu que as redes com menos de 100 clientes KMS podem evitar isso tendo apenas um host KMS.

Desempenho

Inicialmente, as métricas de desempenho indicaram que as ativações estavam forçando muito os processadores dos hosts KMS. A utilização da CPU se manteve em 100 por cento, embora o número de clientes KMS fosse pequeno. Com a investigação, a Microsoft IT descobriu que os clientes KMS estavam renovando suas ativações com muita freqüência. O intervalo de renovação das ativações foi aumentado de uma vez a cada minuto para uma vez a cada sete dias. À medida que a implementação avançou nas fases seguintes, a Microsoft IT descobriu que reduzir esse intervalo era uma maneira simples de testar a carga dos hosts KMS.

Tráfego de Rede

Os testes de tráfego de rede revelaram que a sobrecarga do serviço KMS é mínima. Menos de 250 bytes são enviados em cada direção na permuta completa da ativação do KMS, além da configuração e término da sessão de TCP. O tráfego adicional da rede ocorre quando um cliente KMS consulta o DNS para obter um host KMS, mas isso geralmente acontece somente uma vez por cliente KMS. Quando um cliente KMS encontra um host KMS, envia todas as futuras solicitações de renovação de ativação. O cliente KMS procura um novo host KMS somente se o host atual não responder. Além disso, nenhum tráfego de rede ocorre entre os hosts KMS. Cada host KMS mantém uma lista separada de clientes KMS, sem replicação ou compartilhamento de informações com outros hosts KMS.

Fase 2: Implementação piloto

O plano para a Fase 2 era uma implementação limitada dos clientes KMS na rede de produção com uma instalação que minimizasse o impacto na rede. A Microsoft IT selecionou um número limitado de clientes KMS na rede de produção. Para reduzir o impacto possível de adicionar o serviço KMS à rede, a Microsoft IT instalou os hosts KMS para a Fase 2 em uma floresta usada somente para testar implementações e que não faz parte da rede de produção.

Os sistemas operacionais usados para o VA 2.0 incluíram versões pré-beta dos Windows Vista e Windows Server 2008. Os computadores clientes selecionados para a Fase 2 incluíram membros de um domínio de teste de implementação, bem como membros de um pequeno domínio conectado à rede principal. Além disso, a Microsoft IT selecionou um número limitado de clientes no domínio principal da rede central. Nos computadores que pertenciam ao domínio principal,a Microsoft IT selecionou grupos de usuários que estavam fisicamente próximos uns dos outros. O motivo era testar como o tráfego da rede era afetado na subrede física. A Microsoft IT pediu a esses usuários que atualizassem seus sistemas para uma versão não lançada e licenciada por volume do Windows Vista ou Windows Server 2008. Esses três ambientes totalizaram aproximadamente 3.000 sistemas selecionados para ativação na Fase 2.

Configuração do Servidor DNS

Como os servidores DNS da Microsoft IT tinham suporte a DNS dinâmico, a Microsoft IT solicitou e recebeu uma alteração no KMS. A alteração era fazer com que o host KMS criasse e atualizasse os registros DNS necessários para o KMS para que os administradores não precisassem criá-los manualmente. Com essa alteração,o host KMS cria o registro SRV do DNS automaticamente quando o serviço KMS está ativado. Quando o serviço inicia e uma vez ao dia, o KMS substitui o registro SRV. Esse novo registro reflete quaisquer alterações.

Para a Fase 2 e fases seguintes,a Microsoft IT planejou clientes KMS de vários domínios DNS, mas que os hosts KMS pertencessem a um único domínio DNS. Por padrão, os hosts KMS publicam automaticamente o serviço KMS criando um registro SRV no domínio DNS padrão próprio. Além disso, os clientes KMS consultam somente o domínio DNS padrão para obter o local de um host KMS. Para evitar a necessidade de criar registrar DNS manualmente, a Microsoft IT solicitou e recebeu uma nova chave de registro para os hosts KMS. A chave de registro DNSDomainPublishList permite aos administradores listar todos os domínios DNS aos quais o host KMS deve adicionar um registro SRV do serviço KMS. Isso poupou à Microsoft IT o tempo e esforço necessários para criar e gerenciar registros SRV do host KMS em vários domínios DNS.

Durante a Fase 2, o servidor DNS do ambiente de laboratório permitiu que o host KMS fizesse auto-publicação, mas nos ambientes de produção, já que em muitas organizações, a capacidade de criar e atualizar registros DNS é controlada. Para que o host KMS publique o serviço KMS, precisa dos direitos para criar e atualizar registros de recursos SRV, A e AAAA em todos os domínios DNS que contém clientes KMS. A Microsoft IT atribuiu ao servidor DNS as credenciais necessárias aos hosts KMS criando um grupo de segurança nos serviços de domínio do Active Directory® AD DS e adicionando todos os hosts KMS a esse grupo. A Microsoft IT forneceu a esse grupo de segurança permissão de Controle Total sobre o registro _VLMCS._TCP para cada domínio DNS que continha clientes KMS.

Fase 3: Instalação dos Hosts KMS na Rede Principal

O objetivo principal na Fase 3 era instalar hosts KMS na rede principal. Os hosts KMS que a Microsoft IT usou na Fase 2 não foram usados na Fase 3. Em vez disso , a Microsoft IT instalou dois hosts KMS no domínio da floresta raiz da rede principal. Foi instalado um host KMS em um controlador de domínio de produção e em um servidor independente. Como os hosts KMS não compartilham informações , o processo de ativação era reiniciado para todos os clientes KMS quando os novos hosts KMS ficavam on-line. Assim , a Fase 3 incluiu os 3.000 clientes da Fase 2 , além de 4.000 clientes adicionais , totalizando 7.000 clientes KMS.

Um dos objetivos da Microsoft IT era medir o impacto de adicionar o serviço KMS a um controlador de domínio. Foram coletadas métricas do controlador de domínio que atuava como host KMS e de outros controladores de domínio no mesmo domínio. Quando a Microsoft IT comparou as mensurações do host KMS instalado em um controlador de domínio com as mensurações de outros controladores no mesmo domínio, não constatou redução de desempenho no controlador de domínio ,que também era um host KMS. A Microsoft IT concluiu que a adição do serviço KMS a um controlador de domínio não comprometeu seu desempenho.

Fase 4: Implementação do Windows Vista Beta 2

Sem carga mensurável nos servidores ou no tráfego da rede principal, o plano da Microsoft IT para a Fase 4 era um grande aumento nos clientes KMS. A Fase 4 coincidiu com o lançamento do Windows Vista Beta 2 e a ampla adoção do sistema operacional Windows Vista na rede principal. Os usuários atualizaram mais de 23.000 sistemas para uma versão licenciada por volume do Windows Vista ou Windows Server 2008, resultando em um total de aproximadamente 30.000 clientes KMS na Fase 4. Alguns desses clientes KMS eram laptops que se conectavam por meio de uma rede sem fio interna. Os usuários não relataram problemas de desempenho desses clientes.

Para acomodar o grande aumento nos clientes KMS , a Microsoft IT instalou dois hosts KMS adicionais nos controladores de domínio no domínio da floresta raiz da rede principal ,aumentando o número total de hosts KMS para quatro. Um desses hosts KMS era um servidor que executava Windows Server 2003. Esse servidor suportou 25 por cento dos clientes KMS sem problemas. Além disso , um desses hosts KMS era dedicado apenas aos clientes KMS do IPv6 (IP version 6) e não ofereciam suporte ao IPv4 (IP version 4). A Microsoft IT não encontrou diferença na operação ou desempenho desse host KMS , assim como não encontrou problemas na ativação dos clientes KMS que executavam IPv6.

Observação: O KMS vem incluído automaticamente no Windows Server 2008 e no Windows Vista, mas não no Windows Server 2003. As organizações que queiram hospedar o KMS no Windows Server 2003, devem baixar e instalar o KMS for Windows Server 2003, disponibilizado para download em http://go.microsoft.com/fwlink/?LinkID=82964, em vários idiomas. A versão de 64 bits está disponível em http://go.microsoft.com/fwlink/?LinkId=83041.

Fase 5: Implementação do Windows Vista RC

A Fase 5 coincidiu com o lançamento do Windows Vista Release Candidate (RC). 60.000 clientes KMS foram adicionados, elevando o total a aproximadamente 90.000. A Microsoft IT adicionou outro host KMS ao domínio raiz da floresta da rede principal , aumentando o número de hosts KMS para quatro controladores de domínio e um servidor independente.

Embora todos os hosts KMS estivessem no domínio da floresta raiz da rede principal , alguns dos clientes adicionados durante a Fase 5 tinham contas de computadores em uma floresta diferente, que não tinha vínculo com a floresta da rede principal. Inicialmente, a ativação desses clientes falhou. Com a investigação, a Microsoft IT descobriu que as configurações de segurança de IP (IPsec) causavam esse problema. Depois que a Microsoft IT deu permissões para que o IPSec permitisse a conectividade desses domínios aos hosts KMS,as ativações tiveram êxito.

Uma implementação adicional separada e pequena também ocorreu durante a Fase 5. Alguns clientes KMS estavam em um local remoto que se conectava à rede principal por meio de VPN (rede privada virtual). A Microsoft IT forneceu a esses clientes um host KMS separado. Observando as métricas do desempenho, a Microsoft IT concluiu que o KMS não exige que um host KMS esteja conectado a clientes KMS por meio de uma conexão de banda larga. A Microsoft IT descobriu que a latência estava em termos de segundos , enquanto os requisitos da ativação estavam em termos de semanas. Mesmo se a conexão a um host KMS expirasse e fosse tentada novamente mais tarde,o usuário não perceberia.

Configuração Atual

Após a conclusão da Fase 5, a administração do VA 2.0 passou da implementação e teste para operações e manutenção. O VA 2.0 ainda está em uso para todas as edições licenciadas por volume dos Windows Vista e Windows Server 2008. A configuração de alguns dos servidores com suporte ao VA 2.0 na rede central foi alterada.

Configuração do Servidor DNS

Durante a implementação inicial do VA 2.0, a Microsoft IT usou o serviço do servidor DNS no Windows Server 2003. Posteriormente, a Microsoft IT atualizou esses servidores para a configuração atual do serviço do servidor DNS no Windows Server 2008. Ambas as versões dos servidores DNS têm suporte aos registros SRV, de acordo com a RFC (Request for Comments, solicitação de comentários) 2782 e atualizações dinâmicas, de acordo com a RFC 2136. Todos os servidores DNS com suporte a esses RFCs, além das versões 8.x e 9.x do Berkeley Internet Domain Name (BIND), podem permitir que o host KMS publique os registros de serviço do KMS automaticamente.

Configuração Atual do Host KMS

Um dos objetivos principais da Microsoft IT era fazer teste de carga nos hosts KMS para determinar quantos clientes KMS um host poderia suportar e se os hosts KMS poderiam ser co-hospedados com outros serviços. O host KMS pode ser executado em um computador com Windows Server 2008,Windows Server 2003 ou mesmo o Windows Vista, embora os hosts KMS baseados no Windows Vista possam ativar somente sistemas Windows Vista. Além disso, um host KMS pode ser um computador físico ou sistema virtual.

A Microsoft IT continua a testar novas configurações para hosts KMS. Atualmente , dois hosts KMS dão suporte a todos os clientes KMS na rede. Esses servidores não são controladores de domínio , mas são considerados servidores de licenciamento. Eles não apenas dão suporte aos clientes KMS, mas também às licenças dos Serviços de Terminal. A Tabela 1 lista as especificações desses servidores.


Tabela 1. Especificações de hardware dos hosts KMS

ComponenteConfiguração da Microsoft IT
Processador Dois AMD64, 2.205 megahertz (MHz) cada
Memória 2.046 megabytes (MB)
RedeEthernet de 1-gigabyte (GB)
Disco Uma unidade de disco rígido físico de 70 GB

O KMS usa recursos intensos do computador. A utilização de CPU pode atingir momentaneamente 100 por cento em um computador com processador único durante o processamento de várias solicitações de ativação. Entretanto , as solicitações de ativação do cliente KMS são geralmente escalonadas. Ao tentar ativar-se durante o período de cortesia inicial , o cliente KMS faz solicitações de ativação a cada duas horas , por padrão e solicitações de renovação a cada sete dias após a ativação.

Melhores Práticas

A Microsoft IT concluiu que o modelo KMS de ativação funcionou para a maioria dos ambientes de rede com impacto insignificante na rede e no computador que hospeda o serviço KMS. Não houve necessidade de ativação por MAK exceto em redes desconectadas, como redes de alta segurança que não têm o número de computadores físicos exigidos pelos limites de ativação do KMS. As melhores práticas determinadas pela Microsoft IT durante o estudo de caso são:

  • O KMS satisfaz a maioria dos ambientes de rede. Uma organização deve usar o KMS quando conveniente.
  • Os ambientes de rede com os servidores DNS mais recentes têm poucas etapas de instalação para ativações por KMS.
  • Os servidores que executam outras funções podem adicionar tarefas de hospedagem do KMS com efeitos insignificantes no desempenho.
  • Ambientes de rede pequenos devem ter apenas um host KMS.
  • Após a configuração, o KMS requer poucos recursos administrativos.

Monitoramento da Ativação do Cliente KMS

Quando o(s) host(s) KMS ficam on-line pela primeira vez, os administradores devem monitorar o êxito das ativações dos clientes, além do número de ativações que cada host KMS executa. O cliente KMS registra as solicitações de ativação ,renovações e as respostas no log do aplicativo local do cliente KMS. Os logs do host KMS separam entradas para cada solicitação recebida de um cliente KMS. Essas entradas são salvas no log do Serviço de Gerenciamento de Chaves na pasta de logs Aplicativos e serviços.

O administrador pode arquivar e ver os logs de eventos do KMS manualmente. Ou,se a organização usar o Microsoft Operations Manager 2005,o administrador poderá usar o Pacote de Gerenciamento do MOM 2005 do Serviço de Gerenciamento de Chaves (KMS) do Microsoft Windows. O Pacote de gerenciamento do KMS contém relatórios de ativação detalhados dos computadores que executam Windows Vista e Windows Server 2008. O Resumo de atividade do KMS fornece o número de novas ativações do KMS e pode fornecer esses números de todos os hosts KMS.

uando as ativações iniciais estiverem concluídas,o administrador pode estabelecer alertas no Pacote de gerenciamento do KMS que forneçam notificações quando os períodos de cortesia de um computador ou a ativação atual estiverem para vencer. O administrador também pode usar o relatório Resumo do status de licenciamento para ver o número de dias restantes para que os clientes KMS renovem suas ativações.

Equilíbrio de Carga dos Hosts KMS

Em um ambiente de rede que tenha dois hosts KMS , se ambos ficarem on-line simultaneamente , o servidor DNS alternará os clientes KMS entre os dois hosts KMS e os clientes KMS serão divididos entre os hosts KMS. Entretanto,se outro host KMS entrar on-line após o primeiro host KMS, o novo host KMS não terá clientes KMS. Isso se deve ao comportamento padrão do cliente KMS.

Quando um cliente KMS está corretamente ativado, envia todas as futuras solicitações de renovação de ativação ao host KMS original que o ativou. Contanto que o host KMS original responda ao cliente KMS, o cliente não procurará outro host KMS. Nesse caso, a Microsoft IT encontrou duas formas de equilibrar a carga entre um host KMS atual e um novo host KMS. Primeiro, o administrador pode reiniciar o host KMS original e deixar ambos os hosts on-line novamente simultaneamente. Isso limpa o cache de ativações no host original e inicia o limite de ativações novamente.

Se reiniciar não for uma opção, o administrador poderá bloquear a porta que o serviço KMS usa –porta TCP 1688 – no host KMS original. As tentativas de renovação do cliente ficarão sem resposta, fazendo com que procurem um novo host KMS do DNS. O administrador precisa monitorar o número de clientes que passaram para o novo host KMS para determinar quando desbloquear a porta. O número de dias nos quais a port será bloqueada deve ser menor que o intervalo de renovação do cliente. Se o administrador bloquear a porta durante todo o intervalo de renovação do cliente (por padrão,sete dias), todos os clientes KMS terão passado para o novo host KMS.

Conclusão

A ativação do produto é exigida para todas as edições dos Windows Vista e Windows Server 2008. O VA 2.0 permite aos clientes de licenciamento por volume automatizar o processo de ativação para que haja pouco ou nenhum impacto nos usuários finais. Embora o VA 2.0 proporcione aos clientes de licenciamento por volume dois modelos para ativação do Windows Vista e Windows Server 2008 , a Microsoft IT concluiu que o modelo KMS atende a maioria das necessidades de ativação. A baixa sobrecarga de utilização de recursos e o pouco tráfego de rede torna o KMS útil em vários ambientes de rede.

O objetivo da implementação da ativação por volume da Microsoft IT não era apenas testar como as ativações funcionavam em grande escala, mas também aprimorar a experiência do usuário quanto ao produto. O resultado está nos aprimoramentos feitos ao VA 2.0 que simplificam e automatizam o processo de ativações por volume.

Para obter mais informações

Esse estudo de caso é um exemplo de como o VA 2.0 foi implementado em uma grande organização. Vários recursos e ferramentas estão disponíveis para auxiliar as organizações a planejar e implementar o VA 2.0. Para obter mais informações sobre a terminologia usada ou procedimentos para a execução das tarefas discutidas nesse estudo de caso, consulte esta documentação:

Para obter mais informações sobre os produtos ou serviços da Microsoft, ligue para o Microsoft Sales Information Center em (800) 426-9400. No Canadá, ligue para o Microsoft Canada information Centre em (800) 563-9048. Fora dos Estados Unidos e Canadá, contate a subsidiária local da Microsoft. Para acessar informações pela Internet, visite:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

Baixar Implementação do Volume Activation 2.0 para Windows Vista e Windows Server 2008

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2015 Microsoft