 TechNet Magazine January 2008

TechNet Magazine January 2008

System Center: Controle real com o Virtual Machine Manager 2007

A virtualização permite que as organizações consolidem recursos e economizem dinheiro. Mas quando você começar a implementar números cada vez maiores de máquinas virtuais, precisará de uma maneira prática de gerenciá-las. Este é um guia para a configuração do Virtual Machine Manager e seu uso para executar tarefas administrativas a partir de uma interface centralizada.

Edwin Yuen System Center: Backups melhores com o Data Protection Manager 2007

A versão mais recente do Data Protection Manager oferece muitos recursos novos, fornecendo uma solução flexível e eficiente para gerenciar backups. Aqui está uma visão geral de como o DPM pode proteger tudo: do Exchange ao SQL Server, de filiais aos sites do SharePoint.

Calvin Keaton System Center: Serviços online ajudam a simplificar o inventário de software

O gerenciamento de ativos de software é uma tarefa essencial para todas as empresas – grandes ou pequenas. Porém, com a quantidade de softwares que as empresas agora compram e implantam, entender esses ativos pode parecer quase impossível. Descubra como o novo Asset Inventory Service da Microsoft pode ajudar.

Paul Bourgeau Diretiva de Grupo: Conhecendo os modelos ADM e ADMX para Diretiva de Grupo

Os arquivos ADM são necessários e geralmente confusos. Não permita que isso diminua seus esforços em relação à Diretiva de Grupo. Este tour guiado ajudará você a entender melhor os arquivos ADM e o novo formato ADMX, que ferramentas pode usar para manipulá-los e como fazer o melhor uso desses arquivos.

Jeremy Moskowitz Diretiva de Grupo: Otimizando o desempenho da Diretiva de Grupo

As Diretivas de Grupo não são todas iguais. Saber as diferenças entre os tipos pode ajudar a ajustar o desempenho em seus sistemas. Explore GPs funcionais e monolíticas, aprenda a processar Diretiva de Grupo e descubra o que acontece quando ocorrem alterações em Diretivas de Grupo.

Darren Mar-Elia Diretiva de Grupo: Informações detalhadas sobre o Gerenciamento Avançado de Diretiva de Grupo

O Gerenciamento Avançado de Diretiva de Grupo (AGPM) é uma ferramenta útil que permite trabalhar com GPOs (Objetos de Diretiva de Grupo) de uma forma que outras ferramentas não fazem. E agora ele está disponível para membros do programa Microsoft Software Assurance. Confira como o AGPM pode ser usado para editar GPOs offline, delegar administração, rastrear alterações, e muito mais.

Derek Melber Do editor: Convencendo um cético

Joshua Hoffman Cartas: A palavra está com os leitores

Caixa de ferramentas: Novos produtos para profissionais de TI

Greg Steen Perguntas e respostas do Exchange: Adicionando prompts de voz, escolhendo um PBX, e muito mais

Você tem perguntas sobre a Unificação de Mensagens do Exchange? Nós temos as respostas. Nesta primeira edição de Perguntas e respostas do Exchange, vamos nos concentrar na Unificação de Mensagens, discutindo como é possível implementar recursos de telefone e fax, oferecer alta disponibilidade, configurar prompts de voz, e muito mais.

Seema Rahman Utilitário em destaque: Assistente da transferência fácil do Windows

Essa ferramenta gratuita pode simplificar a migração de aplicativos fundamentais do Windows XP para o Windows Vista.

Lance Whitney The Cable Guy: Aprimoramentos do DNS no Windows Server 2008

O Windows Server 2008 inclui muitos aprimoramentos do servidor DNS. Repare como essas atualizações aceleram a resolução de nomes, aprimoram o suporte a IPv6 e adicionam maior flexibilidade à administração do DNS.

Joseph Davies Windows PowerShell: Prevenção contra código mal-intencionado

Ao desenvolver o Windows PowerShell, muito se pensou em relação à segurança. Mas, como com qualquer software, o Windows PowerShell ainda pode estar exposto a códigos maliciosos. Veja algumas recomendações para a escolha de uma Diretiva de Execução que manterá os seus sistemas mais seguros.

Don Jones Ei, Equipe de Scripts!: Não há como errar usando expressões regulares

Procurando um meio de evitar cometer erros? A validação é bom começo. Saiba como executar correspondência de padrão de caracteres em um script usando expressões regulares.

The Microsoft Scripting Guys Security Watch: Saltos de ilha: armadilha em forma de brindes

As ameaças de segurança não se originam apenas de emails e sites maliciosos. Veja como um pen drive USB e um pouco de engenharia social simples podem ser usados para obter acesso a toda a rede. Além disso, saiba o que você pode fazer para manter a sua rede mais segura contra essa ameaça.

Jesper M. Johansson Os arquivos da área de trabalho: Computação compartilhada com o Windows SteadyState

O novo kit de ferramentas do Windows SteadyState pode ajudá-lo a aumentar a segurança e simplificar o gerenciamento de sistemas Windows XP em um ambiente de uso compartilhado? Faça um tour guiado para descobrir como.

Wes Miller Anotações de campo: Sua tarefa mais importante do dia

Quando estiver trabalhando em um projeto, não subestime a importância de reservar um tempo para pensar, planejar e priorizar.

Eric N. Bush Segredos do Windows: Lembre-me de nunca fazer isso novamente

A detecção de hardware antes da existência de dispositivos adequados de Plug and Play era muito arriscada. Saiba por que.

Raymond Chen


 System Center: Controle real com o Virtual Machine Manager 2007
System Center Edwin Yuen

Controle real com o Virtual Machine Manager 2007
Visão geral:
  • Principais recursos do System Center Virtual Machine Manager 2007
  • Como instalar o VMM
  • Como converter máquinas físicas ou virtuais em VMs

O System Center Virtual Machine Manager 2007 é uma nova solução que fornece uma interface consolidada para o gerenciamento de toda a sua infra-estrutura virtual. O Virtual Machine Manager (VMM)
pode gerenciar instalações existentes do Microsoft® Virtual Server 2005 e também pode instalar o Virtual Server 2005 R2 SP1 em novos hosts de máquina virtual (VM). Com o VMM, as tarefas administrativas tradicionais do Virtual Server 2005 agora podem ser realizadas com muito mais eficiência através de uma interface centralizada, com acesso de gerenciamento a várias instalações do Virtual Server.
Além disso, o VMM oferece novos recursos ao Virtual Server, incluindo conversões P2V (Physical-to-Virtual, físico para virtual), conversão V2V (Virtual-to-Virtual, virtual para virtual) de discos VMDK (VMware Virtual Machine Disk Format, formato de disco de máquina virtual VMware) em VHDs (Virtual Hard Disks, discos rígidos virtuais) do Servidor Virtual e rápidas implantações de VM a partir de modelos e VHDs pré-configurados por meio de uma biblioteca centralizada de objetos de infra-estrutura virtual.
Nas páginas a seguir, explorarei o VMM e o conjunto avançado de recursos que ele fornece aos administradores de TI. Em seguida, apresentarei os requisitos e as etapas para a criação de uma instalação VMM. Finalmente, descrevei em detalhes os excelentes recursos do VMM e algumas dicas úteis para você começar.

Introdução ao Virtual Machine Manager 2007
O System Center Virtual Machine Manager 2007 é um aplicativo autônomo que fornece gerenciamento centralizado de classe corporativa das máquinas virtuais em execução no Microsoft Virtual Server 2005. Como parte da família do System Center, o Virtual Machine Manager integra-se a outros produtos do System Center para fornecer gerenciamento completo de infra-estrutura virtual e física. A Figura 1 mostra os vários componentes do Virtual Machine Manager e como o VMM está relacionado a um host do Servidor Virtual.
A caixa à esquerda representa o servidor do VMM e, à direita, representa um host da máquina virtual. Os componentes do VMM também podem ser instalados em servidores separadores, se você preferir, a fim de aprimorar o desempenho e a escalabilidade. Para este artigo, utilizaremos o modelo na Figura 1, onde os principais componentes do VMM são todos instalados em um computador. No núcleo do produto do VMM, encontra-se o serviço do Virtual Machine Manager, no centro à esquerda. Acima dele, estão as três interfaces diferentes do serviço: a interface do Windows PowerShellTM, o Console do Administrador e o Portal de Auto-atendimento com o gerenciamento de Provisão delegada. O suporte ao VMM é uma instalação do banco de dados do Microsoft SQL Server® 2005 (você pode usar uma instalação completa do SQL Server ou SQL Server 2005 Express Edition) e a biblioteca centralizada, que é um compartilhamento de arquivo para componentes da infra-estrutura virtual.
Figura 1 Arquitetura do System Center Virtual Machine Manager 2007
Figura 1 Arquitetura do System Center Virtual Machine Manager 2007
O lado direito da Figura 1 representa um host da máquina virtual do Virtual Server 2005 R2 que o VMM está gerenciando. Na parte inferior está o sistema operacional do host – nesse caso, o Windows Server® 2003 R2. O VMM instalará um agente no host da máquina virtual que facilitará a comunicação entre o VMM e o Virtual Server 2005 R2. Essa é uma instalação única no host físico, sem instalação nas VMs ou no SO convidado. Se o Servidor Virtual não estiver instalado na máquina de host, o VMM poderá realizar automaticamente a instalação quando o host for adicionado à lista de servidores gerenciados.
Como parte da família de produtos do System Center, o Virtual Machine Manager utiliza a nova interface do System Center (ou no estilo do Outlook®) para o Console do Administrador (em oposição ao snap-in do MMC tradicional). O Console do Administrador do VMM (consulte a Figura 2) foi desenvolvido usando o Microsoft .NET Framework 2.0 e é incorporado no Windows PowerShell 1.0. Na realidade, qualquer ação realizada no Console do Administrador chama de fato o comando do Windows PowerShell associado. Conseqüentemente, qualquer comando ou função chamado no Console do Administrador também poderá ser invocado diretamente através da linha de comando no Windows PowerShell.
Figura 2 IU do administrador do VMM mostrando máquinas virtuais gerenciadas
Figura 2 IU do administrador do VMM mostrando máquinas virtuais gerenciadas
Cada assistente no Console do Administrador também tem um botão Exibir script que mostrará o script do Windows PowerShell associado para o comando que está prestes a ser executado, que fornece um excelente ponto de início para aprendizado de como o Windows PowerShell está relacionado ao VMM. Assim que você se familiarizar com o uso do Windows PowerShell com o VMM, poderá fazer o script de ações em massa através do VMM.
O Virtual Machine Manager foi desenvolvido para fornecer três principais vantagens aos administradores de TI: ele permite que você maximize os recursos, obtenha mais agilidade e aproveite as habilidades existentes. O VMM fornece essas vantagens por meio de vários recursos e funções. Primeiramente, o VMM ajuda a maximizar os seus recursos ao fornecer um método para conversão de seus servidores físicos em máquinas virtuais, um processo conhecido como conversão de P2V, que permite que você consolide suas máquinas físicas existentes em máquinas virtuais sem precisar reinstalar essas máquinas. Isso é especialmente significativo ao converter máquinas com pouca utilização de hardware, pois você pode posicionar várias máquinas juntas em uma única parte do hardware físico. Isso pode ser especialmente útil para, digamos, máquinas com software de legado que raramente são utilizadas, mas precisam ser mantidas pois são executadas uma vez por ano (por exemplo, software de contabilidade normativo). Quando usado em conjunto com o System Center Operations Manager 2007, o VMM pode ajudar a produzir um relatório de candidatos à consolidação de servidor, a fim de analisar quais máquinas na infra-estrutura física são prováveis candidatos ao P2V.
Se você já tiver máquinas virtuais no formato VMDK do VMware, o VMM fornecerá o recurso de realizar uma conversão de V2V para converter os seus VMDKs existentes no formato de VHD. Isso coloca rapidamente o seu ambiente Virtual Server 2005 em funcionamento.
Como parte de qualquer implantação, seja nova ou iniciada através de conversão, o VMM usará um processo denominado Intelligent Placement para implantar as VMs nos hosts de máquina virtual. Usando o Intelligent Placement, o VMM consultará todos os hosts de máquina virtual que gerencia, recuperará vários parâmertos sobre a disponibilidade de recursos desses hosts e retornará então uma lista ponderada dos hosts recomendados para implantação na VM. Como você pode ver na Figura 3, o administrador poderá escolher então aceitar a recomendação, ajustar o algoritmo para que atenda a necessidades específicas ou basta implantar a VM no servidor de sua escolha. Com essa visão consolidada da infra-estrutura virtual e suas recomendações de host, o Intelligent Placement reduz extremamente as cargas relacionadas à implantação de VM.
Figura 3 O Intelligent Placement fornece recomendações para o melhor host do Virtual Server
Figura 3 O Intelligent Placement fornece recomendações para o melhor host do Virtual Server
Outros recursos do VMM que proporcionarão excelentes vantagens incluem uma biblioteca centralizada e um portal de auto-atendimento para o provisionamento delegado. A biblioteca, mostrada na Figura 4, fornece um armazenamento central para todos os componentes necessários para criar uma infra-estrutura virtual, incluindo VHDs pré-criados e prontos para implantação, modelos com configurações de hardware e SO, scripts, perfis e arquivos ISO. As novas VMs podem ser criadas e implantadas a partir desses componentes e o uso de modelos e perfis pode padronizar as configurações de hardware e software nas VMs. O VMM também oferece suporte a bibliotecas distribuídas, permitindo que os componentes sejam armazenados em locais remotos e mantendo transferências de arquivos de grande porte no local remoto e, ao mesmo tempo, continuar gerenciando os componentes centralmente.
Figura 4 A biblioteca do VMM contém todos os blocos de criação para uma infra-estrutura virtual
Figura 4 A biblioteca do VMM contém todos os blocos de criação para uma infra-estrutura virtual
O portal de auto-atendimento é um site da Web que se integra com o serviço do VMM e uma instalação do IIS. O portal concede acesso a usuários e grupos autorizados do Active Directory® a VMs, com todas as funções disponíveis, dependendo da diretiva criada para esse usuário ou grupo. Essas funções variam da capacidade de visualizar e acessar as VMs à execução e ao desligamento das VMs, até a criação de novas VMs com base em recursos delegados específicos.
O administrador cria uma diretiva de auto-atendimento que concede funções específicas a usuários e grupos do Active Directory, a hosts ou grupos de hosts de máquina virtual específicos, bem como a VMs e modelos específicos. O portal de auto-atendimento fornece ao administrador a capacidade de delegar com segurança funções a usuários finais. Sem essa função, o administrador precisaria conceder acesso aos usuários finais ao Console do Administrador, a fim de gerenciar suas VMs, ou os usuários finais fariam solicitações para cada função, resultando em extenuantes emails e telefonemas apenas para realizar ações como iniciar e reiniciar a VM.

Instalação do Virtual Machine Manager
O VMM atualmente gerencia instalações do Virtual Server 2005 (e posteriores) no Window Server 2003 SP1 (e acima) no domínio do Active Directory (ou domínio confiável), bem como hosts que não sejam de domínio usando o suporte à rede de perímetro do VMM. Não é oferecido suporte às instalações do Virtual Server em sistemas operacionais de desktop, como o Windows® XP. As operações de P2V estão disponíveis somente para máquinas físicas localizadas no mesmo domínio (ou domínio confiável) que o servidor do VMM.
Embora eu recomende que cada componente de VMM seja instalado em servidores separados em um ambiente de produção, as instruções apresentadas neste artigo abordarão uma instalação de servidor único. O hardware recomendado para uma instalação de servidor do VMM é um servidor baseado em x86 ou x64 com execução em 2,8 GHz ou acima com, pelo menos, 2 GB de RAM. Como essa é uma instalação de servidor único com um banco de dados local do SQL Server, 7 GB de espaço no disco rígido serão necessários. Se for usado um banco de dados remoto, somente 1 GB será necessário para a instalação do VMM. Um adicional de 80 GB de espaço em disco é recomendável para a instalação da biblioteca local.
Além disso, o VMM requer que o WinRM 1.1 seja instalado no servidor do VMM, em todos os hosts de máquina virtual e em quaisquer servidores de biblioteca que serão gerenciados pelo VMM. O WinRM é a implementação da Microsoft dos serviços da Web para o protocolo de gerenciamento (WS-Management). O WinRM é um protocolo amigável de firewall baseado em SOAP, que permite que hardware e software de diferentes fornecedores interoperem e gerenciem um ao outro. O VMM utiliza o WinRM para realizar ações entre o servidor do VMM, os hosts de máquina virtual e os servidores de biblioteca. Você pode baixar o WinRM 1.1 do go.microsoft.com/fwlink/?LinkId=103610.
Outros pré-requisitos para a instalação incluem o .NET Framework 2.0 e 3.0, Windows PowerShell 1.0 e o IIS para o portal de auto-atendimento. Todos os requisitos adicionais de software são verificados durante a instalação do software do VMM e são fornecidos vinculados para os instaladores apropriados. Se qualquer um desses requisitos não for atendido, a instalação não será realizada.
Quando você iniciar a instalação do VMM, receberá três opções no menu principal: o Virtual Machine Manager Server, o Console do Administrador e o Portal de Auto-atendimento. Instalaremos todos os três em uma única máquina, iniciando com o Servidor. Assim que o processo de instalação for iniciado, as primeiras telas verificarão os pré-requisitos do sistema; você deve garantir que todos sejam atendidos, a fim de permitir a continuação da instalação.
Depois que os pré-requisitos forem verificados, você deverá analisar as opções de instalação, em especial aquelas relacionadas ao banco de dados do SQL Server. Com o VMM, você poderá escolher uma instalação do SQL Server 2005 Express Edition ou usar um banco de dados existente do SQL Server 2005. Para esse exemplo, utilizaremos o SQL Server 2005 Express Edition.
Na próxima etapa do assistente de instalação do VMM, identifique a localização da biblioteca centralizada. Esse local pode ser um diretório local no servidor do VMM (e será criado um compartilhamento para esse diretório) ou poderá ser usado um compartilhamento de arquivo existente. O local padrão é C:\Documents and Settings\All Users\Shared Documents\Virtual Machine Manager Library Files.
As atribuições de porta são a próxima etapa. Nessa etapa, configure as portas usadas para a conexão do Console do Administrador para o serviço do servidor do VMM principal (porta 8100), a porta usada pelo WinRM para realizar as funções de gerenciamento (porta 80, a porta HTTP padrão) e a porta usada pelo BITS (Background Intelligent Transfer Service, serviço de transferência inteligente em segundo plano) para mover os arquivos para os hosts de máquina virtual (porta 443, a porta HTTPS padrão). Assim que todas as informações forem coletadas, uma tela de resumo será apresentada e a instalação do servidor poderá ser concluída.
Agora, vamos instalar o Console do Administrador. Os pré-requisitos do sistema são semelhantes ao do servidor do VMM, exigindo o .NET Framework 2.0 e 3.0, bem como o Windows PowerShell 1.0. A única opção de configuração é confirmar as portas de comunicação a serem utilizadas para conexão com o serviço de servidor do VMM principal. Essa porta deve ser 8100, como configurada na instalação do servidor do VMM. No final da instalação, você receberá a opção de criar um atalho de desktop para o Console do Administrador e abrir o console quando encerrar a instalação. Sugiro a seleção das duas opções. Na primeira vez que você abrir o Console do Administrador, serão solicitadas as informações de conexão do servidor. Com uma instalação de servidor único, você se conectará ao host local na porta 8100 e pressionará Enter para iniciar o console.
Finalmente, vamos instalar o portal de auto-atendimento nesse servidor. Os pré-requisitos para isso são o IIS, o .NET Framework 2.0 e 3.0, e o Windows PowerShell 1.0. Durante a instalação, as únicas opções de configuração são as que lidam com as portas usadas pelo portal de auto-atendimento. A primeira é a porta para conexão com o serviço principal do WMM, a porta 8100, que é a mesma do Console do Administrador. A segunda é a porta na qual o portal será executado. A porta padrão é a porta 80, mas em muitas configurações, essa porta já pode estar em uso. Se necessário, altere a porta para outra aberta, como a 81.
O instalador criará um site da Web denominado Portal de Auto-atendimento do Microsoft System Center Virtual Machine Manager 2007 e a configuração poderá ser alterada no Gerenciador do IIS. Veja uma dica para facilitar a instalação: acesse o Gerenciador do IIS e selecione as propriedades do Portal de Auto-atendimento do Microsoft System Center Virtual Machine Manager 2007. Verifique a configuração do ASP.NET para o site da Web e confirme se a versão do ASP.NET está definida como 2.0. O portal de auto-atendimento não funcionará com o ASP.NET definido como 1.1 e, dependendo da ordem de instalação das versões do .NET Framework e do IIS, essas configurações podem variar.
Assim que a instalação do IIS for concluída, você poderá abrir o site da Web acessando http://localhost:81 no Internet Explorer®. Se for solicitada autenticação ao abrir o site da Web, isso se deve às configurações de segurança do Internet Explorer. O portal de auto-atendimento deve ser executado no contexto de intranet no Internet Explorer; você pode precisar adicionar o servidor do VMM à lista de sites de intranet na sua configuração local. Assim que essas alterações forem concluídas, você estará pronto para criar e usar diretivas de auto-atendimento no VMM.

Recursos do Virtual Machine Manager
Embora haja muitos recursos interessantes no VMM, há dois que indiscutivelmente foram responsáveis por grande parte do interesse: os recursos de Physical-to-Virtual e Virtual-to-Virtual. Ambas as funções são compatíveis a partir do Console do Administrador. Como o Console do Administrador do VMM se baseia no Windows PowerShell, todos os comandos também podem ser executados por meio do próprio Windows PowerShell. Para os nossos objetivos, exploraremos o processo de P2V usando o Console do Administrador e o processo de V2V por meio do Windows PowerShell.

Conversão Physical-to-Virtual
Para realizar a conversão de P2V, usamos o Console do Administrador do VMM. Há vários requisitos para a máquina física que será convertida. Primeiramente, essa máquina deve ser um membro do atual domínio ou um domínio confiável. O VMM se conectará a essa máquina para instalar um agente de P2V e transferir as informações necessárias. Em segundo lugar, a máquina de origem deve estar executando um sistema operacional compatível. Os sistemas operacionais compatíveis para P2V são o Windows Server 2003, Windows 2000 Server e o Windows XP Professional. Se essa máquina de origem estiver executando o Windows Server 2003 ou o Windows XP, o VMM utilizará o VSS (Volume Shadow Copy Service, serviço de cópias de sombra de volume) para consolidar os discos rígidos e distribuir os dados em discos rígidos virtuais. Isso permite que a máquina seja convertida sem qualquer período de inatividade, de modo que você não precise programar um período de inatividade para o servidor criar apenas a imagem de P2V. Para Windows 2000, um disco de inicialização do Windows PE será criado para facilita a criação de imagens de P2V. Para esse exemplo, utilizaremos um destino do Windows Server 2003.
O processo de P2V será iniciado escolhendo a opção "Convert physical server" (Converter servidor físico), em Ações, na parte superior direita do Console do Administrador. Isso ativará o Assistente de P2V, mostrado na Figura 5. A primeira página será a etapa Select Source (Selecionar Origem), onde a máquina a ser convertida será identificada. Insira o nome DNS dessa máquina e as credenciais de domínio apropriadas para conexão e gerenciamento. A próxima etapa permitirá que você dê um nome à VM resultante.
Figura 5 A função de P2V do VMM é baseada em assistente e na IU do &#xA;Admin
Figura 5 A função de P2V do VMM é baseada em assistente e na IU do &#xA;Admin
O assistente iniciará então o processo de coleta de informações a partir da máquina de origem. Quando você clicar em Gather System Information (Coletar informações do sistema), o VMM instalará um agente de P2V que irá recuperar as informações necessárias sobre o sistema operacional da máquina de origem, disco rígido e adaptadores de rede. Clicar em Next (Avançar) passará para uma tela de validação, a fim de que você verifique se há problemas conhecidos que impedirão a conversão. Se houver, serão apresentadas as possíveis resoluções.
Assim que as informações de configuração forem recuperadas, você poderá selecionar as partições de disco rígido a serem convertidas. Por padrão, a partição de inicialização é selecionada e quaisquer outras partições presentes serão disponibilizadas. Você pode escolher quais partições serão mantidas como parte da conversão. A P2V é um processo de cópia inteligente; o que significa que ele combina somente os dados de partições especificadas, em oposição a uma transferência fixa de uma imagem e tamanho de um disco rígido inteiro.
Finalmente, o assistente progredirá para as etapas da implantação padrão do VMM, incluindo as configurações de início do Servidor Virtual e processo de Intelligent Placement descrito anteriormente. Quando o assistente for concluído, a janela Jobs (Trabalhos) será exibida, mostrando a você todo o processo e andamento da P2V.
Por padrão, as VMs recentemente convertidas não iniciarão automaticamente (elas são convertidas em um estado parado), tampouco o processo de P2V desligará ou alterará o status de execução da máquina de origem. Esse é um processo de P2V não destrutivo. Como a nova VM terá o mesmo nome de computador, endereço IP e até endereço MAC do servidor original, essa máquina deve ser desligada antes de a VM poder ser iniciada. Se você quiser que a máquina de origem seja desligada ou que a VM recentemente convertida inicie de forma automática, isso pode ser feito a partir da linha de comando do Windows PowerShell. Como parte do processo, é uma boa idéia executar a P2V e, em seguida, executar a VM resultante em um ambiente de teste, certificando-se de que tudo tenha sido convertido com êxito.

Conversão Virtual-to-Virtual
Para executar a V2V, você precisará de uma máquina virtual VMWare (na forma de um arquivo VMDK) e uma instalação válida de VMM com um host de máquina virtual de destino designado. O cmdlet new-v2v do Windows PowerShell de V2V do VMM oferece suporte aos quatro seguintes formatos de arquivo VMDK: monolithicSparse, monolithicFlat, twoGbMaxExtentSparse e twoGbMaxExtentFlat. A maioria dos arquivos VMDK existentes se encaixam em uma dessas categorias:
O processo de V2V funciona somente em arquivos VMDK offline. No entanto, o processo de P2V pode ser usado para converter máquinas virtuais VMware atualmente em execução. As máquinas virtuais VMware consistem em dois componentes principais – os arquivos VMDK que são os discos rígidos virtuais onde os dados são armazenados e um arquivo VMX que contém as informações de configuração da máquina virtual. Os arquivos VMDK e VMX associados podem ser posicionados em um local de biblioteca que lhe conceda uma forma de acessar e converter a máquina virtual VMware sem a necessidade de conceder acesso ao arquivo a partir do servidor de origem.
Durante o processo de V2V, o arquivo VMDK será convertido em um arquivo VHD, o sistema operacional convidado será limpo para funcionar com o Servidor Virtual e uma nova máquina virtual será criada, a fim de que corresponda ao máximo à configuração original, efetuando as alterações necessárias para o hardware virtual compatível com o Servidor Virtual. Observe que cada parte do processo de conversão pode ser gerenciada separadamente por meio do Windows PowerShell, o que permite conversões de formato em massa antes da alocação de hosts para as novas máquinas virtuais. Nesse exemplo, no entanto, desejamos converter e implantar o VHD.
Embora a V2V possa ser feita por meio do Console do Administrador e do Windows PowerShell, utilizaremos o Windows PowerShell para esse exemplo. Para iniciar o processo de V2V, vamos iniciar uma janela do Windows PowerShell com os cmdlets do VMM carregados. Isso pode ser feito clicando em Iniciar | Todos os Programas | Microsoft System Center | Virtual Machine Manager 2007 | Windows PowerShell – Virtual Machine Manager.
A janela resultante teria o título Windows PowerShell – Virtual Machine Manager. Caso não seja, os cmdlets do VMM não poderão ser carregados. Assim que o Windows PowerShell for aberto, você poderá verificar o comando new-v2v executando o seguinte:
get-help new-v2v –full | more
Isso fornecerá a sintaxe e os exemplos sobre como executar uma V2V. No exemplo fornecido para este artigo, o nosso servidor do VMM será chamado de vmmserver.contoso.com, o host da máquina virtual de destino será chamado de vshost1.contoso.com e o VMDK será disponibilizado a partir do servidor de biblioteca vmmserver.contoso.com.
Inicie identificando o contexto para o servidor do VMM que será utilizado para executar a V2V, usando o comando get-vmmserver. Como com todos os comandos do Windows PowerShell, o get-vmmserver seguirá o formato verbo-substantivo e utilizará traços para os parâmetros. A linha a seguir mostra o comando que utilizaremos para identificar o servidor do VMM:
get-vmmserver –computername "vmmserver.contoso.com"
Isso define o vmmserver.contoso.com como o contexto do servidor do VMM para os comandos a serem seguidos. O resultado do comando acima é uma lista detalhada das informações sobre o vmmserver.contoso.com. Se o comando ou a sintaxe estiverem incorretos, uma mensagem de erro em vermelho descreverá o problema.
A próxima etapa é identificar o host da máquina virtual de destino, o host do Servidor Virtual para o qual o VMDK/VHD convertido será atribuído. Agora, vamos atribuir o valor de host da máquina virtual à variável $vmhost, usando o seguinte comando no Windows PowerShell:
$vmhost = get-vmhost –computername
"vshost1.contoso.com"
Esse comando não produz comentários na janela de comando, mas você pode verificar facilmente se a variável está definida de modo correto ao simplesmente digitar $vmhost no prompt do Windows PowerShell e, em seguida, pressione Enter. Isso deve exibir as informações armazenadas em $vmhost (informações detalhadas sobre vshost1.contoso.com, semelhantes às informações que foram apresentadas para o servidor do VMM).
Além do host da máquina virtual, você precisará identificar o servidor de biblioteca no qual o arquivo VMDK está localizado. O comando é semelhante ao comando de host da máquina virtual utilizado previamente:
$library = get-libraryserver –computername
"vmmserver.contoso.com"
Com com o $vmhost, inserir $library na linha de comando exibirá as informações do servidor de biblioteca.
Finalmente, digite o comando para realizar a conversão de V2V. Para realizar isso, use o comando new-v2v com a função get-help. Nesse comando, continue e identifique o servidor da biblioteca para VMX/VMDK, o host de destino, o nome da VM resultante e o caminho para o arquivo VHD convertido.
Para a linha de comando, a maioria das referências são feitas a partir da perspectiva do host de destino, no nosso caso, o vshost1.contoso.com, com o caminho de instalação que é fornecido como uma referência local para VSHOST1. O caminho VMX origina-se a partir da perspectiva do servidor de biblioteca. A linha de comando resultante no Windows PowerShell é a seguinte:
new-v2v –LibraryServer $library –vmxpath
"\\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx"
–vmhost $vmhost -name "DemoV2V"
–path "C:\VHDs"
Como você pode ver, aqui estamos convertendo o VMX/VMDK em \\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx no servidor de biblioteca $library (VMMSERVER), implantando-o no host na variável $vmhost (VSHOST1), com o nome DemoV2V, no caminho C:\VHDs em VSHOST1.
Assim que o comando tiver sido executado, é sempre uma boa idéia voltar para a janela Jobs (Trabalhos) no Console do Administrador do VMM para visualizar o andamento. O VMX/VMDK será convertido e então copiado para VSHOST1, onde o VHD resultante será adicionado à lista de VMs como DemoV2V. Quando o processo for totalmente concluído, você poderá usar então a VMM para iniciar a nova máquina virtual e rever os resultados.

Conclusão
Como você pode ver, o System Center Virtual Machine Manager 2007 oferece alguns recursos novos e excelentes para a sua infra-estrutura virtual. Ao rever processos de P2V e V2V, espero ter mostrado o quanto eles são facilitados com o uso do Virtual Machine Manager.
O VMM foi desenvolvido para simplificar o trabalho de um administrador de TI no que diz respeito à criação, à implantação e à manutenção de VMs. Com o lançamento do System Center Virtual Machine Manager 2007, recomendo que os administradores do Virtual Server 2005 verifiquem como usar o Virtual Machine Manager para realizar a manutenção de seus hosts de máquina virtual. Para usuários da nova virtualização do Windows Server no Windows Server 2008, a Microsoft fornecerá suporte para a virtualização do Windows Server na próxima versão do System Center Virtual Machine Manager, que será disponibilizada depois do lançamento final da virtualização do Windows Server 2008.
Para obter informações adicionais sobre o VMM e baixar uma demonstração, visite microsoft.com/SCVMM. Para obter mais informações sobre todos os produtos de virtualização da Microsoft, acesse microsoft.com/virtualization.

Edwin Yuen é o Gerente técnico de produtos na divisão Windows Enterprise Management do System Center Virtual Machine Manager. Edwin ingressou na Microsoft com a aquisição em julho de 2006 da Softricity. Edwin também tem 13 anos de experiência em consultoria técnica em âmbito comercial e federal. Ele tem formação em engenharia elétrica pela Johns Hopkins University.
© 2007 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..


 System Center: Backups melhores com o Data Protection Manager 2007
System Center Calvin Keaton

Backups melhores com o Data Protection Manager 2007
Visão geral:
  • Deixando de lado os backups em fita
  • Proteção contínua de dados
  • Backups em disco
  • Controle mais granular com DPM

O mercado de proteção de dados experimentou recentemente um renascimento de classificações. Depois de anos de soluções de backup em fita e abordagens únicas para todas as necessidades para backup noturno, várias tecnologias e métodos novos
foram introduzidos em um período relativamente curto de tempo. Essas novas tecnologias incluíam o backup em disco, a CDP (Continuous Data Protection, proteção contínua de dados) e até mesmo algo aparentemente tão simples como a criptografia de dados. Algumas dessas novas abordagens se tornaram possíveis ou até mesmo necessárias por reduções recentes no preço do armazenamento em disco, por melhorias no desempenho de rede e processadores, bem como por novas exigências normativas.
A Microsoft tem uma longa história de fornecimento de soluções baseadas em plataformas e aplicativos nessa área, como as ferramentas de backup NTBackup, Exchange Server e SQL ServerTM, para mencionar apenas alguns exemplos.
O System Center Data Protection Manager (DPM) 2006 foi a primeira introdução de software autônomo da Microsoft no mercado de proteção de dados; ele foi um dos primeiros produtos a oferecer a proteção de dados em disco e permanece o único nesse sentido a ter sido desenvolvido desde o início considerando-se o backup em disco. A maioria das outras ofertas foram e continuam sendo abordagens em fita que foram retroajustadas para disco.
O DPM é uma parte da família de produtos do System Center. Os produtos System Center foram desenvolvidos para trabalharem juntos e tornarem o gerenciamento diário da sua infra-estrutura complexa de TI mais fácil e econômico. As soluções System Center se baseiam em automação e em práticas recomendadas derivadas do MOF (Microsoft® Operations Framework) e da Information Technology Infrastructure Library (ITIL) e podem ser usadas em todos os níveis de uma organização.
O DPM é apenas uma parte da família System Center. O System Center Configuration Manager fornece gerenciamento de configuração e fornecimento de software. O System Center Operations Manager oferece um sistema proativo de monitoramento e de automação. O System Center Capacity Planner pode ser usado para o planejamento de capacidade e para a análise de possibilidades das implantações de infra-estrutura. (Consulte microsoft.com/systemcenter para obter mais informações.)
O System Center Data Protection Manager 2006 fornecia backup em disco de servidores de arquivos e de impressão, bem como o backup em disco baseado em WAN para filiais. Ele foi desenvolvido para proteger servidores de arquivos no datacenter e remover hardware de backup de fita local da filial. Mas ele não oferecia suporte nativo para aplicativos Microsoft e dependia de produtos de terceiros para arquivamento a longo prazo em fita.
A nova versão do DPM, System Center Data Protection Manager 2007, foi desenvolvida com base nos mesmos princípios e continua fornecendo uma proteção robusta em disco para servidores de arquivos e de impressão, além de oferecer suporte aos aplicativos Microsoft de extrema importância para os negócios, como o Exchange, SQL Server e o SharePoint®, e suporte nativo para backups em fita. Embora não seja comum ver uma quantidade significativa de alterações em uma nova versão, isso é válido especialmente no caso do DPM. A segunda versão acrescentou vários novos recursos, bem como aprimoramentos significativos aos recursos existentes. Neste artigo, apresentarei vários desses recursos novos e aprimorados, bem como uma visão ampla do que você pode esperar dessa nova e interessante versão.

Suporte a aplicativos e plataformas
Muitos fornecedores de software de backup utilizam uma abordagem de “cobertura” de suporte a aplicativos. Eles distribuem seu investimento de engenharia em vários aplicativos na tentativa de oferecer suporte ao maior número de fontes de dados possíveis. O resultado é um suporte muito básico a um grande número de aplicativos. Em vez de tentar fornecer suporte limitado a uma ampla variedade de aplicativos ou plataformas, a Microsoft optou por se concentrar na proteção de alguns aplicativos muito específicos na plataforma Windows®. Isso nos permitiu focalizar o nosso investimento de engenharia nesses aplicativos, a fim de criar uma experiência integrada de backup e restauração, que inclui recursos não comumemente encontrados em outros produtos de backup.
O suporte do Microsoft Exchange foi a solicitação de recurso número um dos usuários do DPM 2006. Levando isso em consideração, o DPM 2007 apresenta suporte ao Exchange Server 2003 e ao Exchange Server 2007. A proteção ocorre no nível do grupo de armazenamento, com grupos de armazenamento individual aparecendo como objetos na IU do DPM, os quais podem então ser adicionados a grupos de proteção, conforme necessário, para habilitar a realização de backups programados e acionados por diretivas. Os grupos de armazenamento em cluster aparecem como um único objeto, eliminando a necessidade de controlar membros individuais de um cluster e sincronizar manualmente sua proteção. As restaurações podem ocorrer no nível de grupo de armazenamento, banco de dados ou caixa de correio. A recuperação granular é atingida por meio da automação, que usa ferramentas padrão do Exchange para restaurar os dados em um grupo de armazenamento e então extrair objetos mais granulares, como caixas de correio, novamente por meio das ferramentas padrão do Exchange (consulte a Figura 1).
Figura 1 Suporte ao Exchange no DPM
Figura 1 Suporte ao Exchange no DPM
Ao contrário de algumas outras soluções de backup do Exchange, o DPM não depende de ferramentas que não sejam do Exchange ou de engenharia reversa do banco de dados do Exchange quando extrai objetos que são restaurados depois. Portanto, as restaurações de caixas de correio no DPM são totalmente compatíveis com o Exchange.
O DPM 2007 é o primeiro produto a oferecer suporte total a clusters CCR (Cluster Continuous Replication, Replicação contínua em cluster) do Exchange 2007 e LCR (Local Continuous Replication, Replicação contínua local). Também é oferecido suporte aos clusters do Exchange 2003.
O SQL Server 2000 e o SQL Server 2005 são compatíveis com o DPM 2007, com o backup e a restauração ocorrendo no nível do banco de dados. Também está incluído suporte para restaurações redirecionadas e renomeadas, bem como suporte completo a bancos de dados em cluster, espelhados ou de envio de log.
Como no Exchange, os bancos de dados em cluster aparecem como um único objeto na IU, eliminando a necessidade de configurar a proteção separadamente em vários servidores em cluster (consulte a Figura 2). O suporte ao SQL Server no DPM pode ser usado para proteger vários aplicativos de terceiros que dependem dos bancos de dados de back-end do SQL Server, sendo o suporte para aplicativos por meio da proteção de arquivos, e o banco de dados SQL Server protegido nativamente por meio do suporte DPM para o SQL Server. O mecanismo de programação flexível no DPM permite que o backup de arquivos e do SQL Server sejam adicionados ao mesmo grupo de proteção, de modo que ocorram simultaneamente e compartilhem uma interface comum de programação e gerenciamento.
Figura 2 Backups em cluster
Figura 2 Backups em cluster
As cargas de trabalho de colaboração são protegidas com suporte ao SharePoint 2007, ao Windows SharePoint Services (WSS) 3.0 e ao Microsoft Office SharePoint Server (MOSS) 2007. O suporte ocorre no nível de farm, mesmo que esse farm se estenda a mais de um servidor. Portanto, por exemplo, um farm consistindo em três servidores de front-end da Web, dois servidores de coleta de site e um único servidor de banco de dados para um total de seis servidores apareceria como um único objeto na IU do DPM – seu backup seria realizado como um único objeto e ele poderia ser restaurado como um único objeto pelo DPM.
Apesar de haver suporte a restaurações completas de farm, o DPM também inclui suporte a restaurações de site, coleta de site e a documentos, listas ou itens individuais. As versões anteriores do SharePoint podem, é claro, ser protegidas como bancos de dados do SQL Server por meio dos recursos de proteção do SQL Server do DPM.
O suporte às cargas de trabalho de arquivos e impressão continua sendo oferecido no DPM 2007, com o suporte a arquivo aberto disponível sem custo adicional. Foi acrescentado o suporte para exclusões de arquivos e pastas, bem como o suporte de backup ao Estado do sistema. É importante salientar que o suporte a arquivo foi ampliado ainda mais para incluir o Windows Vista® e o Windows XP. Mas o suporte para esses sistemas operacionais clientes é relativamente limitado, pois é principalmente voltado para sistemas que são utilizados como servidores de arquivos. Os usuários do DPM têm permissão para proteger um pequeno número de clientes, conforme necessário, mas esse suporte não será facilmente ampliado para grandes quantidades de desktops.
O suporte nativo a Exchange Servers, SQL Server, servidores SharePoint e servidores de arquivos também permite que o DPM seja compatível com uma ampla maioria de cargas de trabalho encontradas em ambientes Windows. Porém, para cargas de trabalho menos comuns, o DPM 2007 também inclui suporte para pré e pós-scripts, os quais podem ser executados automaticamente quando ocorrer um backup. Essa funcionalidade permite que o DPM ofereça suporte a uma ampla variedade de outros aplicativos ou cargas de trabalho. Tal suporte não é integrado como o oferecido para Exchange, SQL Server e SharePoint, mas oferece flexibilidade significativa no suporte à fonte de dados. Os white papers com detalhes sobre o suporte de alguns produtos fundamentais que não são da Microsoft, como Oracle, serão disponibilizados no DPM TechCenter em technet.microsoft.com/dpm.
Uma das inovações mais interessantes no DPM 2007 é o suporte a servidor virtual baseado em host. Embora a maioria dos produtos de backup ofereça suporte a convidados de servidor virtual, como servidores individuais, poucos produtos, se houver, são capazes de fornecer tal proteção no nível de host por meio de uma única licença e instalação de agente. O DPM utiliza os criadores recursivos de VSS (Serviço de Cópias de Sombra de Volume) pra proteger todos os convidados hospedados em um determinado host de servidor virtual por meio de um único agente implantado no host. Esses criadores recursivos de VSS podem chamar criadores de VSS que residem em convidados, ou até mesmo em aplicativos executados em convidados, qualquer que seja o aplicativo ou sistema operacional instalado no convidado. Isso permite que o DPM proteja qualquer plataforma ou aplicativo executado como convidado, independentemente do fornecedor. Tais backups de servidor virtual baseado em host são consistentes com aplicativos e resultam em uma única imagem de VHD (Virtual Hard Disk, disco rígido virtual), que pode ser armazenada em um host novo ou existente, conforme necessário.
Essas imagens de backup baseadas em host não oferecem a mesma granularidade de restauração que os backups feitos por meio de um agente do DPM instalado no convidado ou em um servidor autônomo, mas oferecem outros pontos positivos, incluindo a fácil recuperação do sistema para ambientes virtualizados.

Velocidade, confiabilidade e eficiência
Além das melhorias na profundidade e na extensão do suporte a aplicativos, em comparação à versão anterior, o DPM 2007 permite maior granularidade de backups completos e incrementais. Ao passo que o DPM 2006 permitia que você sincronizasse a cada hora, a nova versão do DPM permite que você faça um backup incremental a cada 15 minutos e um backup completo a cada hora. Para clientes com SLAs (service level agreements, contratos de nível de serviço) menos agressivos, podem ser necessários backups completos uma vez por semana. Portanto, esses clientes podem reduzir a freqüência de backups em servidores menos críticos, permitindo ainda programações de proteção agressivas para servidores críticos. Mesmo que a sincronização com o servidor DPM ocorra a cada 15 minutos, o agente do DPM ainda controlará ativamente as alterações no servidor protegido durante o intervalo entre as sincronizações.
Esse novo agente do DPM controla continuamente alterações no nível de bloco à medida que elas ocorrem em um servidor protegido. Isso se tornou possível graças a um filtro de volume totalmente novo, desenvolvido para o DPM 2007, que consiste em um bitmap que reside na memória de pool paginado e inclui uma parte de cada bloco no volume protegido.
Sempre que um bloco é gravado no volume, uma parte é invertida no bitmap. O impacto na memória e no processador associado a esse processo é menor do que em um filtro característico de antivírus, e não há exigência de espaço em disco que seja dimensionado com a taxa de alteração. Na verdade, a carga associada a esse filtro não é dimensionada de forma alguma com a taxa de alteração. Isso é muito importante, pois a maioria dos esquemas de controle de alterações no nível de bloco geralmente resulta em uma alta sobrecarga de memória e do processador, bem como uma impressão digital de disco que é dimensionada com a taxa de alteração. Portanto, taxas ainda maiores de alteração tendem a ter um impacto maior e, em alguns casos, taxas muito elevadas podem resultar na falta de espaço em disco do sistema. Com o DPM 2007, o impacto do filtro de volume no processador, na memória e no disco é o mesmo, independentemente da taxa de alteração. Seja 1% ou 1.000%, a taxa de alteração simplesmente não terá impacto na baixa sobrecarga associada ao filtro.
No entanto, o controle dos dados alterados é somente uma parte da história. O DPM 2007 também aproveita o serviço VSS no servidor protegido para criar imagens de backup consistentes com os aplicativos, que possam ser recuperadas com confiabilidade. O VSS foi desenvolvido pela Microsoft para fornecer infra-estrutura de backup para Windows XP e Windows Server® 2003, bem como para atuar como um mecanismo para a criação de cópias instantâneas de dados consistentes (cópias de sombra). O VSS pode produzir cópias de sombra consistentes ao coordenar leituras e gravações com aplicativos comerciais, serviços do sistema de arquivos, aplicativos de backup, soluções de rápida recuperação e hardware de armazenamento. Conseqüentemente, o VSS é indiscutivelmente o mecanismo mais consistente e confiável para a produção de backups consistentes de aplicativos no mercado atual. Vários recursos no Windows Server 2003 usam o VSS, incluindo cópias de sombra para pastas compartilhadas.
A maioria dos produtos que usam o VSS para backups de aplicativos criam uma réplica do VSS e a deixam no servidor protegido, a fim de controlar as alterações e obter uma imagem consistente com os aplicativos para backup. Infelizmente, manter a réplica no servidor protegido todas as vezes apresenta algumas implicações significativas de desempenho, uma vez que a cópia da gravação mantém a réplica do VSS atualizada sempre que o aplicativo gravar no disco. Isso pode criar uma sobrecarga de até 25% no processador e tem um impacto significativo nos tempos de gravação.
Como o DPM controla as alterações por meio de seu filtro de volume, ele não precisa manter uma réplica do VSS durante todo o tempo. Em vez disso, o DPM cria uma réplica do VSS quando ocorrer o backup completo, sobrepondo então o bitmap do filtro de volume para identificar somente os dados alterados na réplica. Esses dados alterados são movidos para o servidor DPM, que é usado para criar um ponto de recuperação. A réplica do VSS no servidor protegido é então detectada e o filtro de volume é redefinido. O controle das alterações no nível de bloco continua com pouca sobrecarga e não há necessidade de uma réplica do VSS ou uso de recursos associados.
Essa solução garante que os pontos de recuperação resultem em uma imagem de aplicativo restaurável e reduz a quantidade de dados movidos entre o servidor protegido e o servidor DPM.
Com o DPM 2007, um backup completo não moverá uma cópia total dos dados do servidor protegido para o servidor do DPM. Em vez disso, ele moverá somente os dados alterados. Portanto, um backup diário completo de um grupo de armazenamento do Exchange de 100 GB com uma taxa de alteração de 10% por dia seria apenas de 10 GB.
Essa redução no tamanho dos backups completos representa um armazenamento muito eficiente no servidor do DPM quando é criado um instantâneo para capturar um ponto de recuperação. Cada instantâneo consiste em dados alterados que foram feitos no último backup completo e ocorre automaticamente quando um backup completo é realizado. Ao lidar com aplicativos, esses instantâneos também incluem quaisquer backups incrementais intermediários que tenham ocorrido.
Os backups incrementais são basicamente backups de log no DPM, de modo que sempre que você realizar um backup completo de um aplicativo, os dados alterados serão movidos para o servidor do DPM e agrupados com quaisquer backups de log intermediários, a fim de criar um único instantâneo que tenha vários pontos de recuperação. No caso de um grupo de armazenamento do Exchange de 100 GB com uma taxa de alteração diária de 10% descrita anteriormente, se supormos um backup completo diário e incrementos a cada 15 minutos, um instantâneo incluiria 10 GB de dados alterados e aproximadamente 5 a 10 GB de logs de aplicativo. Mas é importante perceber que esse instantâneo de 15 a 20 GB teria até 97 pontos de recuperação!
Os backups completos devem ocorrer pelo menos uma vez por semana, e o número total de instantâneos está limitado a 512 para servidores de aplicativos e a 64 para servidores de arquivos. Portanto, a execução semanal de backups completos e incrementais a cada 15 minutos resultaria em 673 pontos de recuperação por instantâneo e mais de 340 mil pontos de recuperação se todos os 512 instantâneos fossem usados. Embora seja improvável que alguém tenha a necessidade de tantos pontos de recuperação em disco, isso demonstra a flexibilidade e a escalabilidade do DPM em relação à programação de trabalhos e à recuperação imediata.
A inclusão de backups de log com backups completos permite que o DPM armazene com eficiência um grande número de pontos de recuperação em uma quantidade muito pequena de espaço em disco. Mas há alguma sobrecarga associada a esse processo que, tecnicamente, não é uma compactação ou até mesmo um SIS (single instance storage, armazenamento de instância única), apesar de existirem alguns componentes de deduplicação de dados, ou seja, controle de alteração no nível de bloco. Qualquer que seja o rótulo, o DPM faz um excelente trabalho ao usar uma pequena quantidade de armazenamento de cada ponto de recuperação criado. E, mais importante, como o DPM não utiliza a compactação tradicional, o armazenamento de instância única, nem a deduplicação para realizar essa tarefa, há lugar para outros métodos eficientes caso uma plataforma de armazenamento de compactação, SIS ou deduplicação seja usada para fornecer armazenamento ao servidor do DPM.

Recuperação sem perda de dados e CDP
Talvez uma das alterações mais importantes no DPM 2007 seja sua capacidade de realizar recuperações sem perdas de aplicativos Microsoft. Isso se tornou possível graças ao controle de alterações no nível de bloco e à arquitetura VSS, bem como à profunda integração com os logs de aplicativos existentes no servidor protegido.
Em termos gerais, há duas abordagens para a proteção e a recuperação de dados no mercado atual:
Soluções baseadas em replicação Isso é o que a maioria dos clientes tradicionalmente considera como CDP (Continuous Data Protection, proteção contínua de dados). A proteção de dados baseada na replicação envolve transferir as alterações no servidor protegido para o servidor de backup à medida que elas ocorrem. Essa é uma solução em disco com a finalidade de permitir a recuperação em qualquer momento sem perda de dados.
Embora interessante, há algumas desvantagens reais associadas a essa abordagem. Antes de tudo, uma solução de replicação não tem conceito de estado de aplicativo, nem reconhece as partes transferidas em um aplicativo. Portanto, ela não libera buffers nem a conta de dados que pode estar na memória, ou em progresso, quando o backup estiver ocorrendo. Isso significa que os pontos de recuperação baseados na replicação são freqüentemente inconsistentes com os aplicativos. Você pode realizar uma recuperação, mas o aplicativo não retorna de fato para um estado utilizável. Esse problema é tão predominante que alguns fornecedores de CPD baseada em replicação têm observações em suas documentações, para informá-lo que você deve tentar outro ponto de recuperação para um aplicativo se o atual não funcionar.
Além desses problemas de consistência de aplicativos, as soluções de CDP baseadas em replicação são geralmente muito caras, têm significativa sobrecarga de rede e processador e requerem quantidades razoavelmente grandes de armazenamento, que podem muito provavelmente estar localizadas no hardware do proprietário. As soluções de proteção de dados baseadas em replicação também não são especialmente adequadas para arquivamento ou backups de fita externos, pois ambos são uma exigência de muitos clientes.
Soluções baseadas em instantâneos Essa é uma abordagem de backup de fita tradicional para a proteção de dados na qual os instantâneos imediatos são criados em mídia externa que pode ser usada para recuperações imediatas. O RPO (recovery point objective, objetivo do ponto de recuperação) é determinado pela freqüência de instantâneos, de modo que um backup diário resultará em 24 horas de perda de dados. A vantagem de instantâneos é que eles são baratos, fáceis de gerenciar, têm um impacto mais limitado na rede e são adequados para o arquivamento em disco ou fita. Eles também tendem a resultar em imagens consistentes com aplicativos, pois você tem tempo de preparar o aplicativo antes que o instantâneo ocorra, de modo que haverá menos riscos que quaisquer partes transferidas do aplicativo sejam perdidas quando ocorrer o backup.
Uma tendência recente em instantâneos são as soluções “próximas” à CDP. Elas são soluções de instantâneos nas quais a freqüência de instantâneos é aumentada, de modo que o RPO pode ser tornar muito baixo. Alguns produtos agora medem o RPO em minutos e utilizam totalmente tais instantâneos freqüentes que tenham sido liberados próximos ao identificador da CDF, atualmente denominados produtos da CDP. No entanto, eles ainda perdem alguns minutos válidos de dados no caso de uma restauração.
O DPM 2006 certamente se aproximava à CDP em termos de instantâneo, mas o DPM 2007 tem uma abordagem exclusiva em relação à CDP. A nova versão do DPM realiza instantâneos a cada 15 minutos usando o VSS e sua tecnologia de controle de alterações no nível de bloco para mover somente os dados alterados do instantâneo do VSS no servidor protegido. Portanto, os instantâneos imediatos individuais são muito pequenos, pois consistem somente em alterações no nível de bloco. Essa é essencialmente uma abordagem muito avançada de instantâneos. A inovação no DPM é a integração profunda de aplicativos para Exchange, SQL e SharePoint. É tão profunda que o DPM reconhece os logs de aplicativos e pode encaminhá-los no caso de uma recuperação. Desde que seus logs de aplicativos estejam disponíveis (eles estarão caso você tenha seguido as práticas recomendadas e os salvo em uma unidade separada), o DPM poderá encaminhá-los a partir do último instantâneo imediato para uma recuperação sem perda (consulte a Figura 3).
Figura 3 Opções de recuperação no console do administrador do gerenciador de proteção de dados
Figura 3 Opções de recuperação no console do administrador do gerenciador de proteção de dados
De várias maneiras, essa abordagem híbrida à CDP é a melhor de todas. Ela oferece a consistência de aplicativos e o suporte a arquivamento de longo prazo da solução de instantâneo, com os recursos sem perda de dados de um produto de replicação, evitando, ao mesmo tempo, muitas das desvantagens dessas soluções.

Suporte para backups em disco e fita
Nenhuma discussão sobre os novos recursos do DPM 2007 seria completa sem mencionar o acréscimo do suporte de fita ao produto. O DPM 2006 era compatível somente com backups D2D (Disk-to-Disk, disco para disco), com os dados sendo transferidos do disco no servidor protegido para o disco no servidor do DPM. O DPM 2007 inclui suporte à mídia de fita e disco. Portanto, os dados podem ser transferidos do disco no servidor protegido para o disco conectado ao servidor do DPM (D2D) e para a fita conectada ao servidor do DPM (D2T), ou os dados protegidos podem ser implantados no disco no servidor do DPM antes de serem transferidos para a retenção em fita a longo prazo (D2D2T).
O DPM 2007 é compatível com uma ampla variedade de bibliotecas de fitas e autocarregadores, bem como uma ampla variedade de diferentes tipos de mídia de fita.
O suporte à fita no DPM inclui muitos recursos avançados, como criptografia de mídia de fita baseada em software sem custos adicionais, gerenciamento básico de chaves de criptografia, bem como retenção de fita e controle de localização.

Conclusão
Detalhei vários dos novos recursos e melhorias encontrados no System Center Data Protection Manager 2007. Esses recursos foram desenvolvidos para fornecer uma proteção de dados consistente, confiável e facilmente gerenciada para plataformas e aplicativos Microsoft, definindo um novo padrão na proteção de dados de aplicativos e plataformas Windows.
Além dos recursos descritos neste artigo, há muitos outros aperfeiçoamentos no produto, como a recuperação de usuário final integrada com o Windows, a otimização de largura de banda flexível e uma interface da linha de comando avançada. Recomendo que você baixe a versão Beta 2 do Data Protection Manager 2007 para verificar esses e outros recursos. Para obter mais informações e uma visão geral de todos os produtos da família System Center, visite microsoft.com/systemcenter. A partir desse site, você poderá navegar para qualquer solução da família System Center, incluindo o Data Protection Manager.

Calvin Keaton é atualmente o planejador de produto do DPM. Anteriormente, ele gerenciava o serviço de proteção de dados de TI da Microsoft. Calvin trabalhou por seis anos no setor de operações de datacenter e hardware antes de ingressar na Microsoft, inclusive com o gerenciamento de equipes de operações de dados de data center para a Compaq e, posteriormente, para a HP Services.


 System Center: Servi&#231;os online ajudam a simplificar o invent&#225;rio de software
System Center Paul Bourgeau

Serviços online ajudam a simplificar o inventário de software
Visão geral:
  • Noções básicas dos serviços online
  • Como configurar o agente de inventário
  • Como obter relatórios de inventário

O seu diretor financeiro acabou lhe enviar um email solicitando um "favorzinho": ele precisa de um inventário completo de todos os computadores da empresa, onde eles estão localizados e quais programas estão instalados em cada
máquina. Até o final da semana. Ele precisa disso porque (escolha uma ou mais opções):
  • É necessário planejar o orçamento para o próximo ano e ele deseja saber quanto alocar para licenciamento de software.
  • Ele recebeu uma notificação de uma auditoria de software e agora precisa demonstrar que a sua organização tem licenças suficientes de um determinado produto em conformidade.
  • O CEO solicitou a redução de despesas operacionais de TI e ele considera que a padronização de aplicativos é uma forma de fazer isso.
Então, o que fazer?
O gerenciamento de ativos de TI evoluiu na última década, e agora as organizações mudaram o foco para o gerenciamento eficaz de seus ativos de software. Isso se deve principalmente ao fato de agora o software representar um investimento financeiro significativamente maior do que antes, mas há também cada vez mais problemas jurídicos, de segurança e de diretivas exigindo atenção. A possibilidade de se encontrar em uma situação de não conformidade e enfrentar taxas ou multas verdadeiramente altas reforçou ainda mais a necessidade de um gerenciamento de ativo de software preciso.
As organizações de grande porte geralmente têm recursos e ferramentas para o gerenciamento de software. Essas ferramentas são freqüentemente soluções para várias finalidades em larga escala, desde o controle do inventário de hardware e software, até o gerencimento do fornecimento de software para desktop e monitoramento do desempenho, além de outras funções operacionais. Como ficam as organizações quando tais soluções não são viáveis ou quando não há recursos e conhecimento para implementar e gerenciar essas soluções complexas?
Atender às necessidades dos negócios, sejam de pequeno ou grande porte, é um dos fatores que impulsiona o conceito de software como um serviço (SaaS, software as a service). A estratégia "Software mais Serviços" da Microsoft acompanha os esforços para desenvolver soluções baseadas em serviços, a fim de auxiliar os clientes a gerenciar os ativos de software com eficiência. Um dos primeiros desses serviços, o Microsoft® Asset Inventory Service, será lançado para clientes do Software Assurance, como parte do Desktop Optimization Pack for Software Assurance posteriormente neste ano.
O Asset Inventory Service (AIS), mostrado na Figura 1, fornece um serviço hospedado fácil de implementar e de usar para a coleta de informações sobre os softwares instalados nos computadores em toda a organização. É possível acessar essas informações por meio de relatórios baseados em navegadores, e há planos para uma versão futura do serviço, a fim de analisar também a implantação de contratos de licenciamento por volume da Microsoft.
Figura 1 Microsoft Asset Inventory Service
Figura 1 Microsoft Asset Inventory Service

A natureza dos serviços online
Por que adotar uma solução online? Há vários motivos atraentes, entre eles: a disponibilidade imediata de atualizações e novas versões, a facilidade de adoção e os custos reduzidos de implantação e gerenciamento.
Os serviços online são dinâmicos: como uma página da Web, o conteúdo e a funcionalidade podem ser constantemente atualizados pelo provedor de serviço, a fim de aprimorar a experiência do usuário e fornecer respostas atuais para alterações no cenário tecnológico. Isso fornece um nível inigualável de agilidade e permite que os fornecedores de software disponibilizem recursos, soluções e conhecimentos extremamente atualizados, permitindo que os administradores sejam mais pró-ativos no gerenciamento de seus desktops.
Os serviços online têm a vantagem de serem onipresentes. Nos atuais ambientes de TI, você encontrará diversas situações, desde PCs totalmente em rede conectados diretamente aos recursos de rede, a usuários remotos e filiais que acessam recursos pela Internet de vários locais. Isso inclui usuários móveis que raramente se conectam à sua rede, exceto por programas de webmail, tornando muito difícil atingir um inventário completo de seus ativos de TI. Historicamente, esse tem sido um importante desafio para ferramentas de inventário, em especial para as soluções no local que não fornecem suporte a cenários remotos/que não estejam em rede.
No entanto, a maioria, se não todos os seus PCs, têm conectividade com a Internet, de modo que você pode usar um serviço online para gerenciá-los sem implementar medidas especiais a fim de garantir a conectividade com soluções de servidor cliente internas. O acesso ao serviço para realizar as funções de gerenciamento também é possível por meio de uma conexão segura com a Internet, de modo que você pode gerenciar qualquer PC em sua conta gerenciada de qualquer lugar em que a Internet esteja acessível.
A implantação é fácil e, para iniciar, você somente precisará criar sua conta com o sistema online. Não há servidores no seu ambiente para os quais seja necessário suporte, nem nova infra-estrutura de rede e novas plataformas de software nas quais investir. Tudo isso significa menos investimento em administração e finanças. O suporte contínuo também é mais fácil, pois a organização não precisa se preocupar em manter um caminho de atualização, visto que o serviço freqüentemente inclui as versões mais recentes como parte do contrato.

Como usar o serviço
Como estimular uma comunidade online
O Asset Inventory Service e o serviço System Center Online estão promovendo o desenvolvimento de uma forte comunidade de usuários que poderá influenciar a evolução dos serviços online. O catálogo de software é um excelente exemplo de algo que a comunidade de usuários pode fornecer comentários (no verdadeiro estilo wiki), e os usuários do serviço podem fornecer sugestões, correções e orientações.
No futuro, o próprio catálogo também poderá ser uma fonte valiosa de informações para usuários finais, quando estiverem pesquisando possíveis compras de software. Estatísticas anônimas agregadas podem ser coletadas em todo o serviço, a fim de determinar as taxas de adoção de produtos de software e hardware, fornecendo dados úteis para os usuários finais envolvidos nessas atividades.
A comunidade também orientará a direção geral do serviço ao contribuir com comentários sobre quais áreas devem ser priorizadas a fim de atender a necessidades comerciais específicas.

Para fornecer os serviços de gerenciamento de desktop online, o Microsoft System Center Online está desenvolvendo uma plataforma que, em curto prazo, será compatível com o Asset Inventory Service e também com futuros serviços. O serviço foi desenvolvido considerando-se sua segurança, escalabilidade e confiabilidade. O AIS é uma solução completamente hospedada, com todos os servidores localizados em datacenters da Microsoft. Para implantar a solução, os clientes devem instalar uma pequena parte do software em cada PC cliente que eles desejarem incluir em seu inventário gerenciado.
O Asset Inventory Service é gerenciado pela mesma equipe que gerencia o Microsoft.com. Ele é um aplicativo Web de vários inquilinos que usa serviços da Web para garantir a privacidade e a segurança dos dados de cada cliente, além de usar uma combinação de aplicativos Web para armazenar dados. Os agentes em execução no site do cliente carregam o inventário de software em um serviço Web do Microsoft IIS. A SSL mutuamente autenticada protege os dados do cliente, a comunicação entre o cliente e o serviço, bem como o site da Web do AIS e o site que usa o SQL Server™ para armazenamento.
Usando contas do Windows Live™ ID para a autenticação, os clientes acessam o serviço para gerenciar suas contas e visualizar relatórios. O site da Web do cliente também utiliza SSL para proteger os dados do cliente, e os SQL Server Reporting Services geram relatórios. Os bancos de dados do SQL Server são espelhados e os sites da Web têm balanceamento de carga para alta disponibilidade. Além disso, os dados do inventário são particionados em unidades de escala para alta disponibilidade.
Inscreva-se no Asset Inventory Service comprando licenças do Microsoft Desktop Optimization Pack no seu Contrato de licenciamento por volume da Microsoft. Então, você poderá ativar a assinatura do Asset Inventory Service no site de serviços de Licenciamento por volume da Microsoft, licensing.microsoft.com. Para realizar a autenticação e acessar com êxito o serviço AIS, você deve ter uma Windows Live ID válida.
Durante a ativação, o administrador do contrato atribui um administrador de assinatura do Asset Inventory Service especificando sua Windows Live ID. O administrador da assinatura acessará o AIS com sua Windows Live ID e concluirá o processo de ativação do AIS. Ele poderá então adicionar subseqüentemente outros usuários ao serviço, especificando suas Windows Live IDs.

Agente de inventário
O cliente instalado em cada PC é um agente pequeno e fácil de implantar, empacotado como um Windows® Installer (MSI). Você pode baixar o instalador do agente e gerenciar a implantação cliente a partir do serviço online. (A Figura 2 mostra a interface de gerenciamento e de suporte.) O agente opera de maneira semelhante ao agente do Windows Update porque se comunica regularmente com os servidores do System Center Online. O objetivo é atualizar seu perfil de inventário com base em uma freqüência predefinida e auto-atualizar automaticamente se houver uma versão mais recente do agente disponível.
Figura 2 Implantação de cliente e gerenciamento de conta
Figura 2 Implantação de cliente e gerenciamento de conta
O inventário está programado para execução automática e não requer intervenção do usuário. Há também uma opção para iniciar um inventário manual, se necessário. Na primeira vez que um agente entrar em contato com o serviço, ele utilizará as credenciais de certificado de infra-estrutura de chave pública (PKI, public key infrastructure) para apresentar a identidade do cliente ao serviço e, dessa forma, gerar uma identidade exclusiva para o computador no qual o agente está sendo executado. O próprio agente, que é executado somente conforme a programação, foi desenvolvido para não ser inconveniente para o usuário, de modo que utiliza recursos mínimos e é executado em segundo plano. Os arquivos de dados carregados são pequenos, de forma a não causar picos de tráfego de rede.
O processo de inventário por si só é rápido e eficiente. O agente verifica as entradas do Registro, o banco de dados do MSI e outras fontes para obter as informações de instalação, ao contrário dos sistemas de gerenciamento tradicional que atrapalham a produtividade dos usuários ao verificar e resolver todos os executáveis presentes em uma máquina. Esse processo retorna os dados de inventário de software usando nomes amigáveis com metadados que auxiliam na identificação e na classificação dos itens, de modo que podem ser usados em um amplo conjunto de atividades de gerenciamento de ativos de software.

Reporting Services
Assim que os dados de inventário forem carregados, eles serão submetidos a um processo de identificação e catalogação que irá prepará-los para exibição nos relatórios. Os dados de inventário serão comparados a um catálogo de software central, onde serão divididos por categorias. Esse é um dos recursos importantes do serviço: todos os dados do inventário de software do cliente contribuem com assinaturas exclusivas em um catálogo de software central. Uma equipe de pesquisadores da Microsoft avaliará as assinaturas de software não classificadas e não particulares e, usando uma sistemática estruturada de famílias e categorias de software, classificará os aplicativos que eles representam, de acordo com a natureza e a função dos aplicativos. Essas categorias auxiliam no fornecimento de um nível superior de inteligência ao relatório, permitindo que os usuários se concentrem rapidamente em tipos específicos de software nos quais estão interessados – por exemplo, talvez você esteja interessado apenas em aplicativos antivírus.
As assinaturas de software também servem para consolidar os dados sendo exibidos nos relatórios. Por exemplo, um nome de editor pode ter diversas variações – um aplicativo pode relatar o nome do editor como Contoso Software, enquanto outro pode relatar Contoso, o que os exibiria como aplicativos diferentes em um relatório. Ao consolidar os nomes do editor e do aplicativo, a capacidade de relatar com precisão esses critérios e apresentar dados de forma significativa é aprimorada.
Assim que o usuário tiver atingido o conjunto de dados desejado ao aplicar filtros e agrupamentos, o conteúdo do relatório pode ser exportado em uma variedade de formatos compatíveis, por meio do uso do SQL Server Reporting Services, incluindo arquivos CSV, documentos do Microsoft Word, planilhas do Microsoft Excel® e arquivos PDF (consulte a Figura 3). Isso permite que você realize uma análise e manipulação externas, ou atue como uma fonte de informação para outros sistemas corporativos de gerenciamento.
Figura 3 Resultados do inventário do relatório
Figura 3 Resultados do inventário do relatório
Um recurso que será disponibilizado em breve no serviço irá aprimorar o modo como são gerenciadas as licenças da Microsoft, facilitando muito o processo para os usuários. Os usuários poderão carregar seus pares de contrato de licenciamento por volume, os quais serão então utilizados para recuperar suas informações de posição de licença a partir do Microsoft Customer License Position Repository. Esses dados de autorização de licenças preencherão então uma declaração que resumirá todos os aplicativos Microsoft licenciados a serem instalados e as quantidades de licenças correspondentes.
Usando o Identificador do produto que também é coletado durante o inventário, o software instalado pode será ser dividido por canal: Licença por volume, Varejo e OEM. Esse recusro deve ser lançado na próxima versão do Asset Inventory Service.

Seguindo adiante
O Asset Inventory Service é a oferta inicial do System Center Online, mas de forma alguma será a última. Como mencionado anteriormente, o System Center Online tem o objetivo a longo prazo de fornecer serviços de gerenciamento completos de desktop, completamente disponibilizados como serviços online.
Algumas das possíveis ofertas em consideração incluem o gerenciamento de ativos de TI para inventário e controle de hardware e software, distribuição e atualização de software, fornecendo funcionalidade semelhante aos Windows Software Update Services da Internet, e serviços híbridos no local/online. Vários outros serviços de desktop também estão sendo investigados, a fim de detectar se eles funcionariam nesse tipo de cenário.
Para saber mais sobre o Microsoft Asset Inventory Service, acesse microsoft.com/windows/products/windowsvista/enterprise/ais.mspx.

Paul Bourgeau , Gerente de programa na equipe do System Center, ingressou na Microsoft com a aquisição da Assetmetrix.


 Diretiva de Grupo: Conhecendo os modelos ADM e ADMX para Diretiva de Grupo
Diretiva de Grupo Jeremy Moskowitz

Conhecendo os modelos ADM e ADMX para Diretiva de Grupo
Visão geral:
  • Tipos de modelos de diretiva de grupo
  • Chaves Policies próprias e impróprias
  • Exibindo modelos ADM
  • Convertendo ADM em ADMX

Arquivos ADM. Ame-os ou odeie-os. Ou ambos, talvez. Isso porque eles são, ao mesmo tempo, necessários e confusos. E agora existem os arquivos ADMX, um novo formato que, aparentemente, só aumenta a confusão. Bom, é hora de lançarmos uma luz sobre esse assunto nebuloso.

Por que preciso de arquivos ADM?
A Diretiva de Grupo abrange uma ampla variedade de áreas. Se você se aprofundar no Editor de Objeto de Diretiva de Grupo (GPOE), descobrirá um monte de "coisas" diferentes que pode fazer com a Diretiva de Grupo. Por exemplo, você encontrará Política de Restrição de Software, Instalação de Software de Diretiva de Grupo, Redirecionamento de Pasta e, sim, a que mais utilizamos: Modelos Administrativos. O nó Modelos Administrativos aparece tanto no lado do Computador como no do Usuário. Como esperado, os usuários só podem adotar configurações de diretiva do lado do Usuário, e computadores só podem adotar configurações de diretiva do lado do Computador.
Mas de onde vêm todas essas configurações mágicas dentro de Modelos Administrativos? Quando novos aplicativos "nascem", há algumas configurações que podem ser manipuladas. É aqui que entram os arquivos ADM. Eles descrevem as áreas do aplicativo que estão prontas para aceitar configurações definidas por um administrador. Infelizmente, os arquivos ADM são limitados de imediato, pois só podem resolver configurações do Registro dentro de um aplicativo. Mas um aplicativo pode salvar suas configurações em outras áreas, como arquivos .ini, .js e .xml e bancos de dados.

Arquivos ADM prontos para usar
Então como fazer todas essas configurações prontas para usar referentes a Configuração do Computador | Modelos Administrativos e Configuração do Usuário | Modelos Administrativos chegarem lá em primeiro lugar? Se você clicar com o botão direito do mouse nas palavras "Modelos Administrativos" no GPOE e selecionar "Adicionar/Remover Modelos" no lado do Usuário ou do Computador, verá os modelos padrão que formam a configuração padrão na Figura 1.
Figura 1 Modelos Administrativos padrão
Figura 1 Modelos Administrativos padrão
A divisão desses arquivos é:
  • Conf.adm – Configurações do NetMeeting®.
  • Inetres.adm – Configurações do Internet Explorer®, como conexões, barras de ferramentas e configurações de barras de ferramentas. São equivalentes às opções disponibilizadas quando você clica no menu Opções da Internet dentro do Internet Explorer.
  • System.adm – Configurações e alterações do sistema operacional. A maioria das configurações de Modelos Administrativos de Computador e de Usuário estão neste modelo AMD.
  • Wmplayer.adm – Configurações do Windows Media® Player 9.
  • Wuau.adm – Controla o acesso dos clientes ao Windows® Update e/ou a servidores do Windows Server® Update Services.

Adicionando um novo arquivo ADM de modelo
Superando limitações com ferramentas da Microsoft e de terceiros
Os arquivos ADM e ADMX são extremamente úteis. Use-os para acumular conhecimento no arquivo de definição e controlar o aplicativo de destino. Mas os arquivos ADM e ADMX têm limitações. Especificamente:
  • Eles não podem alcançar hives do Registro diferentes de HKEY_LOCAL_MACHINE e HKEY_Current_User. Se você tiver negócios em outros hives do Registro, não poderá resolvê-los com arquivos ADM ou ADMX.
  • Eles não podem realizar adições em valores REG_Binary.
  • Eles não podem ser definidos especificamente para "executar apenas uma vez".
  • Eles não podem ser definidos especificamente para "reaplicar sempre" durante uma atualização da Diretiva de Grupo.
  • Arquivos ADM e ADMX gravados em chaves impróprias tatuam o Registro, por isso o valor persistirá mesmo que o usuário saia do escopo de gerenciamento (SOM) ou o GPO seja excluído.
A Microsoft e alguns terceiros oferecem algumas soluções para ajudá-lo a superar essas limitações. A Microsoft adquiriu recentemente a DesktopStandard e acabou de lançar uma versão remodelada do DesktopStandard Registry Extension. Com essa ferramenta, é possível determinar quais valores específicos do Registro você deseja gerenciar no computador de destino usando uma interface de assistente dentro do GPOE.
As tecnologias do DesktopStandard PolicyMaker (inclusive a ferramenta Registry Extension) agora se chamam Preferências de Diretiva de Grupo e estão incluídas no Windows Server 2008. As Preferências de Diretiva de Grupo permitem que o administrador configure aplicativos ou componentes do Windows que normalmente não podem ser configurados via Diretiva de Grupo e que a aplique a certos usuários ou computadores baseados em um conjunto avançado de regras de direcionamento. As Preferências de Diretiva de Grupo estão totalmente integradas ao Console de Gerenciamento de Diretiva de Grupo e ao Gerenciamento Avançado de Diretiva de Grupo no Windows Server 2008.
Você pode ler mais sobre as Preferências de Diretiva de Grupo no artigo de Derek Melber, "Informações detalhadas sobre o Gerenciamento Avançado de Diretiva de Grupo", nesta edição da TechNet Magazine.

Essa é fácil. Primeiro, obtenha o modelo ADM que deseja usar. Pode ser aquele que você baixou de GPanswers.com (temos uma dezena de modelos interessantes), ou talvez queira utilizar os arquivos ADM do Office 2003 ou do Office 2007 localizados no site da Microsoft.
Para adicionar no modelo, basta clicar com o botão direito do mouse nas palavras "Modelos Administrativos" e depois clicar em "Adicionar", como mostra a Figura 1. Por padrão, o Windows procura modelos no diretório \Windows\inf, mas não há motivo para você não armazená-los onde quiser. Isto é algo que talvez você não saiba: depois que o modelo ADM é adicionado a partir do ponto de armazenamento original, esse modelo ADM também é adicionado ao conteúdo do Objeto de Diretiva de Grupo (GPO) em si.
Por exemplo, para este artigo, fui para GPanswers.com e baixei nopassport.adm. Originalmente, eu guardava esse arquivo de modelo no meu diretório c:\temp. Esse modelo ADM permite silenciar a mensagem "Deseja adicionar seu passaporte?" que aparece na primeira vez que um usuário faz logon em um computador com o Windows XP.
Eu baixei também os modelos ADM do Office 2003 e os armazenei em c:\temp. Mas eles não ficarão nesse diretório. Na Figura 2, observe que adicionei nopassport.adm e Word11.adm. Você pode ver que eles foram adicionados à lista de modelos padrão na janela "Adicionar/Remover Modelos".
Figura 2 Arquivos ADM adicionais no GPO
Figura 2 Arquivos ADM adicionais no GPO
Agora, se você olhar dentro da parte baseada em arquivo do GPO em si (especificamente, no diretório \\domaincontroller\SYSVOL\domainname\Policies\GUID\ADM), poderá ver que os arquivos nopassport.adm e Word11.adm agora fazem parte do GPO, como mostra a Figura 2.
Por que esses modelos foram adicionados ao GPO? Porque, se você depois tentar editar esse GPO em outra estação de gerenciamento, poderá ver as configurações contidas dentro dos arquivos ADM.

Por que não posso ver o que acabei de carregar?
Às vezes, você pode ver suas adições de arquivos ADM; outras, não. E isso está causando bastante confusão para muitos administradores. De fato, essa é uma pergunta muito comum no GPanswers.com, por isso vamos esclarecê-la já.
Você deve poder ver, pelo menos, os resultados da adição dos dois modelos (consulte a Figura 3). Dois novos nós aparecerão: Configuração do Computador | Incômodos (por causa do nopassport.adm) e Configuração do Usuário | Microsoft Office Word 2003 (por causa do Word11.adm). Se você se aprofundar nas configurações do Microsoft® Word 2003, verá uma matriz enorme de configuráveis, como indicado na Figura 3.
Figura 3 Configurações de Diretiva de Grupo configuráveis
Figura 3 Configurações de Diretiva de Grupo configuráveis
Mas por que não é possível ver as configurações no novo nó Incômodos? Para compreender isso, você precisa primeiro entender a idéia de chaves Policies "próprias" versus "impróprias" que podem ser afetadas por um modelo ADM.

Chaves Policies próprias vs. impróprias
A documentação da Microsoft afirma que quatro áreas do Registro são consideradas como locais aprovados para criar diretivas fora de hacks do Registro:
  • HKLM\Software\Policies (configurações do computador; o local preferido)
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Policies (configurações do computador; um local alternativo)
  • HKCU\Software\Policies (configurações do usuário; o local preferido)
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies (configurações do usuário; um local alternativo)
As configurações contidas dentro do arquivo ADM do Word 2003 são gravadas nesses locais próprios, mas não o arquivo nopassport.adm, que é gravado em HKLM\Software\Microsoft\MessengerService\PassportBalloon.
O GPOE coloca um pequeno portão de segurança antes de permitir que você veja essas configurações porque as configurações que não são gravadas nessas quatro chaves Policies tatuarão o Registro. Por isso, mesmo que você partilhe o GPO, não há como reverter a configuração. Por exemplo, digamos que você adicionou o arquivo nopassport.adm e optou por silenciar o balão pop-up "Deseja adicionar um passaporte?" para cada computador em seu domínio . Mais tarde, o chefe diz que gostava muito daquele balão pop-up. Nesse caso, você tem um longo caminho a percorrer porque, agora, todos os computadores adotarão a configuração – basicamente, para sempre – até que você a coloque expressamente de volta. Sim, é possível criar um novo ADM personalizado apenas para essa finalidade; porém, mais uma vez, pode ser um caminho longo.
Por outro lado, as configurações de diretiva regulares têm um valor padrão. E, se você partilhar o GPO, essas configurações serão revertidas para o padrão. Por exemplo, se você optar por proibir o acesso ao Painel de Controle usando os modelos ADM internos e depois mudar de idéia, basta partilhar o GPO para que o acesso ao Painel de Controle volte. Isso é verdade para quase todas as configurações que acompanham os ADMs padrão (há algumas exceções bizarras).
Novamente, com o ADM personalizado com passaporte silenciado, o site no qual a configuração de diretiva é colocada não permite que o mecanismo de Diretiva de Grupo a reverta após a exclusão. Por isso, a Microsoft protege você (inicialmente) não mostrando essas configurações de diretiva de tatuagem para que não atire no próprio pé!

Visualizando modelos ADM
Visualizar os modelos ADM não é tão difícil assim. O editor, por padrão, não mostra as configurações a você, mas é fácil corrigir isso. Clique em "Modelos Administrativos" (na área do Usuário ou do Computador) e selecione Exibir | Filtragem. Finalmente, desmarque (é, isso mesmo, desmarque) "Só mostrar configurações de diretiva que podem ser 100% gerenciadas" (como você pode ver na Figura 4). Quando você fizer isso, verá a configuração de diretiva "Solicitação de Passaporte" exibida na coluna Configuração, como mostra também a Figura 4.
Figura 4 Filtragem de GPO
Figura 4 Filtragem de GPO

Windows XP versus Windows Vista no Editor
Você percebeu uma diferença sutil na configuração de diretiva que acabou de ser exibida? Olhe os ícones das configurações de diretiva que acompanham os arquivos ADM fora da caixa na Figura 5. Agora olhe o ícone referente a uma configuração de diretiva de um modelo ADM no qual as configurações não são gravadas nas chaves Policies do Registro próprias, como mostra a Figura 6.
Figura 5 Arquivos ADM com ícones
Figura 5 Arquivos ADM com ícones
Figura 6 Ícones para uso de chaves impróprias
Figura 6 Ícones para uso de chaves impróprias
Esse diferencial por ícone azul versus vermelho ajuda a saber quais configurações serão tatuadas ou não. Mais uma vez, tudo se baseia na configuração que realmente realiza sua obrigação.
No Windows Vista®, a propósito, a situação muda um pouco quando você usa arquivos ADM na sua estação de gerenciamento do Windows Vista. Os arquivos ADM são exibidos no próprio nó chamado "Modelos Administrativos Clássicos (ADM)", como mostra a Figura 7. O que eram configurações com pontos vermelhos agora são ícones de rolagem com uma seta para baixo (mas durante a edição da configuração em si, aparece um pequeno sinal "Nenhuma Entrada").
Figura 7 Nó Modelos Administrativos Clássicos
Figura 7 Nó Modelos Administrativos Clássicos
As configurações que eram pontos azuis (aquelas que são gravadas nas chaves Policies próprias) aparecem como pequenos ícones de rolagem, como mostra a Figura 8.
Figure 8 Ícones de rolagem mostrando chaves próprias
Figure 8 Ícones de rolagem mostrando chaves próprias

E que tititi é esse sobre ADMX?
Um novo GPMC (Console de Gerenciamento de Diretiva de Grupo) interno acompanha tanto o Windows Vista como o Windows Server 2003. Com esse novo GPMC, vem uma nova capacidade de se livrar de arquivos ADM antigos e abrir espaço para arquivos ADMX mais novos, se você quiser. Por que iríamos querer nos livrar do formato ADM?
Lembre-se que o próprio arquivo ADM é colocado dentro da parte Modelo de Diretiva de Grupo (GPT) do GPO (a parte que reside no SYSVOL). Quando isso acontece, você grava cerca de 4 MB em cada controlador de domínio toda vez que cria um GPO. Lembre-se também que o próprio arquivo ADM é colocado no GPT do GPO porque será necessário quando você quiser editar novamente o GPO em outra estação de gerenciamento. Sem esse arquivo ADM, não é possível editar nenhuma configuração personalizada dentro do GPO.
Portanto, o formato ADMX ajuda a nos livrarmos desses problemas. Como não é necessário armazenar mais nada diretamente dentro do GPO, você não obtém aquilo que é conhecido como "inchaço do SYSVOL", ou seja, um SYSVOL gordo que precisa armazenar GPOs cheios de arquivos ADM e tem a responsabilidade de replicá-los em cada controlador de domínio. Para contornar isso, o novo padrão ADMX pode tirar proveito do que é conhecido como "Armazenamento Central". A tarefa do Armazenamento Central é ter um local no qual você possa colocar os novos arquivos ADMX para que eles não precisem ser copiados em cada GPO. Com isso, adeus ao inchaço do SYSVOL. Outra coisa interessante sobre o Armazenamento Central é que, se um arquivo ADMX tiver uma definição atualizada, todas as estações de gerenciamento do Windows Vista usarão imediatamente esse arquivo ADMX atualizado.
Caso você queira aprender sobre o formato de arquivos ADMX, especificamente a criação e o uso do Armazenamento Central, tenho dois recursos para indicar. Na edição de fevereiro da Technet Magazine (technetmagazine.com/issues/2007/02/Templates, Darren Mar-Elia escreveu um artigo informativo sobre os aspectos internos do formato de arquivo ADMX e uma breve explanação sobre o Armazenamento Central. Sugiro também um capítulo inteiro do meu livro mais recente, Group Policy: Management, Troubleshooting, and Security, que pode ser baixado na seção "Recursos em livros" do GPanswers.com.
Como expliquei, os modelos ADM continuam com suporte quando você usa uma estação de gerenciamento do Windows Vista, mas os arquivos ADM não têm suporte dentro do Armazenamento Central. Isso pode ser um pouco confuso, por isso vamos pegar um exemplo.
Vamos supor que acabei de criar um GPO a partir de uma estação de gerenciamento do Windows Vista e depois ajustei algumas das configurações prontas para usar (como Proibindo Acesso ao Painel de Controle). Agora, vamos supor também que eu quisesse adicionar um modelo ADM personalizado. Depois de fazer isso, vamos dar uma espiada no GPT do GPO e ver o que aconteceu para esclarecer.
Para adicionar o modelo ADM, você pode repetir algumas etapas que executei anteriormente. Simplesmente abra o GPOE, clique com o botão direito do mouse em "Modelos Administrativos", que está contido no nó Usuários ou Computadores, e selecione "Adicionar/Remover Modelo". A Figura 9 mostra o modelo adicionado.
Figura 9 Exibindo o modelo adicionado
Figura 9 Exibindo o modelo adicionado
A fim de realmente ver as configurações contidas dentro desse modelo ADM, você precisará fazer o que fizemos anteriormente na Figura 4, ou seja, clicar em Exibir | Filtragem. Finalmente, desmarque "Só mostrar configurações de diretiva que podem ser 100% gerenciadas". Em seguida, feche o GPOE e retorne ao GPMC. A Figura 10 mostra a guia Detalhes do GPO que acabei de criar a partir da minha estação de gerenciamento do Windows Vista. (Observe o nome atraente do GPO). Examinando a guia Detalhes, posso determinar o GUID para o GPO, que tornará as coisas mais fáceis quando eu tentar localizar esse GPO em particular no SYSVOL.
Figura 10 Modelos Administrativos padrão
Figura 10 Modelos Administrativos padrão
Depois de rastrear o GPT do GPO (usando o GUID do GPO), posso abrir esse diretório ADM do GPO e ver que há exatamente um modelo ADM aqui – aquele que eu importei manualmente, mostrado na Figura 11. Isso ocorre porque os computadores com o Windows Vista não se baseiam mais em ADMs. Como eles não são usados nativamente por eles, não enviam nada nativamente por push para o GPO em si. No entanto, se você importar manualmente um ADM (como acabamos de fazer), ele continuará a honrar o ADM da mesma maneira que as versões anteriores do Windows.
Figura 11 Arquivo ADM importado manualmente
Figura 11 Arquivo ADM importado manualmente
Isso contraria o GPO na Figura 12, que foi criado em um computador com o Windows XP ou o Windows Server 2003. Quando GPOs são criados por estações de gerenciamento anteriores ao Windows Vista, os arquivos ADM originais são enviados por push para o GPO, conforme descrevi anteriormente. Esse GPO foi criado em uma estação de gerenciamento do Windows XP. Podemos afirmar isso porque ele está repleto de arquivos ADM que o Windows Vista não precisa nem usa.
Figura 12 GPO criado no Windows XP
Figura 12 GPO criado no Windows XP

Convertendo ADM em ADMX usando a ferramenta ADMX Migrator
O Windows XP usa arquivos ADM e o Windows Vista usa arquivos ADMX, embora o Windows Vista continue a dar suporte a arquivos ADM se isso for o que temos disponível. Entretanto, não podemos continuar usando um arquivo ADM no Armazenamento Central e esperar que as nossas estações de gerenciamento do Windows Vista consigam fazer uso do arquivo.
Para utilizar as configurações contidas dentro do ADM no Armazenamento Central, você precisaria converter o arquivo ADM em ADMX ou recriar os arquivos ADM como ADMX manualmente. Por sorte, há um download que realiza essas duas funções. A ferramenta ADMX Migrator (que, na verdade, é composta por uma ferramenta de conversão de ADM em ADMX e por uma ferramenta de criação de ADMX) pode ser baixada em go.microsoft.com/fwlink/?LinkId=103774.
O arquivo MSI da ferramenta ADMX Migrator pode ser instalado no Windows Server 2003, no Windows XP ou no Windows Vista. Depois dela instalada, os aplicativos podem ser encontrados no diretório C:\Arquivos de Programas\FullArmor\ADMX Migrator. O aplicativo de linha de comando que executarei se chama faAdmxConv.exe. Porém, como o diretório não está no caminho, você precisaria estar nesse diretório para executar o aplicativo. Portanto, ao usar a ferramenta , eu opto por adicionar esse diretório ao meu caminho do Windows. O artigo em www.computerhope.com/issues/ch000549.htm explica como definir o caminho no Windows.
Normalmente, eu crio um diretório temporário como C:\ADMtemp e copio meus arquivos ADM de origem nele. Há muitos parâmetros possíveis para faAdmxConv.exe, mas o modo mais simples de converter um arquivo ADM é especificar o nome do arquivo ADM e o diretório de saída. Se você já tiver colocado o arquivo ADM de origem em ADMtemp e adicionado faAdmxConv.exe ao caminho, basta executar "faAdmxConv nopassport.adm." (com o ponto no final para significar o diretório atual como saída). Se você não especificar o ponto (para esse diretório) ou outro caminho explícito, a saída irá para o diretório temporário dentro do perfil da sua conta. Na Figura 13, é possível ver três comandos:
Figura 13 Ferramenta ADMX Migrator
Figura 13 Ferramenta ADMX Migrator
  • Um comando "dir" para ver o arquivo ADM
  • O comando "faAdmxConv" com o nome do ADM e o . (ponto) para representar o diretório atual
  • Um "dir" para ver os arquivos resultantes: nopassport.admx e nopassport.adml
Antes de sair jogando os arquivos resultantes diretamente no Armazenamento Central, convém testá-los em um computador que esteja executando offline. Depois de colocar o computador offline, copie o arquivo ADMX para o diretório C:\Windows\PolicyDefinitions e o arquivo ADML para o diretório específico a um idioma. Em inglês, esse diretório é C:\Windows\PolicyDefinitions\en-us. A Figura 14 mostra um exemplo do procedimento de cópia.
Figura 14 Copiando arquivos ADMX para o Armazenamento Central
Figura 14 Copiando arquivos ADMX para o Armazenamento Central
A ferramenta de conversão de ADM em ADMX foi atualizada recentemente para a versão 1.2. Isso corrige vários bugs de conversão e adiciona mensagens de aviso úteis durante o tempo de conversão. Se você experimentou essa ferramenta no passado mas desistiu devido às mensagens de erro que não conseguiu corrigir, deveria experimentá-la novamente com a versão 1.2, já disponível para download.
Por último, o arquivo ADM convertido agora, na realidade, são dois arquivos: um arquivo ADMX (com neutralidade de idioma) e um arquivo ADML (específico a um idioma). Neste ponto, você pode colocar os arquivos resultantes dentro do Armazenamento Central ou testá-los em um computador local. Mais uma vez, porém, para ver realmente as configurações de diretiva contidas nesse modelo ADMX, você precisará fazer o que fizemos na Figura 4, ou seja, clicar em Exibir | Filtragem e depois desmarcar "Só mostrar configurações de diretiva que podem ser 100% gerenciadas". Isso ocorre porque as configurações contidas nesse arquivo ADMX não são gravadas em uma das chaves Policies próprias que abordei anteriormente.

Organizando as idéias
É claro que o estado ideal é usar somente arquivos ADMX e utilizar o Armazenamento Central. Mas, para fazer isso, você precisa converter todos os arquivos ADM atuais em ADMX, converter todas as estações de gerenciamento em Windows Vista (ou Windows Server 2008) e assumir o compromisso de parar de editar GPOs em computadores anteriores ao Windows Vista.
Se já concluiu essas três etapas, você mais ou menos baniu os arquivos ADM do seu mundo. Neste ponto, os arquivos ADM dentro dos seus GPOs estão apenas ocupando espaço no SYSVOL do seu controlador de domínio. Quando você alcançar o nirvana do ADMX, poderá (se quiser) simplesmente excluir os ADMs contidos no GPT do GPO dentro do SYSVOL. É isso mesmo: como o apêndice no seu corpo, eles deixam vestígios. Eles servem para uma finalidade neste momento; nada mais. Você pode fazer isso manualmente ou com um script. Mas antes, saiba que a não conclusão dessas etapas resultará em um erro muito grave. Por isso, só faça isso se tiver certeza de que pode deixar os arquivos ADM para trás.
Para obter informações adicionais sobre arquivos ADM, ADMX e ADML, consulte o Managing Group Policy ADMX Files Step-by-Step Guide (Guia Passo a Passo de Gerenciamento de Arquivos ADMX de Diretiva de Grupo) em go.microsoft.com/fwlink/?LinkId=105019 e a ADMX Technology Review (Revisão de Tecnologia ADMX) em go.microsoft.com/fwlink/?LinkId=105032. Além disso, não deixe de se inscrever no boletim informativo do GPanswers.com e em avisos intermediários via blog em GPanswers.com/blog.

Jeremy Moskowitz é MCSE e MVP em Diretiva de Grupo e administra o GPanswers.com, um fórum comunitário sobre Diretiva de Grupo. Ele também ministra uma série de cursos de treinamento intensivo. Seu livro mais recente se chama Group Policy: Management, Troubleshooting and Security (Diretiva de grupo: gerenciamento, solução de problemas e segurança; Sybex, 2007). Você pode contatá-lo pelo email www.GPanswers.com.


 Diretiva de Grupo: Otimizando o desempenho da Diretiva de Grupo
Diretiva de Grupo Darren Mar-Elia

Otimizando o desempenho da Diretiva de Grupo
Visão geral:
  • GPOs monolíticos vs. funcionais
  • Como processar entradas de diretiva de grupo
  • O que acontece quando ocorrem alterações de GP (Diretiva de Grupo)

Costumam me perguntar: "Do ponto de vista de desempenho, é melhor ter menos GPOs maiores ou um monte de pequenos?" Essa e outras perguntas relacionadas ao design e ao desempenho da Diretiva de Grupo são o foco deste artigo. E, como a maioria das perguntas abrangentes,
posso responder de antemão: "Depende". Embora possa parecer evasivo, meu objetivo é esclarecer os mecanismos que fundamentam o processamento de Diretiva de Grupo para que você possa tomar decisões informadas sobre o design da Diretiva de Grupo, não importa se está apenas iniciando ou procurando otimizar um ambiente com centenas de GPOs existentes.

GPOs monolíticos vs. funcionais
Vamos começar descrevendo as diferentes maneiras de implementar GPOs. Os termos "monolítico" e "funcional" se referem à forma como você os projeta. GPOs monolíticos contêm configurações de muitas áreas diferentes. Por exemplo, um GPO monolítico pode conter configurações das diretivas Modelos Administrativos, Manutenção do Internet Explorer e Instalação de Software – tudo dentro de um único GPO. Por outro lado, GPOs funcionais normalmente fazem uma coisa. Por exemplo, um GPO funcional pode fazer apenas Instalação de Software ou aplicar configurações de Segurança. Já vi GPOs funcionais que contêm somente uma configuração de diretiva! Mas isso provavelmente é o extremo. A Figura 1 mostra algumas das vantagens e desvantagens de cada abordagem.
Figure 1 Comparando GPOs monolíticos e funcionais (Close Figure 1)

Problema | GPOs monolíticos | GPOs funcionais
Delegação/Isolamento | Difícil, já que cada GPO pode conter configurações de várias áreas e você só pode delegar no nível de GPO, e não no nível de configurações. | Fácil, já que cada GPO contém uma única área de diretiva. Você pode delegar, por exemplo, o GPO de instalação de software ao administrador de implantação, o GPO de segurança ao diretor de segurança, e assim por diante.
Gerenciabilidade e complexidade | Potencialmente mais simples e mais fácil de gerenciar, porque cada GPO contém todas as configurações em um único local. | Potencialmente mais difícil, porque mais GPOs significa mais locais a olhar para rastrear problemas e mais complexidade determinando o conjunto de diretiva resultante para um determinado usuário ou computador.
Desempenho | Potencialmente mais lento porque, para uma determinada extensão do lado do cliente, se um GPO for alterado, todas as extensões precisariam ser executadas em todos os GPOs no escopo. | Depende de quantos GPOs estão em uso e com que freqüência eles são alterados. Em comparação com GPOs monolíticos, o desempenho poderia ser melhor em ambientes dinâmicos.
Como você pode ver, não há uma resposta simples sobre qual abordagem – monolítica ou funcional – é a melhor em todos os casos. No seu ambiente, é provável que você precise de ambas. Por exemplo, você pode achar a abordagem funcional preferível quando estiver criando diretiva de segurança para o domínio inteiro. Ter um único GPO que contenha somente configurações de segurança torna fácil delegar o controle desse GPO aos seus administradores de segurança onde ninguém mais pode tocá-lo. Pelo mesmo token, se você delegar a administração de GP a administradores de OU, o estabelecimento de um GPO monolítico para cada OU dará a esses administradores um local onde eles poderão gerenciar todas as configurações de diretiva. Isso pode reduzir a complexidade para eles e permitir que você modere o número de GPOs criados para os usuários e computadores de uma determinada OU.
Como essas decisões de design de alto nível afetam o desempenho do processamento de Diretiva de Grupo e como tomar decisões inteligentes sobre o design de GP que miminizem os impactos no desempenho? A primeira etapa no aumento do desempenho da sua infra-estrutura de Diretiva de Grupo é entender como o processamento de Diretiva de Grupo funciona nos bastidores.

Noções básicas sobre o processamento de Diretiva de Grupo
O processamento de Diretiva de Grupo é um conjunto complexo de interações envolvendo muitas peças da sua infra-estrutura do Windows® e do Active Directory®. Em um alto nível, existem duas partes no processamento de Diretiva de Grupo. A primeira é chamada Principal ou processamento da Infra-estrutura de Diretiva de Grupo. Nesta fase, um cliente de Diretiva de Grupo do Windows consulta seu controlador de domínio mais próximo para determinar qual é a velocidade de conexão com o DC, onde ele reside na hierarquia do Active Directory (ou seja, de qual site, domínio e OU o cliente é membro) e quais GPOs se aplicam ao computador ou ao usuário conectado no momento. (É importante observar que, neste contexto, um cliente poderia ser um servidor ou uma estação de trabalho que participe de um domínio do Active Directory.) Uma vez criada a lista de GPOs, a próxima fase é acionada – o processamento da Extensão do Cliente (CSE). Durante a fase de CSE, cada CSE registrado processa a lista de GPOs que implantaram configurações na respectiva área. Por exemplo, o CSE Modelo Administrativo ou Registro é executado primeiro em todos os casos e processa todos os GPOs que se aplicam ao usuário ou computador e que tenham implementado diretiva do Registro dentro deles.
A lista a seguir detalha as etapas percorridas pelo ciclo do processamento de Diretiva de Grupo, incluindo interações de rede entre o cliente e o controlador de domínio. É importante lembrar que a Diretiva de Grupo se aplica tanto a usuários como a computadores. Portanto, cada diretiva de tempo é processada (por exemplo, durante a atualização em segundo plano da Diretiva de Grupo). O ciclo que enumero abaixo será repetido tanto para o computador como para a conta de usuário conectada no momento em um determinado sistema, já que cada um pode ter um conjunto diferente de diretivas aplicadas a eles. Quando isso ocorre, o Windows, na verdade, executa o ciclo de processamento ao mesmo tempo tanto para o usuário como para o computador, com cada ciclo sendo executado em um thread diferente dentro do processo de mecanismo da Diretiva de Grupo. (O processo Winlogon para Windows 2000, Windows XP e Windows Server® 2003, e o serviço Cliente de Diretiva de Grupo no Windows Vista® e no Windows Server 2008.)
Processar uma GP é um procedimento em seis etapas:
  1. O cliente executa detecção de vínculo lento do protocolo ICMP em um controlador de domínio no respectivo site para determinar a velocidade de conexão. No Windows Vista, o uso de ICMP para detecção de vínculo lento é substituído pelo serviço Reconhecimento de Locais de Rede (NLA).
  2. O cliente lê as informações de status do CSE a partir do Registro local para determinar quais GPOs foram processados por último.
  3. O cliente usa LDAP para procurar o atributo gpLink no Active Directory em cada objeto de contêiner em seu respectivo local na hierarquia do Active Directory – primeiro no nível de OU (incluindo todas as OUs aninhadas), depois no domínio e, por último, no nível de site do Active Directory. A partir dos resultados dessa pesquisa, ele cria uma lista de GPOs que devem ser avaliados para processamento.
  4. Cada GPO é então pesquisado no Active Directory para determinar se o cliente (usuário ou computador) tem as permissões necessárias para processá-lo. Seu número de versão, o caminho para a parte Modelo de Diretiva de Grupo (GPT) do GPO no SYSVOL e quais CSEs foram implementados nesse GPO também são avaliados.
  5. O cliente então usa o protocolo SMB para ler o conteúdo do GPT e obter o número de versão do GPO do arquivo gpt.ini. Os números de versão no Contêiner de Diretiva de Grupo (GPC) e no GPT são um fator usado para determinar se um GPO foi alterado desde o último ciclo de processamento.
  6. Cada CSE é executado na ordem em que é registrado em HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions e processa os GPOs que implementam esse CSE caso o GPO tenha sido alterado desde o último ciclo de processamento (conforme determinado durante o processamento principal). Cada CSE também registra em log os dados RSOP (Conjunto de Diretivas de Usuário Resultante) na Instrumentação de Gerenciamento do Windows (WMI) durante cada atualização, se disponível.
Vamos dissecar esse processo e ver como o desempenho pode ser afetado. A primeira coisa a observar é que há uma diferença entre processamento em primeiro e em segundo plano. O processamento em primeiro plano ocorre para computadores durante uma reinicialização do sistema e, para usuários, durante um logon do usuário. Atualizações em segundo plano ocorrem em estações de trabalho e em servidores membros, por padrão, a cada 90 minutos, acrescidos de até 30 minutos em um valor aleatório. Em controladores de domínio, elas ocorrem a cada 5 minutos, por padrão. No Windows Vista, também é possível ter atualizações baseadas no NLA, que são essencialmente eventos de atualização em segundo plano acionados por uma falha anterior do processamento de Diretiva de Grupo decorrente da falta de acesso a um controlador de domínio (como quando o cliente estava offline e um intervalo em segundo plano ocorreu). Por que essas distinções são importantes? Principalmente porque certos CSEs (por exemplo, os CSEs Redirecionamento de Pasta e Instalação de Software) não serão executados durante uma atualização em segundo plano, o mesmo ocorrendo para scripts de logon/logoff ou de inicialização/desligamento.
De modo semelhante, na Etapa 1 desse processo, mencionei o processo de detecção de vínculo lento. Em sistemas anteriores ao Windows Vista, esse processo se baseia em clientes que usam o ICMP para executar ping no controlador de domínio a fim de determinar sua disponibilidade e velocidade de conexão. Se a velocidade de conexão calculada cair abaixo de um determinado valor limite (o padrão é 500 Kb/s), o vínculo será considerado lento e, mais uma vez, certos CSEs, como Redirecionamento de Pasta, Instalação de Software e Manutenção do Internet Explorer, não serão executados. Todas essas condições podem ter impacto no desempenho e no fornecimento de diretiva esperado.
Provavelmente, o aspecto do ciclo de processamento de diretiva com maior impacto no desempenho é a lógica que determina se os GPOs aplicados a um computador ou usuário foram alterados. O mecanismo da Diretiva de Grupo tem uma otimização interna que diz que, se nada fora alterado para um computador ou usuário desde a última vez em que a GP foi processada, nenhum processamento ocorrerá. Obviamente, isso pode ter um tremendo impacto no tempo que os clientes levam para processar a diretiva, em especial se o seu ambiente de GP for razoavelmente estático. Vejamos mais detalhadamente no que constitui uma alteração.

Quando ocorre alteração na Diretiva de Grupo
Então, o que constitui uma alteração em termos de processamento de Diretiva de Grupo? Existem muitos fatores, mas o mais óbvio é que, se você fizer uma alteração em um GPO, os clientes que estejam processando esse GPO detectarão a alteração e o reprocessarão. Como um cliente sabe que um GPO foi alterado? Ele se baseia em números de versão no GPO e dentro do cliente para descobrir.
Um GPO é composto por duas partes: o GPC armazenado no Active Directory no contêiner CN=Policies, CN=System dentro de cada domínio, e o GPT armazenado no SYSVOL na pasta "Policies". Cada parte do GPO contém um número de versão. Para o GPC, esse número de versão é armazenado no atributo versionNumber no objeto do GPC. Para o GPT, ele é armazenado dentro do arquivo gpt.ini na raiz de um determinado GPT. O cliente também mantém um registro dos números de versão dos GPOs que ele processou (por computador e por usuário) dentro do seu Registro. Essas informações de versão são armazenadas em HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History para o computador e em HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID do Usuário> para o usuário, em cada cliente.
Quando ocorre o processamento de Diretiva de Grupo, uma das partes é para examinar os números de versão de todos os GPOs aos quais o computador ou usuário está sujeito e compará-los aos processados durante o último ciclo, como encontrado no Registro. Se algum dos números de versão dos GPOs atuais for diferente (observe que eles só precisam ser diferentes; podem ser maiores ou menores!), esses GPOs serão processados durante o ciclo de processamento atual. Caso contrário, eles não serão processados, a menos que uma destas outras condições de alteração seja atendida:
  • Uma alteração na lista de GPOs que se aplicam a um usuário ou computador (um GPO foi adicionado ou removido)
  • Uma alteração na associação do grupo de segurança de um usuário ou computador
  • Uma alteração em um filtro WMI vinculado a um GPO (um filtro WMI foi adicionado ou removido)
Se nenhuma dessas condições de alteração forem atendidas, o cliente reprocessará a diretiva durante esse ciclo. Mas há sutilezas nesse processo que você precisa saber, já que podem ter um impacto significativo no desempenho. Para um determinado CSE, se houver 1 GPO de 10 alterações, então todos os GPOs deverão ser processados para esse CSE. Lembre-se de que o processamento ocorre por CSE. No entanto, os CSEs devem processar a diretiva na ordem de precedência que controla o processamento (primeiro GPOs locais, depois GPOs vinculados a sites e GPOs vinculados a domínios e, por último, GPOs vinculados a OUs). Dado esse requisito, digamos que um usuário tem 10 GPOs que se aplicam, cada um vinculado a diferentes níveis da hierarquia do Active Directory. E digamos que cada um desses 10 GPOs implementam algumas configurações da diretiva Modelo Administrativo. Agora, um administrador acompanha e altera um GPO vinculado ao domínio, adicionando uma nova configuração da diretiva Modelo Administrativo. Em seguida, o computador ou usuário vai processar a diretiva e observa que o número de versão desse GPO alterado está maior que no último processamento e, por isso, ele precisa ser processado novamente. Mas, a fim de manter a ordem de precedência do processamento de GP, ele deve processar todas as configurações de Modelo Administrativo que se aplicam a todos os GPOs. Assim, uma alteração simples em um GPO pode ter um impacto no desempenho potencialmente significativo para esse cliente.

Comparando o desempenho de GPOs monolíticos e funcionais
Agora que examinamos o ciclo de processamento e como as alterações no ambiente da Diretiva de Grupo afetam o processamento, vamos voltar à nossa discussão sobre GPOs monolíticos versus funcionais e como cada abordagem afeta o desempenho.
Os GPOs monolíticos podem ter uma penalidade de desempenho oculta devido ao modo como funciona o controle de versão da Diretiva de Grupo. Os motivos para isso não são todos óbvios, mas têm a ver com o fato de que não há nenhum conceito de controle de versão por CSE dentro do processamento de Diretiva de Grupo. Digamos que um usuário tem três GPOs que se aplicam a ele. Cada GPO é monolítico no sentido de que implementa várias áreas de diretiva. Por exemplo, vamos supor que cada GPO implemente a diretiva Modelo Administrativo, a diretiva Instalação de Software e a diretiva Redirecionamento de Pasta. Agora, digamos que um administrador faça um alteração na diretiva Modelo Administrativo em um desses GPOs. Seu número de versão é aumentado devido a essa alteração. Em seguida, o usuário acompanha e processa a Diretiva de Grupo. O CSE Modelo Administrativo é iniciado e vê que um dos GPOs foi alterado, por isso processa esses três GPOs novamente.
Quando os CSEs Instalação de Software e Redirecionamento de Pasta são executados, eles também examinam os números de versão do GPO e observam o novo número de versão em um dos GPOs. Porém, como esse número de versão não informa qual área de diretiva foi alterada nesse GPO, eles seguem em frente e processam todos os três GPOs novamente, só para garantir. O resultado é que, em uma implementação de GPO monolítico, fazer alterações em uma área de diretiva pode causar atividade de processamento em outra área.
A verdade é que, no caso da diretiva de instalação de software ou de redirecionamento de pasta, esses CSEs podem não executar de verdade nenhum trabalho porque, por exemplo, se um aplicativo já tiver sido instalado, não o será novamente. Mas o ponto é que esse comportamento pode ocorrer com qualquer CSE e deve ser levado em consideração durante o design de GPOs monolíticos. Se você tiver uma área de diretiva que seja alterada com freqüência, convém considerar a possibilidade de manter GPOs que a implementam separados de outras áreas de diretiva.
Do ponto de vista de um GPO funcional, as considerações sobre desempenho são mais óbvias. Se você tiver mais GPOs por usuário ou computador (já que a abordagem funcional geralmente envolve mais GPOs para um determinado conjunto de configurações de diretiva), isso significa que o mecanismo de Diretiva de Grupo precisará passar mais tempo enumerando esses GPOs durante a fase principal do processamento de Diretiva de Grupo. No entanto, como veremos na próxima seção, não necessariamente isso afeta o desempenho de forma significativa.

Mensurando o desempenho da Diretiva de Grupo
No final das contas, a fim de tomar decisões acertadas sobre o desempenho da sua infra-estrutura de Diretiva de Grupo, você precisa ser capaz de mensurar como a Diretiva de Grupo está sendo executada em seu ambiente da vida real. Modelar ou prever o desempenho da Diretiva de Grupo é praticamente impossível, dado o grande número de fatores que podem afetar um determinado ciclo de processamento. Por esse motivo, a mensuração empírica é sua melhor chance de descobrir se o desempenho do processamento de GP é um problema. O que significa desempenho ruim? Bem, é qualquer situação em que o processamento de Diretiva de Grupo afete negativamente a experiência dos usuários nos sistemas. Isso pode ser diferente para cada organização, mas a chave é saber que você tem um problema.
Então, como medir a duração de um determinado ciclo de processamento de Diretiva de Grupo? Mais uma vez, a resposta não é simples. Se você estiver executando o Windows Vista ou o Windows Server 2008, poderá aproveitar os novos Logs Operacionais de Visualizar Eventos. O log operacional de Diretiva de Grupo dentro de Visualizar Eventos, localizado em Applications and Services Logs\Microsoft\Windows\Group Policy\Operational, fornece uma instrumentação excelente de cada etapa do ciclo de processamento de Diretiva de Grupo, inclusive o tempo gasto durante cada fase de processamento (consulte a Figura 2).
Figura 2 Evento de Log Operacional de Diretiva de Grupo mostrando o tempo de processamento da diretiva
Figura 2 Evento de Log Operacional de Diretiva de Grupo mostrando o tempo de processamento da diretiva
No entanto, se você não estiver trabalhando em um ambiente do Windows Vista ou do Windows Server 2008, os mecanismos para mensurar os tempos de processamento da diretiva são menos diretos. Nesse caso, suas opções são habilitar o registro detalhado de userenv em log (consulte o artigo de suporte da Microsoft em support.microsoft.com/kb/221833) e exibir os carimbos de data/hora dentro desse arquivo para um determinado ciclo de processamento, ou usar os valores guardados no Registro do cliente que indicam os horários de início e de conclusão do processamento de diretiva. Para o computador, esses valores são armazenados neste local:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}
e aqui para o usuário:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}
Os valores são armazenados no formato FILETIME e precisam ser convertidos para uma hora e data normal. Você também pode usar o utilitário gratuito GPTime.exe que escrevi (disponível em gpoguy.com/tools.htm#GP_Time_Utility) para obter as mesmas informações.
Se você não tem um ambiente do Windows Vista ou do Windows Server 2008, mas tem acesso a um log userenv, ainda assim poderá obter informações valiosas sobre o tempo gasto em cada ciclo de processamento de diretiva. Por exemplo, a Figura 3 exibe um trecho do log userenv mostrando parte da fase principal do processamento de Diretiva de Grupo.
Figura 3 Uma parte do log userenv
Figura 3 Uma parte do log userenv
Observe que cada linha do arquivo de log contém um carimbo de data/hora. A parte principal do ciclo de processamento de Diretiva de Grupo começa quando você vê um evento que diz algo como "ProcessGPOs: Iniciando processamento (em segundo plano) de Diretiva de Grupo de usuário..." A parte CSE do ciclo de processamento de Diretiva de Grupo começa quando você vê a linha "ProcessGPOs: Processando Registro da extensão." Você pode usar esse log e os carimbos de data/hora dentro dele para determinar o tempo que leva cada parte de um ciclo de diretiva.

Observações gerais sobre desempenho
Quando você passa tempo suficiente examinando arquivos de log userenv, começa a ver os padrões surgirem e, embora não possa prever quanto tempo levará o processamento de diretiva, pode começar a fazer algumas observações gerais sobre onde o tempo é gasto em um determinado ciclo de processamento. Por exemplo, durante um evento de processamento de diretiva, quando alterações na diretiva estão sendo processadas e os CSEs têm trabalho a fazer por causa de uma alteração, o tempo gasto na parte principal do processamento de GP normalmente é muito menor se comparado à parte CSE.
Isso ocorre para a maior parte das áreas de diretiva porque a maioria dos CSEs precisa realizar tarefas que sejam executadas por mais tempo que a parte principal do processamento deles, cujas operações mais caras são consultar o Active Directory e o SYSVOL. Por exemplo, não há comparação entre o tempo gasto no processamento principal e o CSE Instalação de Software que executa uma instalação do Microsoft® Office. No entanto, para uma atualização de diretiva em segundo plano normal, na qual nada foi alterado desde o último ciclo, a parte principal do ciclo de processamento leva praticamente o mesmo tempo que a parte CSE. A exceção é o processamento da diretiva Registro, que, na verdade, é razoavelmente rápido, a menos que você tenha dezenas ou centenas de configurações da diretiva Registro no local para um determinado usuário ou computador.
Além disso, a desabilitação do lado do computador ou do usuário de um GPO por não estar sendo utilizado tem pouco efeito no desempenho do processamento de diretiva. Se um lado de diretiva não estiver sendo utilizado, a única sobrecarga será na consulta ao Active Directory para determinar isso, e a mesma consulta deve ser executada para exibir a opção de desabilitação como aquela que ocorre para determinar se algum CSE foi implantado para esse lado do GPO. O efeito de desabilitar um lado é irrisório.

Recomendações de design para desempenho ideal de GP
Agora que examinamos muitos aspectos do desempenho do processamento de Diretiva de Grupo, existem algumas recomendações de design que podem ter impacto direto no desempenho. Elas estão resumidas em quatro pontos-chave.
  1. Se você estiver fazendo alterações freqüentes em seus GPOs, tenha em mente o efeito mencionado anteriormente, no qual uma alteração em um CSE pode afetar o processamento de todos os CSEs. Para essa finalidade, se você planeja fazer alterações freqüentes na diretiva do Registro, por exemplo, faz mais sentido colocar sua diretiva de Registro em GPOs funcionais (GPOs que só fazem diretiva do Registro) já que isso impedirá o processamento de outros CSEs quando as alterações ocorrerem.
  2. Ao pensar sobre quantos GPOs poderia ser um número excessivo, tenha em mente que o processamento de diretiva só ocorre durante alterações e que CSEs "caros" (como Instalação de Software, Redirecionamento de Pasta), controlar um grande número de diretivas do Registro ou definir permissões em árvores do Registro ou arquivos grandes é que leva a maior parte do tempo. O tempo gasto consultando o Active Directory em relação à lista de GPOs durante o processamento principal geralmente é a menor parte do ciclo de processamento. Assim, 30 GPOs que se aplicam a um determinado usuário, mas fazem alterações mínimas e raramente na diretiva do Registro podem levar menos tempo para serem processados do que 5 GPOs que estejam executando CSEs caros regularmente, porque esses GPOs estão sendo alterados com freqüência.
  3. Evite comportamentos que forcem retardamentos óbvios no desempenho do processamento de diretiva. Por exemplo, você pode definir a diretiva para forçar os CSEs a serem processados mesmo que um GPO não tenha sido alterado (em Configuração do Computador\Modelos Administrativos\Sistema\Diretiva de Grupo). No entanto, se você fizer isso, é quase certo que o processamento de diretiva levará mais tempo durante cada ciclo.
  4. Tenha em mente as compensações de desabilitar a Otimização de Logon Rápido no Windows XP e no Windows Vista (isso é feito por meio da habilitação da diretiva em Configuração do Computador\Modelos Administrativos\Sistema\Logon\Sempre esperar pela rede na inicialização do computador e no logon do usuário). Quando essa diretiva for habilitada, o processamento em primeiro plano alternará de assíncrono para síncrono. Isso significa que a diretiva do computador e do usuário deve ser executada até o final para que o usuário assuma o controle do computador e do desktop. No entanto, isso também pode ser benéfico, pois contorna o problema de requerer duas ou mais reinicializações ou logons para que as diretivas Instalação de Software e Redirecionamento de Pasta entrem em vigor.

Conclusão
Embora o desempenho do processamento de Diretiva de Grupo não seja uma ciência exata, existe uma visão aprofundada que pode ser trazida para o processo de design e talvez reduza os problemas de desempenho.
Saber como funciona o ciclo de processamento e onde o tempo é gasto pode poupar um bom tempo no rastreamento de problemas de desempenho. Use os logs operacionais do Windows Vista ou do Windows Server 2008 (ou logs userenv em versões anteriores do Windows) para obter informações instrumentadas sobre o ciclo de processamento. Tenha em mente os caprichos do processamento de CSE e o que constitui uma alteração na diretiva do ponto de vista de um CSE. E lembre-se que, em ambientes dinâmicos com muitas alterações, GPOs funcionais podem fazer mais sentido que os monolíticos. Mas o ponto principal é que a Diretiva de Grupo é uma tecnologia criada para ajudar você a gerenciar melhor o ambiente Windows. É muito importante que as suas necessidades de negócios orientem o design de Diretiva de Grupo, e não ao contrário. Ter em mente alguns dos comportamentos de desempenho discutidos aqui pode ajudá-lo a atingir esse objetivo.

Darren Mar-Eliaé MVP de Diretiva de Grupo na Microsoft, criador do site popular de Diretiva de Grupo www.gpoguy.com e co-autor do Microsoft Windows Group Policy Guide (Guia de Diretivas de Grupo do Microsoft Windows; Microsoft Press, 2005). Ele também é CTO e fundador da SDM Software, Inc. Você pode contatá-lo pelo email Darren@gpoguy.com.


 Diretiva de Grupo: Informa&#231;&#245;es detalhadas sobre o Gerenciamento Avan&#231;ado de Diretiva de Grupo
Diretiva de Grupo Derek Melber

Informações detalhadas sobre o Gerenciamento Avançado de Diretiva de Grupo
Visão geral:
  • Arquitetura e instalação do AGPM
  • Edição offline de GPOs
  • Gerenciamento de alterações com o AGPM
  • Recuperação de desastre

Recentemente, a Microsoft adquiriu a DesktopStandard, uma empresa que criou um produto que permite o gerenciamento completo de Objetos de Diretiva de Grupo. Na minha opinião, toda empresa que usa o Active Directory deveria executar essa ferramenta – o Gerenciamento Avançado de Diretiva de Grupo (AGPM).
O AGPM fornece edição offline de GPOs (Objetos de Diretiva de Grupo), gerenciamento de alterações, fluxo de trabalho de diretivas de atualização, delegação, e muito mais. Neste artigo, vou me aprofundar no funcionamento interno da ferramenta, fornecendo uma visão detalhada desse produto incrível e extremamente útil.
Vou dar primeiro algumas informações básicas. O AGPM era conhecido inicialmente como GPOVault. Depois de adquirir a DesktopStandard, a Microsoft o renomeou como AGPM e o adicionou ao Microsoft® Desktop Optimization Pack (MDOP). Atualmente, você só pode obter o MDOP se as suas licenças de desktop do Windows Vista® estiverem cobertas pelo Microsoft Software Assurance.
Baseado na minha experiência com as ferramentas incluídas, creio que o MDOP é, de longe, uma das ofertas mais impressionantes da Microsoft nos últimos tempos. O MDOP vem com cinco ferramentas diferentes (cada uma delas impressionante individualmente) que, juntas, criam um conjunto dos mais valiosos e notáveis. Para obter mais informações sobre o MDOP, consulte o site windowsvista.com/optimizeddesktop.

Arquitetura e instalação do AGPM
A instalação do AGPM foi projetada para ser reduzida e fácil. Ela consiste em um componente de servidor e um componente (administrativo) cliente. O componente de servidor deve ser instalado em um servidor membro no domínio; ele não altera o Active Directory®, o esquema ou qualquer outro serviço de diretório. O AGPM pode ser instalado em um controlador de domínio se a situação assim exigir.
A instalação do servidor instalará um serviço que requer uma conta de serviço baseada em domínio, a partir da qual o AGPM acessa Objetos de Diretiva de Grupo de produção ao vivo em nome do usuário. A instalação também requer que haja um Administrador do AGPM, que controlará todas as configurações dentro do AGPM, como delegação e gerenciamento inicial de GPOs.
O cliente deve ser instalado em um computador com o Windows Vista, no qual já ocorram funções administrativas normais, muito provavelmente no desktop dos administradores da rede e do Active Directory. Agora o cliente precisa apontar as configurações do AGPM para o servidor AGPM a fim de que a conexão com o arquivo morto seja feita. O cliente AGPM usa a interface do Console de Gerenciamento de Diretiva de Grupo (GPMC) e é exibido como o nó Controle de Alteração, conforme mostra a Figura 1.
Figura 1 O AGPM é totalmente integrado ao GPMC para facilitar o uso
Figura 1 O AGPM é totalmente integrado ao GPMC para facilitar o uso
Os arquivos que o cliente AGPM acessará estão armazenados em um formato de arquivo básico no servidor AGPM. Esse é o método mais simples para armazenar esses arquivos e facilita o backup do arquivo morto do AGPM inteiro. A maioria das funções do AGPM usa as APIs internas do GPMC que, mais uma vez, contribuem para a integração e o uso ininterrupto do produto. O AGPM não usa um banco de dados; ele armazena os GPOs em uma única pasta e um manifesto controla a correlação de todos os GPOs com o GPO pai dentro do arquivo. Isso garante que todos os GPOs tenham um GUID exclusivo, mas, quando colocado em produção, o GUID correto é associado ao GPO na implantação.

Edição offline do AGPM
O recurso mais básico do AGPM é a capacidade de fazer a edição de GPOs offline, longe do ambiente de produção. Já é um problema conhecido o fato de que a edição dos GPOs com o uso do GPMC padrão pode resultar em configurações errôneas que são imediatamente enviadas por push para o ambiente de produção, podendo causar resultados desastrosos.
O APGM lida com a edição de GPOs offline "controlando" os GPOs. Um GPO controlado, como mostra a Figura 2, é aquele que pode ser editado offline sem provocar nenhuma intrusão no ambiente de produção.
Figura 2 Os GPOs são armazenados no arquivo morto do AGPM e podem ser editados offline
Figura 2 Os GPOs são armazenados no arquivo morto do AGPM e podem ser editados offline
Controlar um GPO é muito simples. Os GPOs não controlados, como mostra a Figura 3, listam todos os GPOs que ainda não foram associados ao arquivo morto do AGPM. O clique com o botão direito do mouse em qualquer um desses GPOs abre um menu, que inclui Controle. A seleção da opção de menu Controle copiará o GPO do local de produção (o compartilhamento do volume do sistema, ou SYSVOL, no controlador de domínio) e o colocará no arquivo morto do AGPM. Vários GPOs podem ser controlados; basta manter pressionada a tecla Shift ou Control ao selecionar os GPOs para obter a lista correta de GPOs que você deseja controlar e depois clicar com o botão direito do mouse para acessar a opção de menu Controle. Também é possível editar GPOs controlados usando o Editor de Objeto de Diretiva de Grupo (GPOE). Essa é apenas outra forma pela qual o AGPM foi totalmente integrado ao GPMC.
Figura 3 Os GPOs não controlados são colocados no arquivo morto por meio da seleção da opção de menu Controle
Figura 3 Os GPOs não controlados são colocados no arquivo morto por meio da seleção da opção de menu Controle

Delegação da administração do AGPM
Vejamos como o AGPM controla a delegação examinando primeiro como se delega a administração de GPOs com o uso do GPMC. Dentro do GPMC, existem cinco tarefas de delegação diferentes que podem ser concedidas a um usuário: Criar GPO, Vincular GPO, Editar GPO, Gerenciar GPO e Ler GPO.
Todas essas delegações são concluídas dentro da interface do GPMC. Elas são controladas pelos usuários e grupos listados nas guias Delegação associadas aos diferentes nós dentro do GPMC. As delegações que nos interessam são aquelas que permitem a criação de novos GPOs, bem como a edição e o gerenciamento de GPOs existentes.
A criação de GPOs dentro do GPMC é controlada pela guia Delegação associada ao nó Objetos de Diretiva de Grupo, como mostra a Figura 4. Uma vez instalado o AGPM, você poderá remover todos os usuários e grupos da lista de quem tem acesso para criar GPOs. (Não há necessidade de remover sistema, computadores ou grupos de computadores da guia Delegação para criar GPOs.) A criação de GPOs passará a ser controlada pela conta de serviço que controla o serviço AGPM. A essa conta será concedida a delegação para criar GPOs em nome de todos os usuários e grupos aos quais foram concedidas as delegações Criar GPOs e Implantar de dentro do AGPM.
Figura 4 A criação de GPOs é controlada pela lista de contas na guia Delegação do nó Objetos de Diretiva de Grupo no GPMC
Figura 4 A criação de GPOs é controlada pela lista de contas na guia Delegação do nó Objetos de Diretiva de Grupo no GPMC
Essa nova capacidade de criar GPOs permite a separação de tarefas e protege a rede de produção. O ideal seria que os GPOs fossem criados, configurados e verificados antes de serem implantados do ambiente do AGPM para a produção. Raramente haverá qualquer configuração errônea enviada por push como ocorre atualmente sem o AGPM.
Para a delegação relacionada à edição ou ao gerenciamento de GPOs, a história é semelhante. Dentro do GPMC, essas delegações são configuradas na guia Delegação associada a cada GPO, como mostra a Figura 5.
Figura 5 A edição e o gerenciamento de GPOs estão associados a cada GPO individualmente
Figura 5 A edição e o gerenciamento de GPOs estão associados a cada GPO individualmente
Uma vez instalado o AGPM, essas delegações precisam ser removidas de cada GPO listado no nó Objetos de Diretiva de Grupo. Isso restringirá a edição de GPOs externos ao AGPM pelos administradores. Basicamente, isso canaliza toda a administração de GPOs para o AGPM, onde tarefas como edição offline, gerenciamento de alterações e recuperação de desastre são possíveis.
A remoção de usuários e grupos da edição de GPOs externos ao AGPM é um processo manual. A instalação e configuração do AGPM não remove nenhum usuário ou grupo da edição de GPOs no ambiente de produção. Como a conta de serviço que controla o serviço AGPM estará realizando as ações em nome dos usuários que modificam GPOs de produção do AGPM, não é necessário que haja nenhum usuário ou grupo de usuários listado na guia Delegação de cada GPO. (Computador e grupos de computadores não devem ser removidos dessas guias de delegação.)
Depois que todas as delegações para a edição de um GPO dentro do GPMC forem removidas, todos os administradores terão negada a capacidade de editar um GPO a partir do GPMC, como mostra a Figura 6.
Figura 6 Os administradores não poderão editar GPOs a partir do GPMC depois que a delegação para essa ação lhes for negada
Figura 6 Os administradores não poderão editar GPOs a partir do GPMC depois que a delegação para essa ação lhes for negada
Para finalizar a configuração, todos os administradores que precisem editar GPOs devem ser adicionados às ACLs (Listas de Controle de Acesso) dentro do AGPM. Se for necessário que um administrador possa editar todos os GPOs que estão no arquivo morto, a conta de usuário dele deverá ser adicionada a um grupo ao qual tenham sido concedidos recursos de edição no nível de domínio dentro do AGPM, como mostra a Figura 7. Caso um administrador fique limitado à edição de alguns GPOs dentro do arquivo morto do AGPM, essa configuração deverá ocorrer em cada GPO (consulte a Figura 8).
Figura 7 A guia Delegação de Domínio permite configurar a edição de todos os GPOs no arquivo morto
Figura 7 A guia Delegação de Domínio permite configurar a edição de todos os GPOs no arquivo morto
Figura 8 A edição de GPOs individuais precisa ser configurada na ACL deste GPO
Figura 8 A edição de GPOs individuais precisa ser configurada na ACL deste GPO

Gerenciamento de alterações do AGPM em GPOs
Um dos incríveis benefícios do AGPM é a capacidade de rastrear todas as alterações feitas em GPOs dentro do arquivo morto. Como se trata de um processo automatizado, ele não precisa ser definido, configurado ou gerenciado. O rastreamento de todas as alterações ocorre em segundo plano quando os GPOs são gerenciados através da interface do Cliente AGPM.
Esse é um aprimoramento significativo no modo como o GPMC padrão controla o gerenciamento de GPOs. Dentro do GPMC padrão, não há recursos automatizados (ou até internos) para rastrear alterações em GPOs. Essa tem sido a principal reclamação da maioria dos administradores de Diretiva de Grupo ao longo dos anos. Agora, o problema foi eliminado.
O recurso de gerenciamento de alterações do AGPM rastreia todas as modificações essenciais que poderiam ocorrer em um GPO. Junto com as alterações feitas no GPO, o sistema de gerenciamento de alterações também ajudará em uma situação de rastreamento de administração geral ou de auditoria. Esse sistema irá monitorar, rastrear e documentar as seguintes especificações por edição e alteração de GPO: data e hora em que o GPO foi modificado, usuário que fez a alteração, configurações originais do GPO e modificações nas configurações do GPO.
Como o rastreamento de todas as alterações é ininterrupto, é importante saber quais ações disparam o rastreamento automatizado. Dentro da interface do Cliente AGPM, você pode clicar com o botão direito do mouse em um GPO na guia Controlado e depois selecionar a opção de menu Fazer Check-out, como mostra a Figura 9.
Figura 9 Fazer check-out de um GPO acionará o processo automatizado para rastrear alterações
Figura 9 Fazer check-out de um GPO acionará o processo automatizado para rastrear alterações
Esse procedimento deve ser seguido para editar o GPO, que abordarei na próxima seção. Mesmo se for feito check-out de um GPO e, imediatamente depois, check-in sem qualquer alteração, um arquivo será criado por essa ação. Como os GPOs são parte integrante da empresa, a ferramenta rastreia até a possibilidade de uma alteração ocorrer.
O procedimento de Check-out é forçado dentro do AGPM porque deve haver um mecanismo que rastreie alterações de GPO no administrador específico que fez a alteração. Dois administradores não podem fazer check-out do mesmo GPO ao mesmo tempo. Se um administrador fizer check-out do GPO e depois não conseguir devolvê-lo fazendo check-in, será acionado um mecanismo interno que permite que o administrador do AGPM faça o check-in.

Edição de GPOs do AGPM
É possível acessar o arquivo morto do AGPM desde que o cliente AGPM esteja instalado. Uma vez concedida a delegação para edição ou Controle Total dentro da ferramenta AGPM, você poderá editar GPOs armazenados. Depois de feito o check-out de um GPO, ele poderá ser editado se você clicar com o botão direito do mouse no GPO e selecionar a opção de menu Editar. (Observação: se você puder editar apenas alguns dos GPOs dentro do arquivo morto do AGPM, só lhe serão concedidos os recursos delegados sobre alguns dos GPOs, e não para todos os GPOs dentro do arquivo morto.)
Com a aquisição da DesktopStandard, a Microsoft também adquiriu o PolicyMaker, agora renomeado como Preferências de Diretiva de Grupo. Esse conjunto de recursos de Diretiva de Grupo está incluído no GPMC que acompanhará o Windows Server® 2008. As Preferências de Diretiva de Grupo permitem que o administrador configure aplicativos ou componentes do Windows que normalmente não são podem ser configurados via Diretiva de Grupo e que a aplique a certos usuários ou computadores baseados em um conjunto avançado de regras de direcionamento. As Preferências de Diretiva de Grupo estão totalmente integradas ao GPMC e ao AGPM no Windows Server 2008.

Implantação de GPOs do AGPM
O AGPM foi projetado visando eficiência e fluxo de trabalho. Como o gerenciamento de GPOs agora é mais estável e controlado com o uso do AGPM, faz sentido ter administradores com capacidade apenas para editar um GPO, mas não implantá-lo na produção. Dentro do AGPM, isso é controlado sem problemas com a interface, as caixas de diálogo e os mecanismos de trabalho. Por exemplo, se um administrador com direitos somente de edição tentar implantar um GPO, o sistema o bloqueará. Será exibida então ao administrador uma caixa de diálogo para comunicação com um administrador que tenha a permissão Implantar delegada. Esse recurso do fluxo de trabalho enviará um email para os destinatários Para: e CC: e colocará o GPO em um estado exclusivo, que pode ser encontrado na guia Pendente na interface do AGPM. Aqui, o GPO é sinalizado como "Implantação Pendente", o que dá aos administradores uma rápida visão do status de cada GPO que tenha tido ações executadas nele.
Para implantar um GPO pendente, um administrador do AGPM que tenha a delegação de implantação pode simplesmente clicar com o botão direito do mouse no GPO e selecionar a opção de menu Aprovar. Caso o GPO precise ser implantado e esteja listado na guia Controlado (e não na guia Pendente), basta que o mesmo administrador clique com o botão direito do mouse no GPO e selecione Implantar. Como essa permissão delegada já foi concedida, o GPO será implantado imediatamente na produção.

Comparações e relatório de configurações de GPOs do AGPM
A interface do GPMC tem uma caixa de diálogo Configurações eficiente, que pode ser acessada por uma guia de mesmo nome. Essa caixa de diálogo Configurações fornece uma visão completa de todas as configurações definidas no GPO, ajudando você a saber quais das quase 3.000 configurações de diretiva de grupo foram definidas.
Como o AGPM fornece um arquivo morto dos GPOs modificados, a guia Configurações no GPMC não permitirá que você veja as configurações definidas nos GPOs editados. Em vez disso, a interface do AGPM fornece uma solução alternativa para esse recurso, e muito mais.
Para ver as configurações em qualquer GPO, vale a pena primeiro exibir a lista histórica de todas as alterações. Para isso, clique duas vezes em qualquer GPO dentro da guia Controlado no AGPM. A partir dessa interface, é possível clicar com o botão direito do mouse em qualquer versão de GPO e selecionar o Relatório de Configurações. Isso criará um relatório de todas as configurações definidas nessa versão do GPO. O relatório é um arquivo HTML amigável, apesar de poder ser criado também no formato XML.
Embora isso seja útil, mais prática ainda é a capacidade de comparar duas versões do mesmo GPO. Com esse recurso, você pode ver o que mudou de uma versão para outra ou comparar duas versões completamente diferentes do mesmo GPO. (Isso também é muito útil no caso de um GPO cuja implantação está pendente, pois permite visualizar as diferenças entre o GPO pendente e o GPO de produção.) Para ver esse relatório, realce dois GPOs diferentes no histórico e clique com o botão direito do mouse em um deles.
A codificação de cores no relatório de diferenças é muito útil, principalmente quando se quer verificar o que mudou em um GPO pendente antes de implantá-lo. As configurações realçadas em vermelho foram excluídas do GPO de produção e não estão mais disponíveis no GPO pendente. As configurações em azul foram alteradas, enquanto as em verde representam novas alterações no GPO pendente, mas não no GPO de produção.
Esse recurso do AGPM pode poupar muitas horas de comparações manuais trabalhosas de configurações de GPOs. Também é uma forma perfeita de documentar os GPOs ao longo do tempo – cada versão pode ser relatada e impressa.

Recuperação de desastre de GPOs do AGPM
Uma única alteração em um GPO pode criar confusão para um ou mais computadores na rede. Com o GPMC padrão, esse tipo de configuração errônea pode ser corrigida, desde que tenham sido tomadas medidas manuais apropriadas para fazer backups do GPO tanto antes como depois de as alterações serem feitas no GPO de produção. Caso não tenha sido feito nenhum backup, a recuperação desse desastre não será tão simples como se pensa.
O AGPM resolve isso facilmente. Como há backups completos de todos os GPOs no histórico de GPOs, basta abrir o histórico do GPO e selecionar qual versão de GPO você deseja reimplantar.
Com o AGPM, seu gerenciamento de Diretiva de Grupo passa a ser ininterrupto. Durante anos, os administradores queriam poder controlar e gerenciar GPOs offline – o AGPM oferece esse recurso com graça e elegância. Ele também fornece uma solução de gerenciamento de alterações bem robusta, que não só rastreia as principais áreas de um GPO alterado, como fornece recuperação de desastre e comparações de GPO com facilidade. O modelo de delegação incorporado ao AGPM permite canalizar todos os administradores para o AGPM referente a todas as edições em GPOs, o que proporciona backups automatizados de alterações de GPOs e remove qualquer contratempo no GPO de produção. Esse serviço tem tantos recursos que é impossível abordar tudo aqui, mas o manual do AGMP fornece uma boa dose de informações sobre modelos, recuperação de nós/links, configuração de SMTP, e muito mais.

Derek Melber é consultor independente, instrutor e autor. Derek ensina e divulga a tecnologia Microsoft, com foco no Active Directory, na Diretiva de Grupo, na segurança e no gerenciamento de desktops. Ele contribui regularmente para publicações impressas e online e escreveu mais de dez livros sobre tecnologia, como o Microsoft Windows Group Policy Guide (Guia da Diretiva de Grupo do Microsoft Windows; Microsoft Press, 2005). Você pode contatá-lo pelo email derekm@braincore.net.


 Do editor: Convencendo um c&#233;tico
Do editor
Convencendo um cético
Joshua Hoffman

Sou cético. Sim, é verdade. Eu sei que nós, nova-iorquinos, costumamos ser conhecidos pela nossa modesta e confiante ingenuidade, mas, de vez em quando, uma alma enfastiada escapa pelo Túnel Lincoln e estraga tudo. Por ser cético, tenho uma tendência a questionar as coisas. Pode ser difícil me convencer.
Meus colegas em Redmond não vão gostar de ouvir isso, mas eu já era um pouco cético quando a Microsoft introduziu a marca System Center alguns anos atrás. Não me entenda mal! Sou um cara do SMS por inteiro. Como especialista em gerenciamento e implantação de desktop anteriormente, o Systems Management Server (mesmo assim, após a versão 2.0) era uma ferramenta importante no meu arsenal. Mas quando a marca System Center evoluiu e a linha de produtos cresceu, minha tendência natural para questionar despertou.
Isso era realmente necessário? Beneficiaria o cliente no final? Será que diversificar a linha de produtos teria impacto negativo sobre os principais produtos de gerenciamento que conhecemos e adoramos?
Contudo, tenho que admitir que, apesar do meu mau pressentimento inicial, o System Center me convenceu. O SMS e o MOM (agora conhecido como Configuration Manager e Operations Manager) evoluíram para produtos de gerenciamento de nível internacional, adicionando funcionalidade nova e eficiente (e até surpreendente) a cada versão. E seu valor não só não foi diminuído pela adição de novos produtos, como, na realidade, foi consideravelmente amplificado.
Nos últimos meses, exploramos os novos produtos do Configuration Manager e Operations Manager, além de outros complementos anteriores na lista organizada do System Center (como o Capacity Planner, o Desired Configuration Monitor e o Essentials). Como você pode ver, nós nos aprofundamos neste mês em algumas adições novas e muito eficientes.
Edwin Yuen começa nossa cobertura mostrando como o Virtual Machine Manager 2007 não só ajuda a centralizar o gerenciamento da infra-estrutura virtualizada, mas também a romper algumas daquelas incômodas barreiras de migração, permitindo que você consolide hardware herdado em novas máquinas virtuais. Calvin Keaton nos guia pela nova versão do Data Protection Manager, que habilita soluções eficientes de backup baseadas em disco não apenas para dados de usuário padrão (como documentos), mas também para dados empresariais, como as informações críticas armazenadas no Exchange Server. E, por último, Paul Bourgeau apresenta a primeira solução hospedada do System Center – o Asset Inventory Service.
Dê sua opinião sobre as novas adições à linha organizada do System Center. Envie um email para mim no endereço tnmag@microsoft.com. – Joshua Hoffman

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Karandeep Anand, Joseph Dadzie, Ray Hayes, KC Lemson, Bill Scheidel, Jeffrey Snover, Mike Stephens, Kevin Sullivan, Jim Truher e Winni Verhoef.


 Cartas: A palavra est&#225; com os leitores
Cartas
A palavra está com os leitores

Problemas com o VMRCplus
Baixei o VMRCplus, conforme descrito na coluna Utilitário em destaque de outubro de 2007 (technetmagazine.com/issues/2007/10/UtilitySpotlight). Mas se eu tento me conectar a um computador remoto, recebo erros de RPC. Como a interface do administrador do Servidor Virtual é baseada na Web, presumi que esse aplicativo também utilizasse a interface da Web, simplesmente contribuindo para uma experiência mais avançada do cliente em relação à tecnologia Web existente. Infelizmente, é utilizada a API COM.
– Via blogs.technet.com/tnmag.

O VMRCPlus utiliza, de fato, o mesmo caminho de rede que o cliente de controle remoto VMRC fornecido com o Servidor Virtual (que é um aplicativo cliente real, não uma interface da Web). Isso significa que você deve ter acesso às seguintes portas:
  • Porta 5900, que é a porta padrão para o servidor VMRC
  • Porta 1024, que é a porta padrão para o site da Web de administração
  • Portas 137 e 138, as portas TCP e UDP (User Datagram Protocol, protocolo de datagrama de usuário), para a autoridade de concessão de tíquete Kerberos V5
  • Porta 135, que é usada para o mapeador de pontos de extremidade RPC
Você pode ler mais sobre isso em microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_operate_using_VMRC_manageVMs.mspx.

Usando o Windows PE
Li o seu artigo "Noções básicas sobre o Windows PE" (setembro de 2006, technetmagazine.com/issues/2006/09/WindowsPE). Estou tentando colocar o Windows® PE em funcionamento em um ambiente de estação de trabalho VMWare com suporte à rede, mas não consigo fazer com que o Windows PE acesse a rede usando o driver NIC. Inicializo a partir do VMWare com o arquivo ISO de imagem do Windows PE. Ele inicia e um console de comando é exibido, mas quando digito ipconfig, ele não exibe um endereço IP. Também não consigo resolver um endereço a partir do meu servidor DHCP.
– John C.

O problema é que o NIC que o VMware instala, por padrão, não é compatível com o Windows Vista® (que é a base do Windows PE 2.0). O que você precisa fazer é especificar outro tipo de NIC no arquivo de configuração da máquina virtual (arquivo VMX), da seguinte forma:
ethernet0.virtualDev = "e1000"
Isso precisa ser feito editando manualmente o arquivo VMX em um editor de texto como o Bloco de notas, por exemplo – não é possível editar o arquivo com nenhuma GUI. Essa alteração substituirá o NIC virtualizado interno existente pelo NIC de 1 GB da Intel, compatível com o Windows Vista. O mais importante é que substituí-lo por esse valor significa que você não precisa adicionar quaisquer drivers de rede.

Como otimizar o desempenho da consulta do SQL Server
No artigo "Como otimizar o desempenho da consulta do SQL Server" (novembro de 2007, technetmagazine.com/issues/2007/11/SQLQuery), o autor apresentou um exemplo de localização das 20 consultas mais caras executadas, utilizando o SQL Server™ 2005. No entanto, o exemplo não é executável no SQL Server 2000. Você poderia me dar um exemplo que funcionasse nessa versão mais antiga?
– Arun N.

Infelizmente, não há como obter essa informação no SQL Server 2000 – o SQL Server 2000 não coleta nem expõe tais informações para consultas em seu cache de procedimento. Essas informações somente foram disponibilizadas com o novo conjunto de DMV (modos de exibição dinâmicos de gerenciamento) introduzidos no SQL Server 2005.

O aplicativo MIISWorkflow não funciona
Depois de ler o artigo "Crie um fluxo de trabalho de provisionamento passo a passo" (maio de 2007, technetmagazine.com/issues/2007/05/Workflow), tive algumas dúvidas. É oferecido suporte ao aplicativo MIISWorkflow? Ele é compatível com o .NET Framework 2.0? Obtenho o erro "Serviço Indisponível" quando tento abrir o aplicativo fora do Visual Studio®. Eu consigo executá-lo com êxito no modo de depuração, mas se fecho o Visual Studio e tento abrir o aplicativo diretamente, o erro é exibido. O que faz com que o aplicativo interrompa o pool de aplicativos e/ou produza o erro Serviço Indisponível?
– Cliff C.

O aplicativo MIISWorkflow não é um produto com suporte oficial da Microsoft. Ele é fornecido como um código de exemplo somente para fins educacionais.
A melhor fonte para problemas relacionados ao gerenciamento de identidade é o site do gerenciamento de identidades dos fóruns da TechNet, em forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=540&SiteID=17. Esses fóruns são monitorados por membros dos grupos de produtos da Microsoft, bem como por especialistas da comunidade, e estão entre as melhores fontes para suporte direto a problemas como esse.


 Caixa de ferramentas: Novos produtos para profissionais de TI
Caixa de ferramentas
Novos produtos para profissionais de TI
Greg Steen

Assuma o controle do Windows PowerShell
PowerGUI
powergui.org
Se você ainda não começou a usar o Windows PowerShellTM, certamente vai utilizá-lo em breve. O Windows PowerShell está se tornando uma ferramenta administrativa importante no mundo do Windows Server®. Para iniciantes, ele se tornou a base para o gerenciamento baseado em script do Exchange Server 2007.
Para obter o máximo do Windows PowerShell em seu formato nativo, você precisa memorizar uma quantidade razoável de sintaxe, cmdlets e estrutura em geral. É claro, você pode não ter tempo (ou energia mental) para se dedicar a isso. Mas e se você tivesse um console administrativo gráfico centralizado para o gerenciamento de seus scripts? Uma interface de usuário que lhe fornecesse modelos personalizados, recursos de edição do tipo IntelliSense® e uma base de comunidade de compartilhamento de scripts? Com esse tipo de ambiente, você poderia realizar rapidamente o script de tarefas necessárias e saber sempre onde estão localizadas para futura reutilização e referência.
Não se preocupe – não estou apenas provocando você. Esse ambiente baseado em GUI para Windows PowerShell é o que você terá com o PowerGUI, um produto de freeware patrocinado pela Quest Software. Embora ainda estivesse na versão beta durante a publicação desta coluna, esse aplicativo oferece uma GUI administrativa extensível e fácil de usar, com a aparência de um snap-in do MMC (Console de Gerenciamento) da Microsoft® em esteróides.
Na GUI, você pode clicar duas vezes em qualquer um dos scripts fornecidos ou em um dos seus próprios scripts personalizados para que ele seja executado e forneça uma exibição tabular do conjunto de dados retornado. Você pode aplicar filtros de coluna e valor a esses dados, a fim de examinar as informações necessárias. Além disso, você pode adicionar suas próprias colunas personalizadas para fornecer valores computados ou resultados personalizados que atendem às suas necessidades específicas.
A partir da GUI, você pode iniciar um prompt do Windows PowerShell ou do editor de scripts interno do aplicativo. O editor de scripts é o ambiente básico do tipo IntelliSense que lhe mostra a sintaxe dos cmdlets disponíveis, bem como os recursos de edição e de arquivo padrão, como localizar e substituir, imprimir, e recortar/copiar/colar. Você também pode marcar as etapas.
Além disso, o PowerGUI lhe fornece um número de ações personalizáveis e extensíveis que você pode aplicar no seu conjunto de dados. Por exemplo, o script de serviços do sistema local permite que você inicie, pare, suspenda e defina propriedades no serviço designado. Outro recurso interessante é a capacidade de adicionar links entre scripts, permitindo que você vincule scripts por meio de elementos comuns para obter as informações necessárias. Por exemplo, você pode obter uma lista de usuários de um determinado grupo e, em seguida, vinculá-lo a um script que lhe mostra a quantidade de dados em seu diretório base. Além desses recursos, o PowerGUI tem alguns scripts de ações comuns internos para relatório e revisão, que permitem que você despeje seus dados em XML, CSV, HTML, bem como na área de transferência.
Você pode ampliar as ações de scripts individuais e as ações comuns ao adicionar seus próprios scripts ou personalizar um dos modelos fornecidos. A visualização da janela de propriedades de um script permite que você edite o script em vigor ou simplesmente veja como ele funciona.
Outro recurso valioso é a biblioteca da comunidade do site da Web do PowerGUI, que oferece um local para que os usuários compartilhem e baixem scripts, a fim de auxiliar nas tarefas de administração do seu sistema. Nela você encontrará scripts e ações para o gerenciamento do Active Directory®, gerenciamento do Exchange Server, tarefas do Microsoft Operations Manager, tarefas gerais do Windows Server e muito mais. O PowerGUI é um sólido começo para o fornecimento de uma ferramenta administrativa extensível baseada em GUI a ser usada com o Windows PowerShell.

Preço: gratuito
Simplifique o Windows PowerShell com uma interface gráfica do usuário
Simplifique o Windows PowerShell com uma interface gráfica do usuário

Pense ecologicamente ao adquirir produtos
Ferramenta de avaliação ambiental de produto eletrônico (Electronic Product Environmental Assessment Tool)
epeat.net
Quando se pensa ecologicamente, é preciso considerar o custo geral de um computador em todo o seu ciclo de vida. Isso significa a energia coletiva consumida ao fabricar, usar e descartar computadores (para não mencionar outros fatores, como os materiais usados e resíduos gerados). O custo geral, nesses termos, é bem surpreendente. (Para obter uma visão geral dos custos ambientais e financeiros envolvidos, consulte o artigo que Dave Ohara escreveu para a edição de outubro de 2007 da TechNet Magazine, disponível em technetmagazine.com/issues/2007/10/Green.)
Felizmente, cada vez mais indivíduos e corporações estão reconhecendo o impacto, tanto financeiro quanto ambiental, de suas infra-estruturas. E, como resultado, estão começando a procurar produtos que reduzam o consumo de energia. Uma ferramenta para o profissional de TI que está tentando ajudar empresas a solucionarem essa preocupação é fornecida pelo Green Electronics Council (greenelectronicscouncil.org ).
A ferramenta dessa organização, apelidada de EPEAT (abreviação de Electronic Product Environmental Assessment Tool), avalia os produtos eletrônicos de acordo com 51 critérios ambientais diferentes – 23 desses critérios são necessários e 28 são opcionais. As classificações são as seguintes: bronze (o que quer dizer que o produto atende aos critérios necessários da linha de base, prata (que é o necessário mais 50% dos critérios opcionais) e ouro (que atende aos critérios necessários mais 75% ou mais dos elementos opcionais).
Os critérios cobrem o ciclo de vida total de um produto, desde os materiais selecionados para a fabricação ao consumo de energia durante o uso e no término do gerenciamento da vida útil. Os critérios necessários do padrão abrangem predominantemente declarações do impacto de um produto, como declarar quanto de um produto é feito de plástico reciclado, identificar materiais contidos no produto que requerem manejo especial e declarar quanto da embalagem de um produto é de material reciclado. (Todos os produtos com registro EPEAT atualmente atendem aos padrões ENERGYSTAR 3.0; e até o final de janeiro de 2008, todos estarão em conformidade com o novo padrão ENERGYSTAR 4.0.)
Além disso, os produtos certificados devem ter um serviço de “devolução” para o produto e suas baterias recarregáveis (se aplicável). Outra exigência interessante é a disponibilidade de uma garantia de três anos ou contrato de serviço, que deveria, na teoria, ajudar a prolongar a vida de um dispositivo, reduzindo assim o impacto geral de uma alta taxa de rotatividade.
Alguns dos padrões opcionais abrangem a eliminação de determinados metais pesados (como o cádmio), design modular, certificação de terceiros de práticas e diretivas ambientais da empresa, e vários níveis percentuais de capacidade de reciclagem.
Atualmente, há quatro categorias de produtos disponíveis: desktops, sistemas integrados, monitores e notebooks. As categorias de produtos continuarão se expandindo, com a inclusão dos padrões do servidor em algum momento em 2009.
E a maioria dos principais fabricantes está participando. Isso foi auxiliado pela Executive Order 13423 de janeiro de 2007, que estipula que qualquer agência federal que adquira produtos eletrônicos deverá atender, pelo menos, a 95% dos requisitos necessários a um produto eletrônico registrado na EPEAT (Electronic Product Environmental Assessment Tool) (whitehouse.gov/news/releases/2007/01/20070124-2.html).
Portanto, se você ainda não estiver gerenciando o impacto ambiental de suas compras, deverá reservar um momento para verificar a ferramenta de avaliação EPEAT, a fim de começar a considerar os ganhos ambientais (e financeiros) que podem ser obtidos com a sua próxima aquisição de produto.

Preço: gratuito
Use a EPEAT para avaliar o impacto ambiental de suas compras de hardware
Use a EPEAT para avaliar o impacto ambiental de suas compras de hardware

Resenha de livro
Windows Vista Administrator's Pocket Consultant
microsoft.com/MSPress/books/9588.aspx
Se você estiver pronto para distribuir o Windows Vista® na sua organização, o Windows Vista Administrator's Pocket Consultant (Microsoft Press, 2006), de William Stanek, pode ajudá-lo a ir diretamente para os novos recursos e funcionalidades. Os que já tiverem lido outros livros da série Administrator's Pocket Consultant reconhecerão o formato deste livro e o seu aprofundamento de conteúdo, semelhante aos outros nesta série. Ele não apresenta todas as complexidades, mas oferece uma boa e ampla visão geral dos recursos e funcionalidades, execução de tarefas administrativas específicas e uma atualização sobre como as coisas funcionam. Além disso, o conteúdo é definitivamente voltado para os administradores de sistema, em oposição aos usuários finais gerais.
O livro começa com uma introdução ao Windows Preinstallation Environment 2.0, juntamente com uma breve visão geral dos utilitários que você terá à sua disposição durante a instalação automatizada ou interativa. Então, o livro passa para o gerenciamento de sistemas Windows Vista, mostrando a você como usar ferramentas como o msconfig para solucionar ou adaptar sua instalação, além de apresentar novos recursos, como Versões anteriores, que permite que você restaure uma pasta ou arquivo a um estado anterior. Além disso, você terá uma introdução às ferramentas que o ajudarão a gerenciar o hardware e dispositivos nos sistemas de destino.
Em seguida, o livro aborda como adaptar a experiência do Windows® para seus usuários finais ao personalizar a interface e a área de trabalho. Por exemplo, ele mostra como reduzir o uso dos recursos da proteção de tela, adaptar os programas da inicialização e do menu iniciar, bem como configurar a barra lateral do Windows. Além disso, o livro também mostra como criar barras de ferramentas pessoais, a fim de proporcionar aos seus usuários finais rápido acesso a pastas e arquivos compartilhados a partir da barra de tarefas.
A seção sobre instalação e manutenção dos programas e recursos do Windows Vista aborda ferramentas como o Gerenciador de Software, que permite que você veja rapidamente os programas na inicialização de um sistema, os programas atualmente em execução, os provedores de serviços Winsock e os programas conectados à rede. Em seguida, o livro aborda o gerenciamento de usuários, perfis, preocupações relativas à mobilidade e diretivas de computadores e usuários, além de gerenciamento de discos, segurança de arquivos e compartilhamento de recursos. Mais especificamente, ele explica como criar usuários, gerenciar o logon do Windows por meio da diretiva de grupos e criar entradas de conjunto de chaves que facilitarão o acesso dos usuários a recursos protegidos com senha.
A seção sobre mobilidade aborda como a nova configuração de rede alternativa permite que você especifique uma configuração “para o escritório” e uma configuração “móvel”. Os usuários poderão alternar facilmente entre os dois modos.
No capítulo "Managing File Security and Resource Sharing" (Gerenciando a segurança de arquivos e o compartilhamento de recursos), são apresentadas noções básicas sobre como configurar permissões em arquivos e pastas NTFS, e sobre como funcionam as Permissões especiais do Windows Vista (e como controlá-las). Você também aprenderá como criar, conectar-se e manter conexões a recursos compartilhados.
Em termos de gerenciamento de disco, o livro apresenta uma introdução à configuração de cota de disco, que o ensina não somente a criar, exibir, atualizar e excluir cotas de disco, mas também a importar e exportar essas configurações para reutilização.
Há uma apresentação bem detalhada de como funciona a pilha de rede IPv4/IPv6 dupla no Windows Vista. Além disso, você aprenderá como configurar seus adaptadores de rede para seu ambiente.
O livro conclui com uma seção sobre como otimizar o Windows Vista para garantir a melhor experiência para seus usuários, seguida por um breve capítulo sobre técnicas gerais de solução de problemas. Nessa seção, você aprenderá como configurar a assistência remota, manter um sistema saudável por meio de verificações programadas de disco e desfragmentação, bem como a criar backups. Em resumo, essa é uma referência rápida e fácil de seguir para a administração do Windows Vista.

Preço: US$ 29,99 para venda direta.

Monitore seu site da Web
Pingdom.com
pingdom.com
Como disse antes e simplesmente não canso de afirmar: uma abordagem pró-ativa para a administração de sistemas resultará em menos estresse e o ajudará a evitar momentos constrangedores, como quando o seu chefe envia um email dizendo: “Você sabia que o site está inativo”?
Uma boa ferramenta de monitoramento de rede é essencial para essa abordagem. A maioria de vocês, se não todos, provavelmente já empregou algum tipo de servidor de monitoramento de rede externo. Mas e quanto àqueles que estão preocupados com uma presença global, na qual você precisará garantir a disponibilidade de seus serviços voltados para a Internet?
O Pingdom.com, um ASP (application service provider, provedor de serviços de aplicativo), fornece um serviço de monitoramento automatizado simples mas eficaz. Os servidores de ASP estão distribuídos em várias localizações globais, proporcionando a você uma idéia muito melhor do que os usuários estão realmente vivenciando – em oposição à dependência de um monitor de serviço externo de fonte única.
Para isso, inscreva-se em uma conta e defina sua localidade, fuso horário, país, formato de data e de número que atendam às suas necessidades. Em seguida, configure seus contatos fornecendo nomes, números de telefone SMS e endereço de email para notificação. Depois disso, crie uma verificação de monitoramento, definindo um nome, uma resolução de verificação, o tipo de verificação de monitoramento a ser realizado na resolução e o tipo, os contatos e os intervalos periódicos de notificações para a verificação.
O pacote de conta padrão lhe fornecerá as resoluções de verificação, variando de 1 a 60 minutos, permitindo que você adapte as solicitações para o serviço que está monitorando. A notificação pode ser enviada aos seus contatos por email ou SMS. Além disso, você pode definir o número de vezes que o ping de serviço deverá falhar antes de a notificação ser enviada, junto com quantos ciclos de falha devem ocorrer antes de você ser notificado novamente (até um máximo de quatro lembretes). Além disso, você pode solicitar que o pingdom o notifique quando o seu serviço efetuar backup – isso é excelente para verificações no período de manutenção de serviço ou de site da Web. Falando em manutenção, você também pode pausar ou interromper as verificações, a fim de evitar falsos positivos durante as tarefas programadas.
O serviço oferece aos usuários quatro tipos básicos de verificações: um sensor HTTP, um sensor de porta TCP, um sensor ping e um sensor UDP. O sensor HTTP permite que você defina a URL/IP, se a solicitação será através de SSL, da porta, de uma combinação de senha e nome de usuáro para autenticação básica ou de uma cadeia de verificação de conteúdo inclusivo/exclusivo básica. O sensor da porta TCP permite que você defina a porta de serviço e o IP/domínio a ser verificado. O sensor de ping permite que você defina o IP ou domínio a ser verificado via ICMP. Além disso, o sensor de UDP é determinado pelo IP/domínio, uma porta, a cadeia a ser enviada para essa combinação e a cadeia de resposta esperada. Na prática, você poderia verificar a disponibilidade do seu site da Web, servidor FTP, servidor SMTP e muito mais a partir de vários locais no mundo.
O serviço também fornece vários relatórios para ajudá-lo a visualizar dados históricos. Com esses relatórios, você poderá ver o percentual de tempo de atividade de determinado mês e o tempo médio de resposta para esse período de tempo. Você também poderá obter uma visualização detalhada de cada instância de verificação, exibindo o carimbo de data e hora, o tempo de resposta e o servidor a partir do qual a verificação foi realizada. Além disso, você obtém uma visualização das notificações, mostrando quando, quantas, para quem e por quais meios elas foram enviadas para um período de tempo especificado. Você pode disponibilizar esses relatórios publicamente, de modo que os outros membros da sua organização possam ver as estatísticas do serviço. Se você tiver sua própria NOC (Central de Operações de Rede) personalizada, o pingdom.com também fornecerá uma API de serviço da Web que você poderá usar para consultar essas informações, permitindo que você integre o serviço em seus atuais modos de exibição de painel.

Preço: US$ 9,95 por mês.
O Pingdom.com monitora seus serviços da Web com uma perspectiva global
O Pingdom.com monitora seus serviços da Web com uma perspectiva global

Greg Steen é um profissional de tecnologia, empresário e entusiasta que está sempre em busca de novas ferramentas para facilitar as operações, o controle de qualidade e o desenvolvimento para os profissionais de TI.


 Perguntas e respostas do Exchange: Adicionando prompts de voz, escolhendo um PBX, e muito mais
Perguntas e respostas do Exchange
Adicionando prompts de voz, escolhendo um PBX, e muito mais
Seema Rahman

P: Ouvi dizer que a Unificação de Mensagens do Exchange não oferece alta disponibilidade nem clustering. É verdade?
R: Embora não haja suporte para a Unificação de Mensagens em uma configuração de cluster ou de balanceamento de carga de rede, é certo poder conseguir uma solução de alta disponibilidade a partir de certos gateways. A chave é designar vários servidores de Unificação de Mensagens para fazer rodízio do tráfego. Também é possível providenciar para que determinado tráfego seja roteado para um servidor de Unificação de Mensagens específico, desde que o gateway tenha os recursos de roteamento avançado necessários. Por exemplo, você pode designar um servidor de Unificação de Mensagens para acesso do assinante e outro para chamadas do atendedor automático. Isso permite equilibrar o tráfego de Unificação de Mensagens com base na infra-estrutura e nas tendências no ambiente.

P: Posso configurar prompts de voz para o número de telefone público da minha empresa com a Unificação de Mensagens do Exchange?
R: Pode, sim. E um atendedor automático também. O artigo "Gerenciando prompts de áudio personalizados" em technet.microsoft.com/aa998818 oferece etapas detalhadas sobre como configurar esse recurso.

P: Como sei se a minha central privada de comutação telefônica (PBX) é compatível com a Unificação de Mensagens do Exchange?
R: Certos gateways são testados pela Microsoft e recomendados para uso com a Unificação de Mensagens do Exchange. Os fornecedores que produzem esses gateways fornecem uma lista de PBXs que funcionam com o gateway deles. Se o seu PBX for listado por algum dos fornecedores, ele será compatível com a Unificação de Mensagens do Exchange.
O artigo "Telephony Advisor for Exchange Server 2007" (Supervisor de telefonia para o Exchange Server 2007), disponível em microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx, fornece uma lista de gateways com suporte e muitas outras informações pertinentes.

P: Preciso adicionar algum hardware especial ao meu sistema telefônico para usar a Unificação de Mensagens do Exchange?
R: Um servidor de Unificação de Mensagens do Exchange funciona como provedor de caixa postal. Para trabalhar com o seu sistema telefônico atual, pode ser necessário um hardware que você não tem.
Se estiver usando um IP-PBX com suporte, você não precisará de hardware adicional. No entanto, é provável que precise de algumas configurações específicas no IP-PBX para fazê-lo funcionar com a Unificação de Mensagens.
Caso esteja usando algo diferente de um IP-PBX com suporte, você precisará primeiro determinar se esse hardware é compatível com um dos gateways para os quais há suporte. Também será necessário ter um gateway VoIP com suporte.
As informações em microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx incluem uma lista de hardware com suporte, especificamente IP-PBXs e gateways. Visite o site com freqüência porque a lista é atualizada sempre que a Microsoft certifica novos hardwares. Você também pode consultar o especialista regional de Unificação de Mensagens para determinar os requisitos de hardware para o seu ambiente.

P: Como a Unificação de Mensagens fornece suporte a fax?
R: Atualmente, a Unificação de Mensagens fornece um recurso de fax de entrada que permite que um fax enviado para uma extensão do usuário habilitada para Unificação de Mensagens acabe na Caixa de Entrada do usuário como uma mensagem de email, com a mensagem do fax anexada no formato TIFF. Uma visão geral detalhada está disponível em technet.microsoft.com/ bb232022.

P: Tenho um IP/PBX Nortel CS1000 e quero usar a Unificação de Mensagens no Exchange Server 2007, mas não sei como reunir esses dois sistemas. Posso usar o IP/PBX Nortel CS1000 como gateway ou somente Intel e AudioCodes têm suporte como gateways? Também preciso que o sistema Exchange autentique no Servidor CS1000.
Um Nortel CS1000 é um IP/PBX com suporte, desde que você esteja executando a versão 5.0 do firmware para o IP/PBX. Não será necessário nenhum hardware adicional para fazê-lo funcionar. O site da Nortel contém observações para a configuração do IP-PBX em support.nortel.com/go/main.jsp?cscat=docdetail&id=626197&poid=14261. Gateways, PBXs e versões de firmware com suporte podem ser encontrados em microsoft.com/technet/prodtechnol/exchange/pbx-partners.mspx.

Seema Rahman trabalha na Microsoft há seis anos. Como engenheira de escalonamento de suporte, ela ajuda os clientes a resolverem problemas complexos com o Exchange Server. Seema gostou em especial do período em que participou da equipe do Exchange 2007 Beta, na qual seu foco era Unificação de Mensagens.


 Utilit&#225;rio em destaque: Assistente da transfer&#234;ncia f&#225;cil do Windows
Utilitário em destaque
Assistente da transferência fácil do Windows
Lance Whitney
Este artigo se baseia em uma versão de pré-lançamento do Assistente da transferência fácil do Windows. Todas as informações deste artigo estão sujeitas a alterações.

Está na hora de migrar os usuários de seus computadores antigos do Windows® XP para as novas máquinas do Windows Vista®. O maior fardo em qualquer migração é reinstalar os aplicativos dos usuários nos novos computadores – e se certificar que eles funcionem. Agora, uma ferramenta gratuita da Microsoft pode poupá-lo dessas incontáveis reinstalações. O WETC (Windows Easy Transfer Companion, Assistente da transferência fácil do Windows) copia os principais programas do Windows XP para o Windows Vista.
Atualmente na versão beta, o WETC é diferente do assistente de transferência fácil no Windows Vista. Enquanto o assistente copia arquivos de dados, configurações de programa e perfis de usuário, o WETC copia os aplicativos por completo, embora somente do Windows XP SP2 para o Windows Vista. Você deve executar a transferência em uma conta de administrador.
Instale o WETC nos computadores de origem e de destino. Os computadores podem se comunicar através de uma rede ou através do cabo USB de transferência fácil. O driver para o cabo de transferência fácil é incluído no Windows Vista; para o Windows XP, você precisará instalar o driver usando o CD do produto.
O WETC fornece uma lista de categorias dos aplicativos transferíveis
O WETC fornece uma lista de categorias dos aplicativos transferíveis
Depois de conectar o cabo, inicie o WETC na máquina com Windows XP. O utilitário verificará o disco rígido, coletará as informações básicas do sistema e analisará todos os programas instalados. Quando esse processo for concluído, execute o WETC no computador com Windows Vista. O utilitário se comunicará com a máquina com Windows XP, a fim de exibir uma lista de todos os aplicativos detectados, divididos em três categorias (consulte a captura de tela anterior):
  1. Programas transferidos com êxito – programas que serão transferidos sem problemas e serão executados no computador com Windows Vista.
  2. Programas transferidos com possíveis limitações – programas que podem ser transferidos mas podem não ser executados corretamente.
  3. Programas que não serão transferidos – programas que não serão executados no Windows Vista e não serão incluídos na transferência.
Para cada programa que não for transferido com êxito, o WETC apresentará uma breve explicação dos motivos. Geralmente, os aplicativos não podem ser copiados porque estão faltando informações do instalador ou outros dados importantes, são incompatíveis com o Windows Vista ou já estão na máquina do Windows Vista. Além disso, o WETC não copiará tipos específicos de aplicativos, como utilitários do sistema e antivírus. Ele também não transferirá estruturas do SO, como o Microsoft .NET – você precisará instalá-las no Windows Vista antes de copiar quaisquer aplicativos que as requeiram.
Na lista de programas, verifique os aplicativos que deseja copiar. Uma tela de ajuda pode auxiliá-lo na sua decisão e fornecer soluções para eventuais problemas. Você também pode salvar um relatório antes da transferência, relacionando todos os programas que serão ou não transferidos.
A transferência será então realizada, copiando os dados relacionados a cada programa. Ao término, uma mensagem de status lhe informará quais programas foram copiados e se ocorreram erros. Você pode salvar um relatório detalhado após a transferência. Depois de sair do WETC, reinicie o computador com Windows Vista, faça login e execute os programas transferidos, a fim de se certificar de que eles funcionam.
Problemas? A pasta de programas do WETC no Windows Vista inclui um atalho para uma ferramenta de recursos com um recurso de desfazer que remove todos os aplicativos copiados na máquina com Windows Vista, mas essas informações expiram em três dias. Você pode saber mais sobre o Assistente da transferência fácil do Windows e baixar a versão mais recente em support.microsoft.com/kb/931696.

Lance Whitney é consultor de TI, instrutor e redator técnico. Ele passa incontáveis horas fazendo ajustes em estações de trabalho e servidores do Windows. Jornalista por formação, ingressou corajosamente no mundo de TI há 15 anos.


 The Cable Guy: Aprimoramentos do DNS no Windows Server 2008
The Cable Guy
Aprimoramentos do DNS no Windows Server 2008
Joseph Davies
Este artigo se baseia em uma versão de pré-lançamento do Windows Server 2008. Todas as informações deste artigo estão sujeitas a alterações.

A Microsoft tem incluído um serviço Servidor DNS (sistema de nome de domínio) em versões do Windows Server desde o Windows NT 4.0. O DNS é um banco de dados hierárquico e distribuído que contém mapeamentos de nomes de domínio DNS para vários tipos de dados, como endereços IP. Com o Windows Server 2008, o serviço Servidor DNS inclui novos recursos, como
carregamento de zona em segundo plano, aprimoramentos para oferecer suporte a IPv6, suporte a controladores de domínio somente leitura (RODCs) e a capacidade de hospedar nomes globais de rótulo único.

Carregamento de zona em segundo plano
O serviço Servidor DNS do Windows Server® 2008 acelera a recuperação de dados ao implementar o carregamento de zona em segundo plano. No passado, empresas com zonas contendo um grande número de registros no Active Directory® sofriam com atrasos de uma hora ou mais quando o serviço Servidor DNS do Windows Server 2003 tentava recuperar os dados DNS do Active Directory na reinicialização. Durante esses atrasos, o servidor DNS ficava indisponível para solicitações do cliente DNS do serviço para qualquer uma de suas zonas hospedadas.
Para resolver essa questão, o serviço Servidor DNS do Windows Server 2008 recupera dados de zona do Active Directory em segundo plano depois de iniciar para poder responder a solicitações de dados de outras zonas. Quando o serviço é iniciado, ele cria um ou mais threads de execução para carregar as zonas que são armazenadas no Active Directory. Como há threads separados para carregar as zonas baseadas no Active Directory, o serviço Servidor DNS pode responder a consultas enquanto o carregamento de zona está em andamento. Se um cliente DNS solicitar dados em uma zona que já tenha sido carregada, o servidor DNS responderá adequadamente. Caso a solicitação seja para dados em uma zona que ainda não tenha sido totalmente recuperada, o servidor DNS recuperará os dados específicos do Active Directory.
Essa capacidade de recuperar dados específicos do Active Directory durante o carregamento de zona proporciona uma vantagem adicional em relação ao armazenamento de informações de zona em arquivos: o serviço Servidor DNS pode responder a solicitações imediatamente. Quando a zona é armazenada em arquivos, o serviço precisa ler seqüencialmente o arquivo até encontrar os dados.

Suporte avançado a IPv6
O IPv6, que já foi abordado em edições anteriores desta coluna, é um novo conjunto de protocolos padrão da Internet. O IPv6 foi projetado para resolver muitos dos problemas da versão atual (IPv4), como esgotamento de endereços, segurança, configuração automática e necessidade de extensibilidade.
Uma diferença no IPv6 é que seus endereços têm 128 bits de comprimento, enquanto os endereços IPv4 têm apenas 32 bits. Os endereços IPv6 são expressos em notação hexadecimal separada por dois-pontos. Cada dígito hexadecimal corresponde a 4 bits do endereço IPv6. Um endereço IPv6 totalmente expresso tem 32 dígitos hexadecimais em 8 blocos, separados por dois-pontos. Um exemplo de endereço IPv6 totalmente expresso é FD91:2ADD:715A:2111:DD48:AB34:D07C:3914.
A resolução de nomes direta para endereços IPv6 usa o registro DNS de Host do IPv6, conhecido como registro AAAA (pronuncia-se "quatro As"). Para resolução de nomes inversa, o IPv6 usa o domínio IP6.ARPA, e cada dígito hexadecimal no endereço IPv6 de 32 dígitos se torna um nível separado na hierarquia de domínio reverso em ordem inversa. Por exemplo, o nome de domínio da zona de pesquisa inversa para o endereço FD91:2ADD:715A:2111:DD48:AB34:D07C:3914 é 4.1.9.3.C.7.0.D.4.3.B.A.8.4.D.D.1.1.1.2.A.5.1.7.D.D.A.2.1.9.D.F.IP6.ARPA.
O serviço Servidor DNS do Windows Server 2003 dá suporte a resolução de nomes direta e inversa para o IPv6, embora o suporte não seja totalmente integrado. Por exemplo, para criar um registro de endereço IPv6 (o registro AAAA que acabamos de mencionar) no snap-in Gerenciador DNS do Windows Server 2003, clique com o botão direito do mouse na zona, clique em Outros Registros Novos e depois clique duas vezes no Host do IPv6 (AAAA) como o tipo de registro do recurso. Para adicionar um registro AAAA no snap-in Gerenciador DNS do Windows Server 2008, clique com o botão direito do mouse no nome da zona e depois clique em Novo Host (A ou AAAA). Na caixa de diálogo Novo Host, você pode digitar um endereço IPv4 ou IPv6. A Figura 1 mostra um exemplo.
Figura 1 Caixa de diálogo Novo Host
Figura 1 Caixa de diálogo Novo Host
Outro exemplo de melhor suporte a IPv6 é para zonas inversas IPv6. Para criar uma zona de pesquisa inversa no snap-in Gerenciador DNS do Windows Server 2003, é preciso digitar manualmente o nome da zona inversa na página correspondente do Assistente de Nova Zona. Um exemplo de um nome de zona inversa no DNS é 1.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa (para o prefixo de sub-rede IPv6 2001:db8:0:1::/64, totalmente expresso como 2001:0db8:0000:0001::/64).
As zonas inversas IPv6 no snap-in Gerenciador DNS do Windows Server 2008 agora estão totalmente integradas ao Assistente de Nova Zona. Existe uma nova página do assistente que solicita que você selecione uma zona de pesquisa inversa IPv4 ou IPv6. No caso de uma zona de pesquisa inversa IPv6, basta digitar o prefixo de sub-rede IPv6 para que o assistente a crie automaticamente. A Figura 2 mostra um exemplo.
Figura 2 Nomeando uma zona de pesquisa inversa IPv6
Figura 2 Nomeando uma zona de pesquisa inversa IPv6
Outro aprimoramento para zonas inversas é a forma como o snap-in Gerenciador DNS exibe registros ponteiro (PTR) IPv6. A Figura 3 mostra como o snap-in Gerenciador DNS do Windows Server 2003 exibe um registro PTR.
Figura 3 Registro PTR para IPv6 no Windows Server 2003
Figura 3 Registro PTR para IPv6 no Windows Server 2003
Embora essa exibição reflita com precisão a estrutura do namespace DNS para nomes de domínio inverso IPv6, ela dificulta o gerenciamento de registros PTR para endereços IPv6. A Figura 4 mostra como o snap-in Gerenciador DNS do Windows Server 2008 exibe um registro PTR.
Figura 4 Registro PTR para IPv6 no Windows Server 2008
Figura 4 Registro PTR para IPv6 no Windows Server 2008
O serviço Servidor DNS do Windows Server 2003 dá suporte a operação por IPv6, mas ela precisa ser habilitada manualmente com o comando dnscmd /config /EnableIPv6 1. O Windows Server 2008, por outro lado, oferece suporte a operação por IPv6 por padrão. A ferramenta de linha de comando Dnscmd.exe foi atualizada para aceitar endereços IPv6 em opções de linha de comando. Além disso, agora o serviço Servidor DNS pode enviar consultas recursivas a servidores somente IPv6, e a lista encaminhadora de servidores pode conter endereços tanto IPv4 como IPv6.
Para obter mais informações sobre IPv6 e como o Windows® dá suporte a ele, consulte microsoft.com/ipv6.

Suporte a controlador de domínio somente leitura
O Windows Server 2008 também introduz o RODC, um novo tipo de controlador de domínio que contém uma cópia somente leitura de informações do Active Directory e que, embora possa executar funções do Active Directory, não pode ser configurado diretamente. Os RODCs são menos vulneráveis a ataques e podem ser colocados em locais onde a segurança física do controlador de domínio não possa ser garantida ou a rede contenha hosts potencialmente mal-intencionados.
Para RODCs, o serviço Servidor DNS do Windows Server 2008 oferece suporte ao novo tipo de zona primária somente leitura. Quando um computador se torna um RODC, ele replica uma cópia somente leitura completa de todas as partições de diretório de aplicativos que o DNS usa, inclusive a partição de domínio, ForestDNSZones e DomainDNSZones. Isso garante que o serviço Servidor DNS executado no RODC tenha uma cópia somente leitura completa de qualquer zona DNS armazenada nas partições de diretório de um controlador de domínio que não seja um RODC. O conteúdo de uma zona primária somente leitura pode ser exibido em um RODC, mas não alterado. Qualquer alteração no conteúdo da zona deve ser feita em um controlador de domínio que não seja um RODC.

Zona GlobalNames
Resolução de nomes com a zona GlobalNames
Depois de implantada a zona GlobalNames, quando um cliente DNS baseado no Windows Vista tenta resolver um nome de rótulo único, ela anexa o sufixo DNS primário ao nome de rótulo único e envia a solicitação de consulta de nome ao respectivo servidor DNS.
Se o nome não for encontrado, o cliente DNS enviará solicitações adicionais para a combinação do nome de rótulo único com os sufixos na lista de pesquisa de sufixos DNS correspondente (se configurada). Caso nenhum desses nomes resolva, o cliente solicitará a resolução usando o nome de rótulo único.
O servidor DNS procura o nome de rótulo único na zona GlobalNames. Se ele aparece ali, o servidor DNS envia o FQDN ou o endereço IPv4 resolvido de volta para o cliente DNS. Caso contrário, o computador cliente DNS converte o nome para um nome NetBIOS e usa técnicas de resolução de nomes NetBIOS, como o WINS. Não é necessária nenhuma alteração no serviço Cliente DNS para habilitar a resolução de nomes de rótulo único na zona GlobalNames.

O Windows Server 2008 e o Windows Vista® dão suporte ao NetBIOS pelo protocolo TCP/IP (NetBT). O NetBT usa nomes NetBIOS para identificar aplicativos NetBIOS de camada de sessão. Embora a resolução de nomes NetBIOS com o WINS não seja necessária para versões atuais do Windows que se baseiam em DNS e em aplicativos de rede baseados no Windows Sockets para resolução de nomes, muitos clientes da Microsoft implantam o WINS em suas redes para dar suporte a aplicativos NetBT mais antigos e fornecer resolução de nomes para nomes de rótulo único em suas organizações. Normalmente, os nomes de rótulo único referem-se a servidores importantes, conhecidos e amplamente usados de uma organização, como servidores de email, servidores Web centrais ou os servidores para aplicativos de linha de negócios.
A fim de permitir que esses nomes de rótulo único sejam resolvidos em uma organização usando somente DNS, convém adicionar registros A aos vários domínios DNS da organização para que um cliente DNS baseado no Windows possa resolver o nome sem levar em conta a lista de pesquisa de sufixos ou o sufixo de domínio DNS atribuído.
Suponha, por exemplo, que a organização contoso.com tenha um servidor Web central chamado CWEB que é membro do domínio central.contoso.com. Para implementar um nome de rótulo único para o servidor CWEB quando clientes DNS puderem ser atribuídos ao sufixo de domínio DNS wcoast.contoso.com, central.contoso.com ou ecoast.contoso.com, o administrador da rede deve criar dois registros A adicionais para cweb.wcoast.contoso.com e cweb.ecoast.contoso.com. No entanto, não se esqueça de que registros A criados manualmente para nomes de rótulo único devem ser mantidos para alterações na atribuição de endereço IPv4 ou para novos nomes.
Se contoso.com já estiver usando o WINS para aplicativos NetBT mais antigos, um administrador da rede poderá implementar a resolução de nomes para o nome de rótulo único CWEB adicionando um registro WINS estático único à infra-estrutura WINS. Se o endereço IPv4 mudar, somente o registro WINS estático único precisará ser alterado. Como nomes de rótulo único são mais fáceis de gerenciar no WINS, muitas redes baseadas no Windows usam registros WINS estáticos para esses nomes.
Para fornecer uma solução de nome de rótulo único no DNS que seja gerenciada facilmente como registros WINS estáticos, o serviço Servidor DNS do Windows Server 2008 oferece suporte a uma nova zona chamada GlobalNames para armazenar nomes de rótulo único. O escopo da replicação dessa zona normalmente é uma floresta, que fornece resolução de nomes de rótulo único em uma floresta inteira do Active Directory. Além disso, a zona GlobalNames pode dar suporte a resolução de nomes de rótulo único através de uma organização que contenha várias florestas quando você usa registros de recurso de serviço local (SRV) para publicar o local da zona GlobalNames.
Ao contrário do WINS, a zona GlobalNames tem por finalidade fornecer resolução de nomes de rótulo único para um conjunto limitado de nomes de host, geralmente os servidores centrais e críticos de uma organização que são gerenciados pelo departamento de TI. A zona GlobalNames não deve ser usada para armazenar os nomes de desktops ou outros computadores cujos endereços IPv4 possam sofrer alterações. Além disso, ela não oferece suporte, sob nenhuma circunstância, a atualizações dinâmicas do DNS. Ela é mais usada para armazenar registros de recurso de alias (CNAME) que mapeiam um nome de rótulo único para um FQDN (nome de domínio totalmente qualificado). Para redes que estejam usando o WINS, a zona GlobalNames geralmente armazena registros de recurso para nomes gerenciados por TI que já estejam configurados estaticamente no WINS.
A zona GlobalNames fornecerá resolução de nomes de rótulo único somente quando todos os servidores DNS autoritativos estiverem executando o Windows Server 2008. No entanto, outros servidores DNS que não sejam autoritativos para qualquer zona podem executar versões anteriores do Windows ou outros sistemas operacionais. A zona GlobalNames deve ser exclusiva na floresta.
Para fornecer o máximo de escalabilidade e desempenho, a zona GlobalNames deve estar integrada ao Active Directory e configurar cada servidor DNS autoritativo com uma cópia local dela. A realização dessa tarefa é necessária para dar suporte à implantação da zona GlobalNames em várias florestas.
Para obter mais informações sobre o suporte a DNS no Windows e sobre como implantar a zona GlobalNames, consulte a página da Web do DNS da Microsoft em microsoft.com/dns.

Joseph Davies é redator técnico da Microsoft. Além disso, ensina e escreve sobre assuntos relacionados a sistemas de rede do Windows desde 1992. Ele tem cinco livros publicados pela Microsoft Press e é autor da coluna mensal online da TechNet, The Cable Guy.


 Windows PowerShell: Preven&#231;&#227;o contra c&#243;digo mal-intencionado
Windows PowerShell
Prevenção contra código mal-intencionado
Don Jones

Você se lembra de quando o Windows Vista ainda estava na versão beta e havia muitos rumores sobre uma versão muito recente de um novo código de shell da linha de comando chamado "Monad"? (Esse, é claro, viria a ser conhecido como o Windows PowerShell.) Na época, havia muitas informações predominantes na mídia sobre o “primeiro vírus do Windows Vista”. Na
realidade, o “vírus" era apenas um script de malware de verificação de conceito destinado ao "Monad". Para executar o script, o próprio “Monad” precisaria ter sido especialmente configurado – o script não funcionaria nas configurações padrão. Além disso, quando esses relatórios surgiram, a Microsoft já havia anunciado que o "Monad" não seria fornecido como parte do Windows Vista®. Em resumo, toda a situação foi “muito barulho por nada” (ou, pelo menos, muito sobre muito pouco).
À medida que o Windows PowerShellTM se torna mais conhecido – ele já foi baixado mais de um milhão de vezes – aumentam as possibilidades de que alguém o utilize para criar um script malicioso. O recurso de gravar um script potencialmente perigoso no Windows PowerShell é uma certeza; qualquer ferramenta de administração – incluindo o Windows PowerShell, o cmd.exe e o VBScript – pode ser usada maliciosamente. Assim, você não pode presumir que determinado arquivo PS1 é inofensivo.
Felizmente, o Windows PowerShell está configurado por padrão para não executar scripts, de modo que o script malicioso precisará da sua ajuda para que seja executado. Neste mês, gostaria de prever como isso provavelmente acontecerá. O objetivo disso não é desqualificar o Windows PowerShell – penso que a Microsoft fez um excelente trabalho ao desenvolver um shell de script que evita muitos riscos. No entanto, essa é uma discussão válida somente para ajudá-lo a se preparar e estar pronto para evitar um possível ataque.

Seguro por padrão
É válido salientar que o Windows PowerShell foi a primeira linguagem desenvolvida pela Microsoft depois da famosa iniciativa Trustworthy Computing. O guru da segurança, Michael Howard (autor do livro Writing Secure Code), foi o "contato de segurança" da equipe do Windows PowerShell. Ele ajudou a garantir que o código fosse escrito com o máximo de segurança possível e, o mais importante, que o shell fosse configurado com a maior proteção possível pronta.
Primeiramente, vamos analisar de forma breve as configurações iniciais de segurança do Windows PowerShell. Por padrão, o shell não executará arquivos com uma extensão de nome de arquivo PS1 quando você clicar duas vezes neles. Essa extensão está associada ao Bloco de notas. Na verdade, por padrão, o shell não executará scripts em razão de um recurso interno denominado Diretiva de Execução, que descreve as condições nas quais um script será executado. Ele é definido como Restrito pronto, o que proíbe a execução de todos os scripts e habilita o shell somente para uso interativo. A Diretiva de Execução pode ser alterada usando o cmdlet Set-ExecutionPolicy ou por meio de um modelo administrativo da Diretiva de Grupo (arquivo ADM) fornecido pela Microsoft. (Você pode obter o arquivo ADM em go.microsoft.com/fwlink/?LinkId=102940.) A Figura 1 mostra as Diretivas de Execução que você pode definir.
Figura 1 Como escolher uma Diretiva de Execução segura
Figura 1 Como escolher uma Diretiva de Execução segura
A Diretiva de Execução tem somente algumas exceções. Especificamente, mesmo quando definida como Restrita, ela permitirá que o shell importe determinados arquivos de configuração XML, os quais são fornecidos pela Microsoft e instalados junto com o shell. Esses arquivos serão utilizados para fornecer funcionalidades específicas, como extensões para tipos Microsoft® .NET Framework e layouts de formatação padrão para a maioria dos tipos de objetos .NET. Assim, esses são os arquivos que você definitivamente deseja que o shell carregue na inicialização.
Embora esses arquivos possam conter, e contêm, código executável, eles foram assinados digitalmente pela Microsoft. Violá-los de qualquer forma inutilizará a assinatura e, se isso ocorrer, o shell não importará os arquivos na inicialização. Esse projeto torna os arquivos muito mais seguros em relação a malware que possam tentar inserir código malicioso neles.
É claro, a Diretiva de Execução, se mantida como Restrita, também impedirá que seus próprios scripts de perfil do Windows PowerShell sejam executados na inicialização. Por padrão, o Windows PowerShell não criará um script de perfil, mas irá pesquisar quatro locais específicos quanto a nomes de arquivos específicos e, se localizá-los, tentará executá-los sempre que o shell for iniciado. (A documentação instalada junto com o Windows PowerShell fornece detalhes sobre os nomes de arquivo e pasta utilizados para scripts de perfil.) O perfil é fundamental para explorar o que abordarei a seguir.

Como modificar a Diretiva de Execução
Cmdlet do mês
O assistente do Set-AuthenticodeSignature é o Get-AuthenticodeSignature. Esse cmdlet foi desenvolvido para examinar um script assinado digitalmente e fornecer detalhes sobre a assinatura. Basta apontá-lo para o arquivo em questão e você verá não somente se um arquivo foi assinado, mas se a assinatura está intacta, qual certificado foi usado para assinar o arquivo e assim por diante. Além de funcionar com os scripts do Windows PowerShell, esse cmdlet também funciona com os executáveis assinados, como a seguir:
PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *
Ao executar esse comando, é possível ver se o executável foi assinado pela Microsoft Corp. usando um certificado emitido pela Microsoft Code Signing CA.
Resultados do comando
Resultados do comando

Devo salientar que em condições padrão, é muito difícil – se não impossível – que o Windows PowerShell execute qualquer código ou deixe qualquer código malicioso isolado. Somente se você alterar a Diretiva de Execução é que os scripts maliciosos se tornarão possíveis. Para ser mais específico, esta coluna não é um alerta sobre as brechas de segurança no Windows PowerShell; em vez disso, tem como objetivo compartilhar algumas das práticas recomendadas para manter os sistemas protegidos.
A Diretiva de Execução mais baixa é Irrestrita, o que permite que todos os scripts sejam executados sem restrição ou dúvida – oferecendo basicamente o mesmo cenário indesejável que você teve por anos com os arquivos em lote e VBScript. Defina o shell como Irrestrito e você estará apenas solicitando que um script malicioso surja e cause danos. Se você não tiver escolhido a configuração Irrestrita e um script surgir e o atacar, certifique-se de que você possa justificar por que escolheu essa configuração e prepare-se para sustentar sua decisão quando estiver explicando como um vírus eliminou seu ambiente!
Para ser honesto, o Windows PowerShell ainda tentará detectar scripts obtidos pela Internet e avisá-lo antes da execução, mesmo quando estiver definido como Irrestrito. Mas a questão é que ter uma Diretiva de Execução definida como Irrestrita não é uma boa idéia.

Como assinar scripts
A Diretiva de Execução mais segura que permite que os scripts sejam executados é a AllSigned. Essa configuração, como o nome sugere, executa somente scripts que têm uma assinatura digital intacta criada usando um certificado confiável (diferente do que a assinatura antiga faria). A assinatura de scripts requer que você adquira um certificado digital de Classe III – mais especificamente, um certificado de assinatura de código Authenticode da Microsoft. Tais certificados podem ser obtidos da Infra-estrutura de chave pública (PKI, Public Key Infrastructure) interna de sua empresa, se você tiver uma, ou adquirida de autoridades de certificação comercial (CAs, certificate authorities), como CyberTrust, Thawte e VeriSign.
Se você quiser saber se tem certificados instalados na sua máquina que podem ser usados para assinar scripts, o seguinte cmdlet exibirá:
Get-ChildItem CERT: -recurse –codeSigningCert
Depois de instalar o certificado no seu computador Windows®, utilize o cmdlet Set-AuthenticodeSignature para criar e aplicar uma assinatura digital, que lhe mostrará uma série de linhas de comentário sem sentido no final do script. Alguns editores de script podem oferecer a opção de aplicar uma assinatura a um arquivo de script, incluindo uma oportunidade para assinar automaticamente scripts à medida que você salvá-los, o que pode ser conveniente.
AllSigned é a melhor Diretiva de Execução a ser utilizada em um ambiente de produção. Embora isso não impeça diretamente scripts maliciosos, garante que um script malicioso seja assinado e, portanto, você poderia rastrear o autor do script (pressupondo-se que os computadores Windows estão configurados para confiar somente em CAs confiáveis, mas esse tópico foge do objetivo desta coluna). Curiosamente, o Windows Script Host (WSH) 5.6 e suas versões posteriores podem ser configurados com uma definição TrustPolicy semelhante, que também requer assinaturas digitais, mas sei de poucos administradores que usam de fato essa configuração.
Portanto, façamos uma rápida recapitulação. Com uma Diretiva de Execução definida como Irrestrita, você está protegido contra scripts maliciosos, mas não poderá executar scripts benéficos. Com a sua Diretiva de Execução configurada como AllSigned, o shell permite scripts assinados, o que é muito seguro, pois alguns autores de scripts maliciosos querem que uma identidade verificada e rastreável seja aplicada em seus trabalhos. A configuração Irrestrita, por outro lado, é extremamente desprotegida e, se você a estiver usando, poderá esperar ser atingido por algum script malicioso em algum momento. (Observe que não considero a configuração Irrestrita uma vulnerabilidade específica, pois ela não finge ser algo, apenas é insegura, mas se você estiver usando essa configuração, provavelmente sabe quais são os riscos.)

Acesso pela "porta lateral"
Ainda há mais uma configuração de Diretiva de Execução: RemoteSigned. Essa é a que eu considero estar sendo utilizada atualmente pela maioria dos administradores, simplesmente por que é percebida como mais segura do que a Irrestrita e menos problemática do que a AllSigned. A RemoteSigned não requer uma assinatura para scripts locais. Os arquivos PS1 que residem nas suas unidades locais serão executados sem serem assinados. Os scripts remotos – principalmente os obtidos da Internet usando o Internet Explorer® or Outlook® (esses aplicativos marcam os arquivos baixados com um sinalizador especial) – não serão executados a menos que sejam assinados.
No entanto, a configuração RemoteSigned pode lhe dar a falsa impressão de segurança. Para começar, é fácil de baixar scripts remotos sem precisar aplicar o sinalizador especial. Os navegadores que não são da Microsoft, por exemplo, geralmente não definem esse sinalizador, e o mesmo se aplica à maioria dos clientes de email que não são da Microsoft. É importante observar que sem esse sinalizador, o Windows PowerShell trata os scripts de download como locais – o que significa que não será necessária uma assinatura. Ainda assim, não considero isso uma vulnerabilidade significativa. Na verdade, você precisa fazer download do script, abrir o Windows PowerShell e executar manualmente esse script para que ele seja executado. É um pouco difícil enganar alguém para que realize todas essas tarefas e, os administradores – geralmente os únicos usuários em uma rede que têm o Windows PowerShell instalado – já deviam estar cientes disso.
No entanto, a RemoteSigned oferece uma “porta lateral” significativa que pode ser utilizada pelo malware. Você se lembra dos scripts de perfil do Windows PowerShell? Se eles existirem – sejam criados por você ou por um código de malware – eles serão executados sempre que o Windows PowerShell for executado. E na Diretiva de Execução RemoteSigned Execution, os seus scripts de perfil – que são locais – não precisarão ser assinados.
Veja o cenário:
  1. Parte do código consegue entrar no seu sistema e criar um script de perfil de shell, ou inserir um código malicioso em um script de perfil existente. O malware geralmente é executado na conta do usuário conectado, o qual geralmente tem permissão para modificar o script do seu perfil.
  2. Você abre o Windows PowerShell, não percebendo que o seu script de perfil foi criado ou modificado para incluir o código malicioso. O código é executado e o dano está feito. O dano é pior se você tiver o hábito de abrir o Windows PowerShell com credenciais de administrador – uma prática comum, pois quando você está usando o shell, precisa de privilégios administrativos para realizar quaisquer tarefas para as quais está usando o shell.
O perfil apresenta então uma forma para que o código arbitrário e malicioso seja executado sem o seu conhecimento, e a Diretiva de Execução RemoteSigned permite que isso aconteça.

Como proteger o perfil
Há apenas um método ideal para proteger o seu perfil: use a Diretiva de Execução AllSigned. Na AllSigned, até mesmo os seus scripts de perfil devem ser assinados digitalmente; caso contrário, o Windows PowerShell não irá executá-los na inicialização. E se você tiver assinado seus scripts de perfil, as modificações maliciosas neles violarão suas assinaturas digitais, impossibilitando-os de serem executados – na verdade, o Windows PowerShell irá alertá-lo do problema na inicialização. A AllSigned é realmente a única configuração segura de Diretiva de Execução para ambientes de produção que precisam permitir a execução de scripts.
Há outra abordagem, mas é mais complicada e menos confiável. Você pode criar arquivos de script de perfil em branco para cada um dos quatro arquivos que o Windows PowerShell verificar. Use uma nova conta de usuário (a chamarei de "Editor de perfil") para criar esses arquivos e definir as permissões NTFS dos arquivos, de modo que somente a conta do Editor de perfil possa modificá-las. Outras contas podem ter acesso somente leitura.
Agora, nunca faça logon no computador usando a conta de Editor de perfil, exceto para editar seu perfil. Com essa abordagem, a sua conta (ou contas) de usuário normal não poderá modificar seus scripts de perfil. E qualquer malware que for executado enquanto você estiver conectado com uma conta normal não poderá modificar os scripts. O que acontece se o malware for executado enquanto você estiver conectado como Editor de perfil? Bem, considerando que você está conectado como Editor de perfil para editar seus scripts de perfil, você deverá observar as alterações.
Você também pode criar sua própria segurança de rede ao criar um script de perfil para todos os usuários, que será controlado com rígidas permissões de arquivo, como acabei de descrever. Nesse script, grave o código que utilizará o cmdlet Get-AuthenticodeSignature para examinar as assinaturas digitais em outros perfis que o shell verificar. Isso basicamente permite que você exija assinaturas em scripts de perfil, sem exigi-las para outros scripts.
No entanto, a Diretiva de Execução AllSigned é uma forma muito mais completa de proteger o seu perfil. Minha recomendação é que qualquer computador conectado à sua rede tenha uma Diretiva de Execução Restrita, preferencialmente aplicada pela Diretiva de Grupo. Isso substitui qualquer configuração local e garante que os computadores do novo domínio sejam definidos automaticamente para desativar scripts. Os computadores nos quais os scripts devem ser permitidos devem ter uma Diretiva de Grupo alternativa que defina a Diretiva de Execução AllSigned. Você precisará assinar digitalmente todos os scripts, mas ficará tranqüilo sabendo que somente os scripts confiáveis de autores identificáveis serão executados no seu ambiente.

Don Jones é o guru de scripts da SAPIEN Technologies e co-autor do Windows PowerShell: TFM (SAPIEN Press, 2007). Para entrar em contato com ele, visite www.ScriptingAnswers.com.


 Ei, Equipe de Scripts!: N&#227;o h&#225; como errar usando express&#245;es regulares
Ei, Equipe de Scripts!
Não há como errar usando expressões regulares
The Microsoft Scripting Guys
Faça download do código deste artigo: HeyScriptingGuy2008_01.exe (150KB)

Todo o mundo comete erros. (Não vai me dizer que você achava que a Equipe de Scripts foi criada intencionalmente?) Entretanto, se há algo positivo que pode ser dito sobre erros é: o que é isso? Você podia apostar que íamos dizer "sempre podemos aprender com os erros", não é? Céus, não! A única coisa que você pode aprender com um erro, antes de tudo, é que seria bem melhor nunca tê-lo cometido.
Observação: desculpe, nada de piadas sobre Microsoft Bob, não hoje. Cometemos o erro de zombar do Microsoft Bob uma vez e, nesse caso, realmente aprendemos com o nosso erro. Em se tratando de Microsoft Bob, ficamos de boca calada.
Para ser honesto, a Equipe de Scripts não pode realmente pensar em nada bom para dizer sobre erros; é por esse motivo que nos dedicamos a minimizar os erros que cometemos. (Confesso que a única forma de fazer isso era diminuindo o número de tarefas que realizamos atualmente. Mas essa é outra história.)
Tudo bem em tentarmos minimizar nossos próprios erros, mas isso pode não ser tão bom para nós se as pessoas com as quais trabalhamos continuarem cometendo erros. (Não, já lhe dissemos: nada de piadas sobre Microsoft Bob!) Se você já gravou alguma vez um front-end em um programa de banco de dados ou no Active Directory® (e sabemos que muitos de vocês já fizeram isso), então sabe exatamente do que estamos falando: o programa de entrada de dados front-end só é tão bom quanto as pessoas que inserem os dados.
Suponha que você queira que os nomes sejam inseridos desta forma: Ken, com a primeira letra em maiúscula e as subseqüentes em minúscula. O que acontece quando um usuário insere esse nome assim: KEN? Suponha que as datas devam ser inseridas desta forma: 23/01/2007. O que acontece quando um usuário insere uma data assim: 23 de janeiro de 2007? Suponha... Bem, você já entendeu. Como dissemos, o programa de entrada de dados front-end só é tão bom quanto as pessoas que inserem os dados. E, gostando ou não, essas pessoas vão cometer erros. A menos, é claro, que você tome medidas para ajudar a garantir que eles não os cometam.

Ter certeza de que os dados são válidos
Espere o jogo terminar
Alguma vez você já se perguntou qual é o evento que a Equipe de Scripts aguarda com tanta ansiedade durante o ano inteiro? Se você já esteve no Script Center em fevereiro nos últimos dois anos, vai imaginar que são "Os Jogos de Script de Inverno". Sinto dizer, mas... você errou! A Equipe de Scripts espera ansiosa pelo final dos Jogos de Script, quando, depois de duas semanas de diversão e empolgação ininterruptos, ela se deleita com outra bem-sucedida competição de script e dorme durante todo o mês seguinte.
Então, na preparação para nosso evento favorito do ano (o final dos Jogos de Script), é hora de começar os Jogos de Script de Inverno de 2008! Junte-se a nós de 15 de fevereiro a 03 de março de 2008, no Script Center, para mais de duas semanas de diversão e a melhor competição de script do mundo!
Os Jogos de Script são a melhor forma de testar – e melhorar – suas habilidades na criação de scripts. E, como este ano a Equipe de Script quer dormir mais alguns dias depois que a competição terminar, estamos programando-a maior e melhor que a do ano passado! Mais uma vez, teremos duas divisões: Iniciantes e Avançados. Isso significa que, se você é novato em script, um profissional experiente (ainda que jovem) ou algo entre os dois, esta competição é para você.
Então, o que há de novo este ano? Estamos adicionando outra linguagem de script. Você pode entrar na competição de VBScript, Windows PowerShell ou – aqui está a novidade – Perl. (Sabemos que Perl não é novo, mas é uma novidade nesta competição.) Provavelmente será ainda mais divertido, mas, como tivemos de anexar esta barra lateral meses atrás, não temos idéia de como será. Você terá de vir ao Script Center para descobrir o que bolamos.
Caso você esteja se perguntando, haverá prêmios, sim! Quais serão eles? Ei! Você não quer que estraguemos a surpresa, não é? Venha ao Script Center e descubra! microsoft.com/technet/scriptcenter/funzone/games/default.mspx.

Muitos de vocês provavelmente já estão fazendo uma validação de entrada de dados rudimentar. E, para muitas coisas, ela serve perfeitamente. Precisa ter certeza de que o valor da cadeia strName tem 20 ou menos caracteres? Este minúsculo bloco de código lhe dirá:
If Len(strName) > 20 Then
    Wscript.Echo "Invalid name; a " & _
    "name must have 20 or fewer characters."
End If
Mas suponha que strName é uma nova peça número, e peças números devem atender a um padrão específico: quatro dígitos seguidos de duas letras maiúsculas (algo como 1234AB). Usando o VBScript simples, é possível verificar se strName segue o padrão obrigatório para peças número? Sim, é possível. Mas confie em nós: você nem vai dar bola. Em vez disso, vai querer usar uma expressão regular.

Ter certeza de que somente números aparecem em um valor
Expressões regulares datam dos anos 50, quando foram descritas pela primeira vez como uma forma de notação matemática. Na década de 60, esse modelo matemático foi incorporado ao editor de texto QED como uma forma de procurar padrões de caracteres em um arquivo de texto. Algum tempo depois, o que é isso? Xi... Aparentemente, ninguém acha a história das expressões regulares tão fascinante como nós. OK. Nesse caso, vamos só mostrar do que estamos falando.
Quer ter certeza de que uma variável (nesse caso, strSearchString) contém apenas números? A Figura 1 mostra um meio de fazer isso.
Figure 1 Numbers only, please (Close Figure 1)
Set objRegEx = _
  CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\D"

strSearchString = "353627"

Set colMatches = _
  objRegEx.Execute(strSearchString)

If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
Como você pode ver, o script começa criando uma instância do objeto VBScript.RegExp, o objeto que... sim, você está certo, o objeto que nos permite usar expressões regulares em nosso script. (Ah, queríamos que fôssemos nós a explicar isso.) Depois disso, atribuímos valores a duas propriedades principais do objeto de expressões regulares: Global e Pattern.
A propriedade Global determina se o script deverá corresponder a todas as ocorrências de um padrão ou simplesmente localizar a primeira ocorrência desse tipo e depois parar. Em geral, é melhor definir esse valor como True, indicando que você quer procurar todas as ocorrências de um padrão. (O padrão é False.) Na maioria das vezes, você vai querer localizar todas as ocorrências de um padrão. Mesmo que não queira, a única vantagem de localizar apenas a primeira ocorrência de um padrão é que o script será executado mais rapidamente se parar no meio da cadeia em vez de procurar até o final. Teoricamente, isso parece bom. Na prática, porém, a pesquisa geralmente é concluída com tanta rapidez que você nem vai notar muita diferença.
Esta é a parte boa: a propriedade Pattern é onde especificamos os caracteres (e o plano gráfico de caracteres) nos quais estamos interessados. Em nosso script de exemplo, estamos procurando qualquer caractere que não seja um dos dígitos entre 0 e 9. Se localizarmos esse caractere (uma letra, uma marca de pontuação, o que for), então saberemos que o valor atribuído a strSearchString não é válido. Com expressões regulares, a sintaxe \D é usada para corresponder a qualquer caractere que não seja um dígito. Dessa forma, atribuímos o valor \D à propriedade Pattern.
Observação: como sabemos que \D corresponde a qualquer caractere que não seja um dígito? Bem, essa é uma longa história. Veja só, anos atrás... OK, OK. Nós pesquisamos na VBScript Language Reference no MSDN® em msdn2.microsoft.com/1400241x.
Depois de atribuir valores às propriedades Global e Pattern, nossa próxima etapa é atribuir um valor à variável strSearchString:
strSearchString = "353627"
Como sabemos se há algum caractere que não seja um dígito nessa cadeia? É fácil. Basta chamar o método Execute, que irá procurar esse tipo de caractere na nossa variável:
Set colMatches = _
objRegEx.Execute(strSearchString)
Quando chamamos o método Execute, qualquer correspondência – ou seja, qualquer instância de Pattern – encontrada é armazenada automaticamente na coleção Matches. (No nosso script de exemplo, demos a essa coleção o nome colMatches.) Se quisermos saber se a nossa variável contém algum caractere que não seja dígito (e queremos), tudo o que temos a fazer agora é verificar o valor da propriedade Count da coleção, que nos informa quantos itens existem na coleção:
If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
Se Count for maior do que 0, isso só pode significar uma coisa: um caractere que não é dígito foi encontrado em algum lugar no valor da variável. (Se todos os caracteres no valor fossem dígitos, a coleção estaria vazia e teria um Count de 0.) Em nosso script de exemplo, repetimos então o fato de que um caractere não-numérico foi descoberto. Em um script real ou em um banco de dados front-end, provavelmente você repetiria uma mensagem semelhante e executaria o loop novamente para que o usuário tentasse mais uma vez. Mas não vamos nos preocupar com isso. Como membros da Equipe de Script, temos um monte de outras coisas com que nos preocupar.
Como o quê? Como o pensamento de que, algum dia, as pessoas na TechNet Magazine podem começar realmente a ler os artigos que enviamos para eles todos os meses. É melhor eles não aprenderem com os erros que cometem.
Ah, boa pergunta: não poderíamos simplesmente usar a função IsNumeric para determinar se strSearchString contém um número? Claro, desde que strSearchString possa ser qualquer número. Mas e se strSearchString tiver que ser um inteiro positivo? Isso poderia ser um problema; IsNumeric identifica estes dois como números válidos:
-45
672.69
Por que eles são identificados como números válidos? Porque são números válidos; não são simplesmente números inteiros positivos. Contudo, nossa expressão regular os sinalizará como entradas inválidas, pois a expressão regular captura os caracteres que não são dígitos menos o sinal de subtração (–) e o ponto final (.). Se você vem lendo esta coluna e pensando: "Por que estou lendo esta coluna?", há uma boa razão bem aqui.
O que você disse? Isso não é bom o bastante? Uau, que multidão valente este mês. OK, vamos examinar alguns outros tipos de validação de entrada de dados que podem ser realizados usando expressões regulares.

Ter certeza de que nenhum número aparece em um valor
Acabamos de mostrar como ter certeza de que somente números aparecem em um valor. E se quiséssemos fazer o oposto? Ter certeza de que nenhum número aparece em nosso valor? Este é um padrão de pesquisa que podemos usar:
objRegEx.Pattern = "[0-9]"
O que está acontecendo aqui? Bem, no mundo selvagem e maluco das expressões regulares, os caracteres entre colchetes ([ e ]) permitem especificar um conjunto de caracteres ou, como fizemos aqui, um intervalo de caracteres. O que significa Pattern [0-9]? Significa que estamos procurando qualquer caractere no intervalo de 0 a 9 – em outras palavras, qualquer valor numérico. Se quiséssemos somente números pares (ou seja, ter certeza que nosso valor não inclui nenhum 1, 3, 5, 7 ou 9), usaríamos este padrão:
objRegEx.Pattern = "[13579]"
Observe que, como não usamos hífen, não estamos procurando um intervalo de caracteres. Na verdade, estamos procurando os caracteres reais 1, 3, 5, 7 e 9, especificamente.
Obviamente, Pattern [0-9] procura somente números; ele não localizará marcas de pontuação ou outros caracteres que não sejam letras nem números. Você acha que podemos criar um padrão que procure algum caractere que não seja letra? Claro que sim. Você pode fazer quase tudo o que quiser com expressões regulares.
objRegEx.Pattern = "[^A-Z][^a-z]"
Nesse caso, estamos combinando dois critérios em nosso padrão: [^A-Z] e [^a-z]. Como você já deve ter adivinhado, A-Z significa o intervalo de caracteres da letra maiúscula A até a letra maiúscula Z. O que significa o caractere ^? Bem, quando incluído em um par de colchetes, ^ significa "Procurar qualquer caractere que não esteja no conjunto de caracteres". Portanto, [^A-Z] significa "Procurar qualquer caractere que não seja uma letra maiúscula". Entrementes, [^a-z] significa "Procurar qualquer caractere que não seja uma letra minúscula". Resultado: esse padrão significa que estamos procurando qualquer coisa que não seja uma letra maiúscula ou uma letra minúscula. Isso inclui números, marcas de pontuação e qualquer outro caractere estranho que exista no seu teclado.
Como alternativa, poderíamos ter definido a propriedade IgnoreCase como True:
objRegEx.IgnoreCase = True
Com isso, nossa pesquisa ignoraria a diferenciação entre maiúsculas/minúsculas. Por sua vez, poderíamos então usar esse Pattern, que, combinado à propriedade IgnoreCase, procuraria qualquer coisa que não fosse uma letra maiúscula ou uma letra minúscula:
objRegEx.Pattern = "[^A-Z]"

Ter certeza de que uma peça número é válida
Agora, vamos sonhar um pouco mais. (Confie em nós, você realmente pode sonhar com expressões regulares. Dê uma olhada no site regexlib.com para ver alguns exemplos.) Dissemos anteriormente neste artigo algo como “suponha que strName é uma nova peça número, e peças números devem atender a um padrão específico: quatro dígitos seguidos de duas letras maiúsculas (por exemplo, 1234AB)”. Como verificar se uma variável atende a esse padrão? Desta forma, é claro:
objRegEx.Pattern = "^\d{4}[A-Z]{2}"
O que significa esse padrão? Que coincidência! Acabamos de explicar o que significa esse padrão. Nesse caso, estamos procurando por três critérios:
^\d{4}
O \d significa que estamos procurando dígitos (um caractere no intervalo entre 0 e 9). O que significa {4}? Significa que queremos corresponder exatamente quatro dos caracteres (ou seja, exatamente quatro dígitos). Portanto, estamos procurando quatro dígitos consecutivos.
E quanto ao caractere ^? Bem, fora de um par de colchetes, ^ indica que o valor deve começar com o padrão subseqüente. Isso significa que AA1234AB não seria sinalizado como uma correspondência. (Por quê? Porque o valor realmente começa com AA, e não com quatro dígitos consecutivos.) Se quiséssemos, poderíamos usar o caractere $ para indicar que a correspondência deve ocorrer no final da cadeia. Mas simplesmente não queremos. (Bem, pelo menos não com este exemplo.)
[A-Z]{2}
Você já sabe o que significa o componente [A-Z]: qualquer letra maiúscula. E {2}? Isso mesmo: os quatro dígitos devem vir seguidos de exatamente duas letras maiúsculas.
Muito fácil, não? A propósito, nesse caso, se Count for 0, teremos um valor inválido. Por quê? Bem, desta vez, não estamos procurando um único caractere que invalidaria a cadeia. Em vez disso, procuramos uma correspondência de padrão exata. Se não obtivermos essa correspondência, significa que temos um valor inválido e que a propriedade Count da coleção será 0.
Observação: duas outras construções úteis são {3,} e {3,7}. O {3,} significa que deve haver pelo menos 3 caracteres consecutivos (ou expressões). Porém, embora haja um mínimo de 3, não há um máximo. O \d{3,} corresponde a 123, a 1234 e também a 123456789. O {3,7} significa que deve haver pelo menos 3 caracteres consecutivos (ou expressões), mas não mais do que 7. Portanto, 123456 é uma correspondência, mas 123456789 (que tem mais do que 7 dígitos consecutivos), não.
Aqui está outro padrão útil. Suponha que sua peça número começa com 4 dígitos seguidos das letras US seguidas de dois caracteres finais (que podem ser letras, números ou qualquer outra coisa). Aqui está uma forma de fazer essa correspondência:
objRegEx.Pattern = "^\d{4}US.."
Como você pode ver, esse padrão começa com 4 dígitos (\d), que devem ser seguidos dos caracteres US (e somente eles; nada mais será uma correspondência). Após os caracteres US, precisaremos então de mais dois caracteres do mesmo tipo. Como indicamos qualquer caractere em uma expressão regular? Espere um segundo; essa nós sabemos... aqui está: qualquer caractere único é indicado por um ponto (.). Logicamente, isso significa que dois caracteres podem ser indicados por dois pontos:
..
OK, essa era fácil. Vamos tentar uma mais difícil. Suponha que aqueles dois caracteres internos indicam o país onde a peça foi fabricada. Se você tiver fábricas nos EUA, no Reino Unido e na Espanha, isso significa que qualquer um destes códigos de caracteres é válido: US, UK, ES. E como fazemos múltipla escolha em uma expressão regular?
Bem, que tal isto:
objRegEx.Pattern = "^\d{4}(US|UK|ES).."
A chave aqui é esta pequena construção: (US|UK|ES). Colocamos os três valores aceitáveis (US, UK e ES) dentro de um conjunto de parênteses, separando cada valor com um caractere de pipe (|). É assim que fazemos múltipla escolha com uma expressão regular.
Mas espere! Não dissemos que colocaríamos várias opções dentro dos colchetes? E não é para isso que fizemos essa coisa [13579] toda? Foi sim. Entretanto, isso funciona somente para caracteres únicos; [13579] sempre será interpretado como 1, 3, 5, 7 e 9. Para usar 135 e 79 como opções, você precisa usar esta sintaxe: (135|79). Pode também usar parênteses para delinear uma única palavra a ser procurada:
objRegEx.Pattern = "(scripting)"
Ou simplesmente tirar os parênteses:
objRegEx.Pattern = "scripting"
Observação: OK, é bom saber disso, mas e se os parênteses precisarem ser incluídos como parte do termo de pesquisa, ou seja, e se eu quiser procurar (script)? Bem, como os parênteses de abertura e de fechamento são caracteres reservados em expressões regulares, você precisa preceder cada caractere com um \. Em outras palavras:
objRegEx.Pattern = "\(scripting\)"

Liberdade de expressão
Acabou o espaço que tínhamos para a coluna deste mês. Se você quiser saber mais sobre expressões regulares, convém dar uma espiada no webcast String Theory for System Administrators: An Introduction to Regular Expressions (microsoft.com/technet/scriptcenter/webcasts/archive.mspx). E quando você começar a aprender – e usar – expressões regulares, tenha em mente as palavras imortais de Sophia Loren: "Erros são parte dos tributos que se paga por uma vida plena."
Puxa! A Equipe de Scripts tem vivido vidas muito mais plenas do que nos demos conta!

O desafio de script do Dr. Scripto
O desafio mensal que testa não apenas sua habilidade de resolver quebra-cabeças, mas também de criar scripts.

Janeiro de 2008: Nomes de enrolamento
Neste mês, Dr. Scripto decidiu trabalhar com o Windows PowerShell. É claro que não se pode trabalhar com o Windows PowerShell – não da forma correta (e o Dr. Scripto sempre faz a coisa certa) – sem usar cmdlets. Para esse quebra-cabeças, Dr. Scripto enrolou alguns cmdlets em torno de uma grade e você precisa encontrá-los.
Temos que admitir que esse quebra-cabeça seria bem mais confuso se tivéssemos que usar o cmdlet inteiro. Por causa da construção verbo-nome dos cmdlets, existem dezenas que começam com Get-, Set-, etc. Por isso, desativamos a parte de verbo do cmdlet (e o hífen), deixando apenas os nomes. (Mas podemos lhe dizer que todos os verbos eram "Get-".)
Sua tarefa é desenrolar os nomes de cmdlet. Fornecemos a lista de nomes ocultos no quebra-cabeças. (Não fomos bonzinhos?) Cada palavra pode enrolar vertical e horizontalmente, para frente e para trás, mas nunca na diagonal. Demos a você a primeira palavra (Location) como exemplo. Boa sorte!

Lista de palavras
Alias
ChildItem
Credential
Date
EventLog
ExecutionPolicy
Local
Member
PSSnapin
TraceSource
Unique
Variable
WMIObject

O desafio de script do Dr. Scripto
Resposta: Nomes de enrolamento, janeiro de 2008

The Microsoft Scripting GuysA Equipe de Scripts trabalha para a – bem, é empregada da – Microsoft. Quando não está jogando/treinando/assistindo beisebol (e diversas outras atividades), ela administra o Script Center da TechNet. Confira no site www.scriptingguys.com.


 Security Watch: Saltos de ilha: armadilha em forma de brindes
Security Watch
Saltos de ilha: armadilha em forma de brindes
Jesper M. Johansson

A técnica de saltos de ilha – penetrar uma rede através de um link fraco e então saltar entre os sistemas nessa rede – existe há anos. Mas ela continua tomando novas dimensões. Nos atuais ambientes de TI que têm preocupação com a segurança, as pessoas são freqüentemente o link mais fraco e os usuários maliciosos estão
sempre buscando formas de usar isso em vantagem própria (considere o phishing e outras formas de engenharia social). Essa combinação pode ser fatal para sua rede.
Um dos melhores casos em que se tirou vantagem do elemento humano foi perpetrado por Steve Stasiukonis, da Secure Network Technologies, durante um teste de penetração para um cliente. Ele implantou no estacionamento do cliente unidades flash USB, cada uma delas com um cavalo de Tróia instalado. Quando os funcionários chegaram para trabalhar na manhã, eles estavam bem empolgados para localizar os gadgets gratuitos distribuídos no estacionamento. Os funcionários coletaram ansiosamente as unidades USB e as conectaram nos primeiros computadores que viram: suas próprias estações de trabalho.
Talvez alguns funcionários fossem inteligentes o suficiente para ignorar essas unidades USB, e é possível que algumas delas fossem descartadas, mas o fato é que basta que apenas um usuário com uma unidade infecte seu próprio sistema e forneça um gateway na rede. Stasiukonis fez esse exercício como um teste, é claro, mas essa técnica foi utilizada por criminosos reais para se infiltrarem em grandes redes corporativas.
As unidades flash USB estão em toda parte atualmente. Em praticamente todas as conferências, há algum fornecedor oferecendo-as como brinde. Essas unidades podem não ter muita capacidade, mas não é necessário muito espaço de armazenamento para se assumir o controle de uma rede inteira. Nessa série de duas partes, investigarei esse tipo de ataque e mostrei formas de ajudá-lo a reduzir o risco. Na edição deste mês, discutirei o que exatamente as unidades flash USB fazem e o que você pode fazer para controlá-las. Na edição do próximo mês da TechNet Magazine, mostrarei como você pode conter um ataque a um único ou pequeno conjunto de sistemas na rede.
Os detalhes técnicos do ataque são, na verdade, bem simples. Todos eles iniciam com uma unidade flash USB infectada sendo inserida em um único computador. O que ocorre então depende da carga nessa unidade e, é claro, de quão ingênuo é o usuário.

Introdução
No palanque havia um laptop autônomo. O palestrante estava ocupado tentando se familiarizar com o público antes de iniciar sua apresentação. O laptop em si estava bloqueado, mas isso não foi muito significativo. O invasor foi para o palanque e ali permaneceu um pouco, aparentando estar apenas aguardando que o palestrante retornasse. Como esses palanques são desenvolvidos para ocultar “itens feios”, como computadores, portas USB, etc., as mãos dos invasores também não são vistas. Assim que a unidade flash USB foi inserida no computador, demorou apenas alguns segundos para que o ataque fosse concluído.
Há algumas variações óbvias sobre esse tema específico. Por exemplo, quando eu costumava viajar pelo mundo palestrando mensalmente, quase sempre, quando eu terminava, havia algumas pessoas pedindo uma cópia dos meus slides. Minha resposta era sempre que eles deixassem um cartão e que me enviassem um email. Por que eu faria isso quando todos apontavam ansiosos uma unidade flash USB na minha direção? Porque eu conheço ferramentas como USB Hacksaw e Switchblade. (Se você não estiver familiarizado com essas ferramentas, consulte wiki.hak5.org.)
Basicamente, essas ferramentas permitem que praticamente qualquer um explore, com muita facilidade, pessoas que deixam suas portas USB desprotegidas. Por exemplo, a ferramenta Switchblade pode despejar o seguinte:
  • Informações do sistema
  • Todos os serviços da rede
  • Uma lista de portas na escuta
  • Todas as chaves de produto de produtos Microsoft no computador
  • O banco de dados de senha local
  • A senha de quaisquer redes sem fio que o computador utilize
  • Todas as senhas de rede que o usuário atualmente conectado tiver armazenado no computador
  • Internet Explorer®, Messenger, Firefox e senhas de email
  • Os segredos da LSA (Local Security Authority, Autoridade de segurança local), que contêm todas as senhas da conta de serviço em texto não criptografado
  • Uma lista dos patches instalados
  • Um histórico recente da navegação
Tudo isso vai para um arquivo de log na unidade flash e leva apenas 45 segundos.
A ferramenta Hacksaw é uma versão levemente modificada; ela instala um cavalo de Tróia no computador, que monitora todos os eventos de inserção de unidade flash USB. Em seguida, ela envia por email para o invasor todos os documentos de todas as unidades flash subseqüentemente inseridas no computador.
As ferramentas que abordamos até o momento usam o U3 (u3.com), uma tecnologia desenvolvida para permitir que os usuários carreguem os programas consigo em uma unidade flash. Em resumo, uma unidade flash habilitada com U3 dissimula sua presença. Ela informa ao SO que é, na realidade, um hub USB com uma unidade flash e um CD conectado a ela. As versões do Windows® anteriores ao Windows Vista® executarão automaticamente, por padrão, programas designados no arquivo autorun.inf em CDs, mas não em unidades USB. Ao se camuflar, a unidade flash USB habilitada com U3 engana o OS ao executar automaticamente algo denominado iniciador de U3. O iniciador de U3, por sua vez, poderá iniciar os programas, apresentar a você um menu ou realizar qualquer ação que você mesmo faria no computador.
Tudo que as ferramentas de exploração fazem é substituir o iniciador pelo código de exploração. Assim que a unidade flash for conectada a um sistema Windows XP, a ferramenta de exploração será executada automaticamente. No Windows Vista, o fluxo de decisão de Reprodução Automática funciona de forma diferente. A Execução Automática está realmente habilitada em dispositivos removíveis, como CDs. Isso significa que algum tipo de ação ocorrerá quando o dispositivo for inserido. Por padrão, será exibida a caixa de diálogo da Reprodução Automática, como mostra a Figura 1.
Figura 1 A caixa de diálogo padrão de Reprodução Automática será exibida quando um usuário inserir uma unidade removível com imagens
Figura 1 A caixa de diálogo padrão de Reprodução Automática será exibida quando um usuário inserir uma unidade removível com imagens
Observe que a caixa de diálogo na Figura 1 tem uma opção para "Always do this for pictures" (Sempre fazer isso para imagens). Isso define uma opção de Reprodução Automática, que pode ser configurada no Painel de Controle, como na Figura 2.
Figura 2 Configuração de Reprodução Automática no Windows Vista
Figura 2 Configuração de Reprodução Automática no Windows Vista
A configuração de Reprodução Automática é especialmente interessante para "Software e jogos". Por definição, isso significa que a unidade removível tem um arquivo autorun.inf que especifica que algum programa seja executado. As configurações na Figura 2 relacionadas a "Software e jogos" são armazenadas na seguinte chave de registro:
Hive:    HKEY_CURRENT_USER
Key:    \Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\
UserChosenExecuteHandlers\AutorunINFLegacyArrival
Value: (Default)
Data:
MSAutoRun – automatically executes the program specified in the autorun.inf file

MSPromptEachTime – prompts the user, using strings specified in the autorun.inf file, if available
Como não é necessário ser um administrador para modificar essas configurações, os usuários podem defini-las como desejarem, incluindo a execução automática de qualquer malware, como o que estava na unidade encontrada no estacionamento. Na verdade, eles podem fazer isso marcando a caixa apropriada na caixa de diálogo de Reprodução Automática.

Gerenciando a Reprodução Automática na sua rede
Como administrador, há várias formas de gerenciar a Reprodução Automática em toda a sua rede. Primeiramente, você pode impedir que um usuário habilite a Reprodução Automática para mídia removível e CDs modificando a configuração NoDriveTypeAutoRun, que controla para quais tipos de unidade a Reprodução Automática está habilitada. O Windows XP é fornecido com NoDriveTypeAutoRun definido como 0x95, o que desabilita a Reprodução Automática em tipos de unidades, unidades de rede e dispositivos removíveis desconhecidos. Iniciando com o Windows XP SP2, por padrão, a configuração NoDriveTypeAutoRun está configurada como 0x91. Isso habilita a Reprodução Automática em dispositivos de armazenamento removíveis. Usando a Diretiva de Grupo, há uma configuração em Configuração do Usuário\Modelos Administrativos\Componentes do Windows\Diretivas de Reprodução Automática que permite que você gerencie a configuração NoDriveTypeAutoRun. Ao habilitar a configuração "Turn off AutoPlay setting and select CD-ROM and Removable Drives" (Desativar a configuração de reprodução automática e selecionar CD-ROM e unidades removíveis), você desabilitará a Reprodução Automática em ambos os tipos de unidades.
Conseqüentemente, o usuário não obterá a caixa de diálogo de Reprodução Automática da Figura 1. Na verdade, nada acontece quando o usuário insere a unidade. No entanto, essa pode não ser uma solução ideal, por causar confusão para o usuário que não estiver certo sobre como acessar as informações necessárias na unidade.
O que você provavelmente deseja é controlar quais tipos de conteúdo podem ser reproduzidos automaticamente. Você pode fazer isso, em certa medida, no Windows Vista, pois esse SO tem efetivamente dois níveis de controle em relação à execução automática de software. Outro controle na Diretiva de Grupo, mostrado na Figura 3, permite que você desabilite a Reprodução Automática de software usando arquivos autorun.inf, enquanto mantém intacto o restante do comportamento de Reprodução Automática do Windows Vista.
Figura 3 Desabilitar arquivos autorun.inf com a Diretiva de Grupo
Figura 3 Desabilitar arquivos autorun.inf com a Diretiva de Grupo
O fluxo de decisão é um pouco complicado quando se trata de Reprodução Automática, e talvez seja mais fácil mostrá-lo com um fluxograma. A Figura 4 descreve o fluxo de decisão usado para determinar se um arquivo deve ser executado automaticamente em uma mídia removível.
Figura 4 O fluxo de decisão da Reprodução Automática
Figura 4 O fluxo de decisão da Reprodução Automática

Outras noções básicas
É claro, essas são apenas algumas das ferramentas que podem ser usadas para comprometer um computador com uma unidade flash USB. Todos os tipos de ferramenta podem ser adicionados a esse cenário, como uma ferramenta que despeja o hash de senha do Windows NT® do usuário atualmente conectado (consulte microsoft.com/technet/community/columns/secmgmt/sm1005.mspx).
Muitos controladores são, na verdade, dispositivos de DMA (Direct Memory Access, acesso direto à memória). Isso significa que eles podem ignorar o sistema operacional e ler/gravar diretamente na memória do computador. Ignorando o SO, os controles de segurança que ele fornece são ignorados – dessa forma você tem acesso completo e irrestrito ao hardware. Isso resulta em total ineficácia do controle do dispositivo implementado pelo OS. Não tenho conhecimento de quaisquer ferramentas de hacking que atualmente usem essa técnicas, mas duvido muito de que isso ainda não tenha sido feito.
Outra forma de explorar a combinação de dispositivo removível é simplesmente apresentar uma opção atraente. Por exemplo, quantos usuários clicariam na caixa de diálogo na Figura 5? Nem todos, mas, provavelmente, muitos. Essa é a questão: é uma tarefa bastante trivial criar uma caixa de diálogo que será muito atraente para que os usuários a ignorem.
Figura 5 Quantos usuários são vítimas disso?
Figura 5 Quantos usuários são vítimas disso?

Bloqueio de dispositivo
Novo no Windows Vista, o recurso de Diretiva de Grupo agora tem um conjunto de diretivas que regem a instalação do dispositivo (consulte a Figura 6). Como mostrado, o administrador pode bloquear a instalação de todos os novos dispositivos removíveis caso o driver especifique que eles são removíveis. No entanto, se o driver definir que eles não o são, a diretiva não terá efeito. Assim, essa diretiva pode ser driblada usando drivers personalizados.
Figura 6 Diretivas de instalação de dispositivo do Windows Vista
Figura 6 Diretivas de instalação de dispositivo do Windows Vista
Para um controle mais granular, o administrador pode usar as diretivas para atuação em classes específicas de configuração de dispositivo. No entanto, isso requer que você conheça a GUID da classe específica do dispositivo que deseja bloquear (ou permitir), tornando essa abordagem consideravelmente mais difícil de gerenciar.

Os privilégios mínimos realmente importam
Ignorando o cenário DMA por um momento, o sucesso dos ataques que abordamos, bem como o das medidas preventivas, dependerá dos privilégios do usuário que acessa o computador. Se for um usuário padrão, a extensão do dano que a exploração pode causar é limitada. Ainda assim, ela poderá roubar os dados desse usuário e tudo que ele acessar. No entanto, o ataque provavelmente não terá muito impacto na rede.
No entanto, se o usuário explorado for um administrador, as conseqüências poderão ser muito piores. No pior dos casos, o usuário é um Administrador de Domínio, e a tomada de toda a rede é trivial. Por exemplo, o invasor poderia extrair o hash de senha do usuário da memória. O sistema armazena em cache o hash no espaço do processo de LSA no logon, de modo que pode ser usado para acessar de forma imperceptível os recursos da rede em nome do usuário. Um invasor com privilégios administrativos pode extrair esse hash e acessar quaisquer recursos da rede com ele. Em outras palavras, se o usuário for um Administrador do Domínio, todo o domínio será comprometido.
Isso nos conduz ao tópico de dependências. Até agora, descrevi um ataque específico em estações de trabalho. No entanto, não explorei o que um ataque pode causar em uma escala de rede. Na coluna do próximo mês, irei explorar o conceito das dependências, mostrando a você o que elas significam para o ambiente como um todo e, mais importante, o que você pode fazer para proteger as dependências.

Jesper M. Johansson é engenheiro de segurança e trabalha com questões de segurança de software, além de editor-colaborador da TechNet Magazine. Ele possui PhD em MIS (sigla em inglês para Sistemas de Gerenciamento de Informação) e mais de 20 anos de experiência em segurança.


 Os arquivos da &#225;rea de trabalho: Computa&#231;&#227;o compartilhada com o Windows SteadyState
Os arquivos da área de trabalho
Computação compartilhada com o Windows SteadyState
Wes Miller

Sei que, se você esteve próximo a um laboratório de computação nos últimos 10 anos, já está familiarizado com esse problema. Eu vi isso pela primeira vez quando estava na faculdade. Na época, os laboratórios ficavam abertos o tempo todo (bastava apresentar a carteira de estudante) e não tinham uma vigilância efetiva, já que faziam parte da biblioteca. Os alunos viciados em jogos nessa época
entravam e faziam modificações nos principais arquivos do Windows® e do MS-DOS® para executar seus jogos. O resultado final era um computador que podia executar jogos bem, mas não executava o Windows corretamente – quando executava. Todos nós passamos por isso em alguma fase. O uso compartilhado foi desencorajado a tal ponto que tentar utilizá-lo não é considerado mais um uso eficiente do tempo.
Recentemente, passei férias em South Padre Island, aqui no Texas. O hotel onde me hospedei tinha três computadores com o Windows XP em uma "sala de computadores para hóspedes". Qualquer pessoa que usasse esses sistemas Windows era administrador e não havia diretivas implantadas, ou seja, cada um desses pobres computadores tinha sido usado e abusado por visitantes que instalavam software não autorizado e removiam ou alteravam aplicativos básicos. Muito provavelmente, essa não era a intenção inicial do hotel. Seja em um laboratório ou em um hotel, a verdade é que computadores de uso compartilhado em um ambiente público são expostos a uma “vida de cão” que nem de longe lembra a dos computadores domésticos.

Soluções para o problema
Obtendo e usando o SteadyState
O Windows SteadyState está disponível para download gratuito em go.microsoft.com/fwlink/?LinkId=104721. Mais informações sobre o SteadyState estão disponíveis em microsoft.com/windows/products/winfamily/sharedaccess.
O Windows SteadyState será executado em qualquer sistema que possa executar o Windows XP. O aprimoramento mais significativo em relação ao SCT é que o SteadyState não requer uma segunda partição para funcionar, como o SCT fazia para a Proteção de Disco do Windows.
A tabela a seguir fornece uma visão geral dos requisitos do sistema para o SteadyState. Observe que ele não precisa de um sistema de arquivos formatado com NTFS, embora haja suporte para qualquer versão do Windows XP. Atualmente, o SteadyState não funciona com o Windows Vista®.

Componente | Requisito
Processador | 300 MHz ou superior (233 MHz, no mínimo).
Memória | 128 MB de RAM ou superior (64 MB, no mínimo; pode limitar o desempenho e alguns recursos).
Disco rígido | Mínimo de 1,5 GB de espaço em disco rígido sem a Proteção de Disco do Windows, ou um mínimo de 4,0 GB de espaço em disco rígido com a Proteção de Disco do Windows.
Sistema operacional | Windows XP Home Edition, Windows XP Professional ou Windows XP Tablet PC Edition. O Windows XP SP2 deve estar instalado.
Idiomas localizados com suporte | Inglês, alemão, francês, italiano, japonês, português (Brasil), chinês simplificado e espanhol.
Sistema de arquivos | Sistema de arquivos formatado com NTFS
Acesso | Acesso no nível de administrador

Se você tem lido minha coluna no último ano ou está familiarizado com a implantação do Windows em geral, pode estar pensando: "grande coisa... vou simplesmente recriar a imagem dos sistemas". Mas aqueles que têm vivido o mesmo que eu sabem que nem sempre é tão simples. Pressionar o botão grande vermelho de recriação de imagens todo dia ou toda semana não dimensiona realmente.
Anos atrás, um amigo e eu pensamos em abrir um cibercafé. Isso foi nos idos de 1995, quando ainda era uma idéia original. Minha maior preocupação era garantir a confiabilidade e a disponibilidade do sistema. Infelizmente, as opções naquela época eram basicamente recriação total de imagens ou soluções ligeiramente mais robustas; não havia nada plug-and-play para resolver o problema.
Voltando ao assunto, ao proteger computadores de uso compartilhado, você vai querer fazer três coisas:
  • Garantir que os usuários executem somente como não-administradores. Esse deve ser sempre o caso em computadores compartilhados.
  • Implantar diretiva para que os sistemas sejam o mais seguro possível. Dessa forma, é pequena a possibilidade de os usuários poderem manipular áreas do sistema às quais não deveriam ter acesso.
  • Poder reverter qualquer alteração aleatória feita por usuários. Mesmo executando como não-administradores, os usuários ainda podem fazer alterações não autorizadas em menus, favoritos, etc.
Felizmente, a Microsoft vem trabalhando há anos em um conjunto de ferramentas criado para ajudar exatamente nessa situação.

História do SteadyState
Pouco mais de um ano atrás, a Microsoft lançou o Windows Shared Computing Toolkit (SCT). Disponível para download gratuito para sistemas verificados pelo programa Vantagens do Windows Original, o kit de ferramentas foi projetado visando especificamente bibliotecas, cibercafés, laboratórios e outros ambientes de computação compartilhada. Talvez você tenha visto a cobertura do SCT na edição de julho de 2006 da TechNet Magazine (technetmagazine.com/issues/2006/07/UtilitySpotlight).
Uma nova versão, agora renomeada como Windows SteadyStateTM (microsoft.com/windows/products/winfamily/sharedaccess), foi lançada em junho de 2007. Sua renomeação se deve, em parte, ao fato de o conjunto de ferramentas ter sido consideravelmente alterado de uma versão para outra. Ele continua executando as mesmas tarefas, que detalharei daqui a pouco, mas a equipe se concentrou na facilidade geral de uso na versão mais recente. Conseqüentemente, o SteadyState está totalmente integrado a um novo console e é mais fácil de instalar e gerenciar. Ele é mais eficiente e flexível, além de oferecer suporte à integração do Active Directory® para um de seus principais componentes, o que significa maior flexibilidade em vários cenários empresariais completamente novos. Agora ele também dá suporte à integração do Windows Update para que o SteadyState saiba quando desativar a Proteção de Disco do Windows para aplicar atualizações em si mesmo. Isso reduz a sobrecarga de gerenciamento que você precisa dedicar aos sistemas gerenciados pelo SteadyState.

Recursos do SteadyState
O Windows SteadyState consiste em quatro componentes principais: Restrições de Computador bloqueia opções de configuração e de segurança por computador; Proteção de Disco do Windows armazena em cache (e reverte) alterações na partição do sistema Windows; Gerenciador de Contas de Usuário cria, edita, importa ou exporta um usuário; e finalmente, Configurações e Restrições de Usuário bloqueia opções de configuração e de segurança por usuário.
Um aprimoramento imediato que pode ser observado no Shared Computing Toolkit é a ajuda ao usuário. Um guia de introdução ajuda você a colocar o SteadyState em funcionamento. O SteadyState oferece quatro tarefas-chave mais detalhadas (refletindo os recursos principais que descrevi acima):
  • Definir Restrições de Computador (Restrições de Computador).
  • Agendar Atualizações de Software. (Permite que você especifique se o SteadyState aplicará automaticamente as Atualizações do Windows. Esse é o procedimento recomendado, já que ele controla a Proteção de Disco do Windows para você e atualiza as assinaturas de vários programas antivírus populares.)
  • Proteger o Disco Rígido (Proteção de Disco do Windows).
  • Adicionar Usuário (Gerenciador de Contas de Usuário)
Em Adicionar Usuário, você encontrará Configurações e Restrições de Usuário, que oferece uma opção de configuração por usuário.

Configurações e restrições de computador e de usuário
Se você está familiarizado com a Diretiva de Grupo, também já conhece estes aspectos do SteadyState: Configurações e Restrições de Usuário e Definir Restrições de Computador. Em vez de forçar os administradores do SteadyState a usar o Editor de Objeto de Diretiva de Grupo (GPEdit.msc), que não é um recurso disponível no Windows XP Home Edition (embora o SteadyState se baseie nele), o SteadyState faz surgir diversas opções de configuração e segurança que são comuns no cenário de computação compartilhada.
A Figura 1 mostra a tela de configuração referente a Definir Restrições de Computador. Observe que se trata de configurações genéricas que serão aplicadas ao computador inteiro. Essas configurações são selecionadas basicamente para minimizar os riscos de segurança no sistema – e, no caso de acesso à unidade USB, a capacidade de remover coisas do sistema. (Quando você examinar as configurações por usuário, verá também uma forma de bloquear o acesso de leitura a todas ou algumas unidades.)
Figura 1 Restrições de computador no SteadyState
Figura 1 Restrições de computador no SteadyState
É importante observar que a configuração USB só ficará ativa enquanto estiver sendo executada na instalação real do Windows em que o SteadyState foi configurado. Para se proteger contra ataques offline, você deve configurar corretamente o BIOS para impedir a inicialização de dispositivos USB ou de CD e proteger por senha o próprio BIOS.
Claro que isso não é infalível. Lembre-se da terceira lei citada em "10 Immutable Laws of Security" (microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx): "Se uma pessoa mal-intencionada tiver acesso físico irrestrito ao seu computador, o computador não é mais seu." Um indivíduo dedicado, com tempo suficiente e as ferramentas certas, consegue ignorar uma senha de BIOS.

Proteção de Disco do Windows
Se você já usou o Windows XP Embedded a partir de um CD ou o Windows PE 2.0, o que vou descrever lhe parecerá familiar, e por uma boa razão: eles têm uma história em comum. A Proteção de Disco do Windows trabalha para fornecer um "desfazer" completo da partição do sistema Windows salvando todas as alterações feitas na partição do sistema em um cache na mesma partição. Esse aspecto do SteadyState é fundamental, já que ele é o componente que permite desfazer as alterações feitas por usuários do sistema ao longo do tempo.
A Proteção de Disco do Windows é útil principalmente se você quiser garantir que, com o tempo, poderá reverter rapidamente (após uma reinicialização não agendada ou em um intervalo agendado) para o estado implantado inicial do sistema. Ela tem quatro modos que podem ser definidos na caixa de diálogo exibida na Figura 2:
Figura 2 Configurando a Proteção de Disco do Windows
Figura 2 Configurando a Proteção de Disco do Windows
Desativado A Proteção de Disco do Windows está completamente desativada, e todas as alterações são gravadas normalmente no disco.
Ativado – Descartar alterações na inicialização A Proteção de Disco do Windows está desativada, e as alterações serão descartadas toda vez que o computador for reiniciado. Basicamente, isso significa que o sistema reverterá exatamente para o que era quando você verificou e salvou esta opção.
Ativado – Descartar alterações na hora definida Quase idêntica às opções anteriores, exceto pelo fato de que as alterações são descartadas em uma hora definida, e não na próxima reinicialização. Esta seria uma escolha lógica se você quisesse descartar alterações diária ou semanalmente.
Ativado – Reter alterações permanentemente Embora conceitualmente confundido com Desativado, a diferença está no fato de que este é um modo temporário. Por exemplo, você pode usar este modo se quiser aplicar atualizações de aplicativo, instalar novos aplicativos ou configurar o sistema. Não é um modo a ser executado durante um período de tempo significativo.
Observe que a Proteção de Disco do Windows requer uma reinicialização para alterar entre qualquer um desses modos.

Agendar Atualizações de Software
A configuração Agendar Atualizações de Software é útil sob o aspecto de que o SteadyState agora pode ativar ou desativar a Proteção de Disco do Windows automaticamente. Se você deixar o SteadyState controlar suas atualizações, ele definirá a Proteção de Disco do Windows para manter as alterações durante a atualização e depois retornar a Proteção de Disco do Windows ao que estava definido anteriormente. Eu recomendo enfaticamente esta configuração, pois ela tira um fardo da sua lista de tarefas de gerenciamento.
Os softwares de segurança a seguir têm suporte por meio do recurso de atualização em Atualizações de Software: Computer Associates eTrust 7.0, McAfee VirusScan, Windows Defender e TrendMicro 7.0.

Gerenciador de Contas de Usuário
A opção Adicionar Usuário permite configurar novos usuários para o sistema. A Figura 3 mostra as opções disponíveis para o novo usuário: nome, senha, uma imagem para representar o usuário e o local do perfil do usuário. Depois de criar os usuários, você poderá definir Configurações e Restrições de Usuário para cada uma dessas contas locais. O bom é que, uma vez adicionada e configurada uma conta no sistema, é possível exportá-la e depois importá-la para outro sistema, conforme necessário (ou arquivá-la).
Figura 3 Adicionando contas de usuário
Figura 3 Adicionando contas de usuário
Um aspecto útil do Gerenciador de Contas de Usuário é que os perfis de usuário podem ser criados em uma partição secundária através do menu Local do Usuário mostrado na Figura 3. Normalmente, os perfis devem ser criados na partição do Windows, a menos que você tenha especificado manualmente um local diferente em Documents and Settings durante a instalação, por meio de um arquivo unattend.txt. Essa abordagem é particularmente útil com o SteadyState já que descarta alterações feitas na partição do sistema Windows quando a Proteção de Disco do Windows está habilitada. Se você quiser que o perfil de um usuário permaneça consistente através de limpezas de cache da Proteção de Disco do Windows, basta especificar o perfil do usuário a ser armazenado em outra partição local ao criar o usuário usando o Gerenciador de Contas de Usuário.
Esse processo funciona reinicializando para limpar o cache da Proteção de Disco do Windows, aplicando as atualizações e depois reinicializando novamente para reiniciar a Proteção de Disco do Windows. Além do Windows Update, o SteadyState atualizará os arquivos de assinatura de vários aplicativos antivírus populares com suporte (consulte a barra lateral "Obtendo e usando o SteadyState"). Caso não haja suporte para o seu aplicativo ou seja necessário executar outro atualizador, você poderá fazer a atualização manualmente – basta verificar se a Proteção de Disco do Windows está desabilitada quando fizer isso; caso contrário, a atualização da assinatura será perdida.

Configurações e Restrições do Usuário
Depois que você tiver selecionado um usuário, o SteadyState dividirá as Restrições de Usuário em quatro categorias. Elas derivam das configurações de Diretiva de Grupo e provavelmente lhe parecerão familiares.
As configurações Geral controlam perfis de usuário e configurações de logoff forçadas. Isso inclui configurações para bloqueio do perfil e definição de intervalos de tempo limite para fazer logoff após uma duração configurada de uso ou um tempo ocioso.
As configurações Restrições do Windows, mostradas na Figura 4, controlam itens de configuração específicos do Windows. Alguns exemplos são a funcionalidade do Windows Explorer e a remoção de acesso a itens da interface do usuário do Windows, como componentes do Menu Iniciar. A capacidade de bloquear o acesso a unidades específicas por letra de unidade também está disponível, assim como a capacidade de desabilitar a gravação de CD.
Figura 4 Restrições de usuário específicas ao Windows
Figura 4 Restrições de usuário específicas ao Windows
A guia Restrições de Recurso, mostrada na Figure 5, controla o acesso granular à maior parte da funcionalidade do Internet Explorer® e permite que você defina a home page do Internet Explorer e controle a funcionalidade do Microsoft® Office até um certo grau – basicamente, controlando a capacidade de execução de scripts do Visual Basic® for Applications (VBA).
Figura 5 Restrições de recurso
Figura 5 Restrições de recurso
As configurações Bloquear Programas (consulte a Figura 6) controlam a capacidade de executar aplicativos específicos – basicamente, você cria uma lista negra. Ela é preenchida com vários aplicativos comuns, e é possível adicionar outros. Observe que esses itens são bloqueados com base em uma definição do caminho deles. Se um usuário tiver permissão para mover um aplicativo para outro lugar no sistema, a regra do caminho não será mais aplicada. Contudo, as restrições de acesso ao sistema, as ACLs de diretório e o arquivo aplicado corretamente de outras formas impedirão a facilidade de fazer isso.
Figura 6 Impedindo a execução de programas
Figura 6 Impedindo a execução de programas
Outro recurso novo importante do SteadyState se baseia nos modelos pré-configurados que especificam Níveis de Restrição relacionados tanto a Restrições do Windows como Restrições de Recurso. Os modelos facilitam a obtenção de um trabalho de configuração de linha de base, dependendo do nível desejado de bloqueio de função/recurso. Claro que também é possível criar modelos personalizados.

Limitações do SteadyState
O SteadyState é excelente para ajudar uma organização a estabilizar seus sistemas de computação compartilhada. Para uma ferramenta comercial, seria bom. Para uma ferramenta livre, é admirável. Mas lembre-se: ele não faz tudo.
Sistemas de computação compartilhada são alvos fáceis de ataque ou até de abuso não intencional. Você deve garantir que esses sistemas fiquem isolados de informações às quais eles não precisam ter acesso. Embora o SteadyState tenha a capacidade de bloquear o acesso a aplicativos, essas imposições são controladas pelas Diretivas de Restrição de Software. E, como Mark Russinovich observou alguns anos atrás, há técnicas por meio das quais um usuário experiente pode montar um aplicativo que pareça inofensivo, mas mesmo um Usuário Limitado é capaz de permitir que essas diretivas sejam ignoradas (blogs.technet.com/markrussinovich/archive/2005/12/12/circumventing-group-policy-as-a-limited-user.aspx). Sem bloquear o acesso à Internet e o acesso a todos os dispositivos, essa é uma vulnerabilidade que você precisará ter em mente. Lembre-se sempre da Lei nº 3...
Obviamente, o SteadyState é apenas um componente de um sistema de computação compartilhada bem-configurado. A aplicação regular de atualizações através do Windows Update e a configuração correta do Firewall do Windows (ou algum outro firewall) são importantes. Além disso, não deixe de instalar e configurar antivírus, anti-spyware e outras contramedidas de segurança necessárias para a análise dos possíveis riscos ao computador. Da mesma forma, controle o acesso ao computador – se não for possível, controle o que o computador pode ver. E não armazene dados confidenciais localmente.
Finalmente, ao qualificar sua plataforma, verifique se o teste inclui o uso do SteadyState (com a Proteção de Disco do Windows habilitada, a menos que você não pretenda usá-la) e todos os softwares adicionais que você planeja executar no sistema. Convém garantir que o software e o SteadyState funcionam juntos sem problemas.

Suporte ao SteadyState
Os comentários dos usuários sobre o SteadyState que eu li foram muito positivos. Pelo que ouvi dizer até agora, existem algumas armadilhas envolvendo a ordem em que os usuários precisam ser adicionados. Muitas dessas armadilhas (junto com outras dicas e truques) são discutidas na Comunidade do Windows SteadyState (convenientemente vinculada a vários locais na documentação e no aplicativo SteadyState) em forums.microsoft.com/windowstoolsandutilities.
Antes de começar, recomendo também que você reveja o manual do SteadyState, que está disponível em go.microsoft.com/fwlink/?LinkId=104722. Ele fornece algumas dicas e truques para usar o SteadyState com sucesso.

Conclusão
O SteadyState oferece – gratuitamente! – um excelente pacote de recursos para qualquer sistema Windows XP ao qual você precise controlar o acesso. O recurso Proteção de Disco do Windows consideravelmente aprimorado e os aperfeiçoamentos na interface do usuário significam mais facilidade na implantação e no gerenciamento dos sistemas de acesso compartilhado.
Sejam as suas necessidades para sistemas de laboratório de computadores, quiosques de acesso compartilhado para visitantes ou funcionários, salas de treinamento ou qualquer outra necessidade de computação compartilhada, o SteadyState pode ajudá-lo a obter – e manter – os sistemas em funcionamento com mais facilidade. E isso não vai exigir que você faça mais nenhuma recriação de imagens semanal apenas para dar o salto inicial em um sistema novamente. Isso é um aprimoramento enorme, a meu ver.

Wes Milleré gerente de produto técnico da Initiate Systems (InitiateSystems.com) em Austin, no Texas. Antes disso, ele trabalhou na Winternals Software e como gerente de programas na Microsoft. Você pode contatá-lo pelo email technet@getwired.com.


 Anota&#231;&#245;es de campo: Sua tarefa mais importante do dia
Anotações de campo
Sua tarefa mais importante do dia
Eric N. Bush

Bill Gates se afasta do escritório duas vezes por ano para o que ele chama de "semana da reflexão". Ele se isola de pessoas, telefonemas e emails e se dedica à leitura. Gates reflete sobre o estado da tecnologia na Microsoft e no mundo. Ele tenta entender no que a sua empresa e as outras estão trabalhando e como podem progredir de maneira mais estratégica. Gates sabe o valor da reflexão e do planejamento.
Cada um de nós pode se beneficiar reservando um tempo todos os dias para simplesmente pensar e planejar – um tempo para formular idéias, resolver problemas, priorizar tarefas, definir metas e sonhar acordado. Experimente realizar esse exercício na mesma hora e local todos os dias e evite outras interações durante esse período. Sua tarefa mais importante é planejar e priorizar o que fará com o seu dia. Se você estiver em uma função de gerenciamento, pode passar a maior parte do tempo planejando e priorizando o trabalho de outras pessoas.
Esteja você gerenciando a rede corporativa, administrando um importante banco de dados ou projetando e gerenciando os sistemas de informação corporativos, há questões que surgem diariamente que podem desviar sua atenção de continuar progredindo no trabalho, que é o que realmente conta. No final do dia, você não pode dizer realmente se avançou ou simplesmente ficou para trás.
Sua meta deve ser tornar-se mais preemptivo, mais organizado e melhor preparado para responder a emergências de TI. Planejando, você pode passar de reativo para proativo. Para fazer essa mudança, porém, você tem de refletir, planejar e priorizar. É de grande ajuda manter uma lista de tarefas – organizada em três categorias – e começar o dia revendo-a: Em andamento, URGENTE e Lista de desejos. Usando essas listas, você pode arrumar tempo para criar soluções que, antes de mais nada, evitam crises.
A lista Em andamento é fundamental para colocar tudo em ordem. É vital que você faça progressos nessas tarefas importantes todos os dias. Prontifique primeiro as metas principais do seu grupo e da sua empresa. Tarefas que não afetem diretamente essa prioridade podem descer de posição na lista. Se você ocupa um cargo de gerência, implemente um processo que ajude os funcionários a ficarem em sincronia com as principais prioridades.
As listas URGENTE e de desejos normalmente são utilizadas para aqueles planos estratégicos que pouparão tempo e dinheiro à empresa, tornando-a mais competitiva. Identifique essas tarefas e tente realizá-las lenta e metodicamente, movendo-as para a lista Em andamento à medida que forem subindo de prioridade.
Não se esqueça, porém: só porque você tem essas listas priorizadas não significa que tudo será realmente feito. Eis algumas dicas para ajudá-lo a dar cabo de suas tarefas:
  • Livre-se primeiro das tarefas rápidas e fáceis.
  • Em seguida, faça aquilo que não está motivado a fazer.
  • Por último, ataque as tarefas interessantes.
  • Evite alternância de contexto. Serialize seu trabalho, se possível.
  • Entretanto, caso você se veja bloqueado em algum ponto, passe para a próxima tarefa até poder voltar.
  • Delegue ou recuse tarefas que não fazem sentido para você, ou sugira alternativas.
  • Saiba quando você trabalha melhor e é mais produtivo. Reserve esse tempo para se concentrar em tarefas importantes.
Saber planejar o seu tempo com sabedoria o ajudará a dar o melhor de si. Pessoas que passam pela vida sem um plano nunca são realmente felizes com o que conquistam porque, antes de mais nada, nunca sabem de verdade onde estão indo.

Eric N. Bush é chefe de desenvolvimento de software do grupo Engineering Excellence da Microsoft. Ele trabalha como consultor interno e instrutor de cursos, orientando aprimoramentos organizacionais e de engenharia nas áreas de habilidades humanas, processo e tecnologia. Você pode contatá-lo pelo email ericbush@microsoft.com.


 Segredos do Windows: Lembre-me de nunca fazer isso novamente
Segredos do Windows
Lembre-me de nunca fazer isso novamente
Raymond Chen

Há uma ferramenta antiga para a série Windows® 95 de sistemas operacionais que é conhecida como ASD, Automatic Skip Driver (Ignorar driver automaticamente). A sua primeira reação à essa ferramenta pode ter sido de estranheza em função do nome, e você pode até mesmo ter suspeitado que as letras ASD tivessem outro significado. E você estaria totalmente certo.
O Windows 95 precisava lidar com vários dispositivos que não eram do tipo Plug and Play porque a grande maioria dos sistemas da época eram anteriores à especificação Plug and Play. A detecção de hardware na ausência de dispositivos adequados de Plug and Play era muito arriscada.
Por exemplo, a detecção de modem era realizada pela emissão de consultas de valores de vários registros de modem. Embora houvesse um conjunto de comandos de modem básico razoavelmente bem estabelecido, havia uma variação significativa na implementação de partes mais obscuras da linguagem de comando. Obviamente, essa inconsistência foi frustrante para programas de comunicações, pois requeria o acréscimo de casos especiais para vários modelos de modem, a fim de acomodar suas peculiaridades. No entanto, a inconsistência foi um benefício inesperado ao Windows: como cada modem tinha um comportamento sutilmente diferente, o Windows podia investigar esses pontos obscuros e comparar o comportamento do modem em relação a uma tabela de modems conhecidos e suas respostas.
Havia uma pessoa na equipe do Windows 95 cujo trabalho era instalar todos os tipos de modem e executar um pequeno programa que colocava o modem em funcionamento, explorava os pontos obscuros e coletava os resultados de cada um, de modo que um banco de dados de modem completo pudesse ser criado. Se você ainda tiver acesso a uma máquina executando o Windows 95, poderá dar uma espiada no diretório Windows\Inf e verificar todos esses arquivos cujos nomes iniciam com MDM. Há mais de um megabyte de arquivos de informações sobre dispositivos dedicados a modems. Isso significa alguns anos da vida de alguém recolhidos em um megabyte de números hexadecimais não legíveis.
A detecção de modems era muito segura, pois praticamente todos os modems se comportavam da mesma forma em um nível elevado; o atrativo estava todo nos detalhes. Muito mais assustadores eram os dispositivos que utilizavam portas de E/S. Por exemplo, para detectar se uma placa de vídeo específica havia sido instalada, o módulo de detecção de placa de vídeo do Gerenciador de Configurações do Windows 95 enviava valores cuidadosamente selecionados para portas de E/S específicas e fazia a escuta de quaisquer respostas a partir do dispositivo. Se o dispositivo respondesse imediatamente, então se pressupunha que ele havia encontrado o que estava procurando. Caso contrário, ele passava para o próximo modelo de placa de vídeo.
É claro, se o dispositivo instalado nessa porta de E/S não fosse a placa de vídeo sendo testada pelo Gerenciador de Configurações, valores sem sentido enviados não teriam qualquer utilidade. Dependendo do dispositivo, ele poderia parar ou reiniciar a máquina. Isso não era muito útil para o Gerenciador de Configurações. Foi assim que surgiu o módulo conhecido como ASD.
Antes de realizar esses testes de hardware potencialmente catastróficos, o Gerenciador de Configurações criava um arquivo que dizia basicamente, "Essa não! Estou prestes a danificar X!". Essa era a versão do computador do envelope clássico "Abra caso eu morra", que o herói de um filme de ação deixava com sua namorada antes de sair para uma missão suicida para combater o bandido.
Se o dano realmente fizesse com que o computador fosse interrompido, falhasse ou reiniciasse, então, na próxima vez que o sistema fosse iniciado, ele veria esse arquivo mágico e "abriria o envelope" para ver se esse dano seria o responsável pela falha do computador. O sistema então concluiria que a tentativa de detectar o dispositivo X era catastrófica e nunca mais faria isso novamente!
O módulo que fazia esse trabalho era chamado de ASD. As letras ASD representavam "Attempting Something Dangerous" (tentando algo perigoso).

Raymond Chenpossui o site The Old New Thing (A velha novidade), e escreveu um livro homônimo (Addison-Wesley, 2007) para tratar da história do Windows e da programação Win32. Ele é cauteloso pois o assunto é delicado.