 TechNet Magazine October 2007

TechNet Magazine October 2007

Computação verde: Crie um data center verde

As empresas de todo o mundo começam a pensar em formas de economizar energia e reduzir custos, embora ainda haja pouca orientação sobre como agir nesse sentido. Comece com a nossa introdução ao planejamento, à criação e à implementação de um data center verde na sua organização.

Dave Ohara Administração do Windows: Um guia para a replicação do Active Directory

O Active Directory proporciona uma grande flexibilidade para o suporte a ambientes de grande porte ou descentralizados. No entanto, manter a integridade dos seus dados pode representar um desafio. A replicação do Active Directory define a forma como as atualizações são comunicadas por todo o ambiente e como os conflitos são resolvidos. Saiba aqui tudo o que é preciso para vencer esse desafio.

Laura E. Hunter System Center: Novas ferramentas para o gerenciamento de atualizações de software

Você descobrirá, no System Center Configuration Manager 2007, um mecanismo totalmente novo para lidar com o gerenciamento de atualizações, garantindo melhor conformidade e imposição em cada cliente. Saiba como essa abordagem aperfeiçoada pode ajudá-lo a ter todas as suas máquinas atualizadas.

Steve Rachui Comunicações: Servidores de Transporte de Borda do Exchange na Microsoft

Como a Microsoft garante a entrega de mensagens legítimas aos funcionários e ao mesmo tempo afasta o fluxo de conteúdo mal-intencionado do ambiente de mensagens? Uma forma de fazer isso consiste na implantação dos servidores de Transporte de Borda do Exchange Server 2007 e do Forefront Security for Exchange Server. Descubra como essas tecnologias podem manter sua organização segura.

Kay Unkroth SQL Server: Otimizando o desempenho de CPU do SQL Server

A chave para uma utilização íntegra de CPU no seu servidor de banco de dados consiste em verificar se a CPU está mesmo dedicando seu tempo a processar o que você deseja que seja processado, ou se está desperdiçando ciclos com código mal otimizado ou hardware ineficiente. Eis algumas dicas para obter o máximo do SQL Server e do seu hardware.

Zach Nichter Do editor: O melhor ainda está por vir

Joshua Hoffman Toolbox: Novos produtos para profissionais de TI

Greg Steen P&R do SQL: Disparadores de logon, desfragmentações de arquivos de dados e muito mais

Edited by Nancy Michell Utilitário em destaque: Virtual Machine Remote Control Plus

Matthijs ten Seldam The Business of IT: Calculando o valor da infra-estrutura de TI no setor governamental

Acer Maamoun The Cable Guy: O protocolo Authenticated IP

Joseph Davies Windows PowerShell: Trabalhando sem script

Don Jones Ei, Equipe de Scripts!: Que venha o Silverlight

The Microsoft Scripting Guys Security Watch: O BitLocker e a complexidade da confiança

Justin Troutman Os arquivos da área de trabalho: Guia avançado para usuários do WIM e do ImageX

Wes Miller Anotações de campo: Recicle seu PC

Jim Lynch Segredos do Windows: Chamando o Dr. Watson

Raymond Chen


 Computa&#231;&#227;o verde: Crie um data center verde
Computação verde Dave Ohara

Crie um data center verde
Visão geral:
  • Sistemas de monitoramento de energia
  • Características essenciais de um data center verde
  • Efeitos da H.R. 5646
  • Práticas recomendadas para introdução

Verde é o assunto do momento, e o conceito está tendo um impacto na forma como as pessoas pensam nos data centers. Empresas de todo o mundo estão anunciando formas de economizar energia e reduzir
os custos com a compra de novos hardwares e serviços. Porém, ainda há pouca orientação sobre como agir para controlar os custos de energia. Antigamente, a eletricidade era tratada como sendo uma despesa que sobrecarregava, como o custo do espaço. Mas, com o aumento nos custos de energia e os problemas referentes à confiabilidade e à capacidade, a eletricidade exige uma estratégia própria específica.
Projetos relacionados à otimização do desempenho e à redução dos custos fazem parte das boas práticas diárias em praticamente todas as áreas da empresa. Então, por que não tratar os custos de energia da mesma forma?
Como profissionais de TI, muitos de nós tomamos decisões sobre a configuração e a instalação de servidores, sobre as especificações referentes ao equipamento comprado pelas nossas organizações e sobre os requisitos para a atualização e a construção de data centers. Nós até mesmo damos opiniões sobre os estágios iniciais durante o desenvolvimento de aplicativos. Quando aparecem esses projetos, é claro que temos uma oportunidade de ouro de ser ecológicos e influenciar o consumo eficiente em qualquer data center.
A primeira parte de qualquer estratégia é conhecer o uso atual da energia. Você precisa saber onde ela é usada e por qual equipamento específico, bem como quais são os usos eficientes e quais são os desperdícios no data center. Infelizmente, é raro encontrar um medidor de consumo de energia em vigor capaz de detalhar o uso em um nível no qual as pessoas possam ver os resultados de suas ações. A maioria das organizações costuma ver apenas uma conta de energia elétrica mensal que informa o consumo geral total. Isso oferece pouco incentivo à economia de energia, uma vez que as pessoas jamais vêem o impacto de suas decisões e não há meio para que elas comprovem que suas alterações efetivamente economizaram energia.
Um dos primeiros problemas enfrentados pelas pessoas ao considerar a iniciativa de um data center verde é se elas têm respaldo dos superiores. Suponho que a resposta seja "ainda não". O suporte dos executivos exige um sério comprometimento com recursos e orçamento para a iniciativa. E, enquanto houver muito o que se discutir sobre os data centers verdes, a realidade é que ainda normalmente faltará um suporte sério dos superiores hierárquicos. Se já contasse com esse suporte, você certamente já estaria implantando um data center verde agora.
Ainda assim, mesmo supondo que você não esteja recebendo o apoio necessário, há muito o que fazer para que a iniciativa do data center verde seja bem-sucedida. E como você determina as ações efetivas para poder atingir as metas? Felizmente, a eficiência em energia não é um conceito novo e os profissionais de TI ainda têm muito o que aprender com outros setores.

Resumindo o consumo de energia
Um dos maiores desafios que encontrei ao escrever este tópico estava relacionado à enorme variação dos números fornecidos por fontes diferentes. Alguns estudos dizem que os data centers são responsáveis por entre 1,2% e 2% da eletricidade consumida nos Estados Unidos. Segundo estimativas, se considerássemos os data centers um setor isolado da economia americana, eles estariam próximos de se tornar um dos cinco setores que mais usam energia. Enquanto isso, a eletricidade pode responder por entre 15% e 20% dos custos operacionais em um data center corporativo nos Estados Unidos.
Um estudo feito nos laboratórios Lawrence Berkeley National Laboratories para o American Council for an Energy-Efficient Economy (Conselho Americano de Economia com Eficiência Energética) determinou que os data centers podem usar 40 vezes mais energia do que os prédios comerciais convencionais. O estudo fornece detalhes sobre o que pode ser feito para aumentar a eficiência energética das instalações (consulte eetd.lbl.gov/emills/PUBS/PDF/ACEEE-datacenters.pdf). Um bom ponto de partida é determinar em que medida o data center usa as práticas recomendadas estabelecidas nesse estudo.
Obviamente, há muitas perspectivas, muitos estudos e muitos números a respeito do consumo de energia. No entanto, um tema que permanece constante é que há muita perda. Basta pensar em quantos servidores foram comprados com a intenção de oferecer o melhor custo—benefício. Isso significa comprar o máximo possível de capacidade em CPU, memória, armazenamento e fontes de alimentação redundantes mantendo-se dentro de um orçamento. Muitos desses servidores têm funcionado com uma média de utilização entre 10% e 15% por cento nos últimos três a cinco anos. Embora as pessoas normalmente prestem atenção nas CPUs, os demais componentes desempenham um papel importante aqui – memória, discos e interfaces de rede são todos consumidores de energia significativos e, quando combinados, excedem o consumo de energia da CPU.
Ao mesmo tempo, o excesso de capacidade do hardware – em tudo, desde processadores a fontes de alimentação redundantes – pode acarretar uma perda significativa. Dada a cultura avessa a riscos da maioria dos departamentos de TI, o excesso de capacidade é a norma. A decisão mais segura é ter excesso de capacidade de hardware, mesmo que essa talvez não seja necessariamente a melhor decisão em termos financeiros. Mas embora seja um fator essencial, a energia costuma ser deixada de lado durante o cálculo dos custos do ciclo de vida. Infelizmente, não há incentivos para a compra de soluções eficientes, por não haver relação custo—benefício para os tomadores de decisão após a implantação.
No entanto, há um ponto intermediário a ser alcançado. O pêndulo se desloca de outra forma quando os executivos percebem a capacidade mínima com que o hardware do data center está sendo efetivamente usado, e vêem na consolidação do servidor uma forma de reduzir os custos. É muito mais fácil dimensionar os servidores corretamente com antecedência do que tentar a consolidação após sua implantação.
À medida que o setor de TI atinge um novo nível de maturidade, a otimização com a redução dos custos se torna uma prioridade. O consumo de energia é um indicador de que os executivos podem usar como medida a eficiência das decisões tomadas a respeito do ciclo de vida do hardware de TI. A AMD, a Intel e os OEMs de servidores e componentes estão todos fazendo referências ao desempenho por watt de suas plataformas. Os números do desempenho por watt podem ser usados para calcular um custo operacional usando a fórmula inversa: watts por unidade de desempenho. Com o conjunto de pessoas envolvidas no desenvolvimento de soluções em TI – desde instalações, desenvolvimento de aplicativos, arquitetos, operações e unidades de negócios –, o desempenho por watt responde à pergunta "O que eu ganho em troca?" e permite que você veja como as soluções se comparam em termos de eficiência da energia.
Por que é prática comum ignorar os custos de energia e deixar de lado as decisões que afetam os custos operacionais e das instalações? Quantos data centers você já viu em capacidade máxima por conta de restrições de energia ou de resfriamento? Houve um tempo em que ter espaço físico o suficiente para o data center era o problema. No entanto, hoje em dia o problema é se você tem capacidade o suficiente para operar e resfriar todo o equipamento – e com que rapidez, antes que se esgote a capacidade.

A importância dos sistemas de monitoramento de energia
O consumo preciso de energia pode ser difícil de medir. Como mencionei anteriormente, a maioria das empresas acumula os custos de energia como um todo, em vez de dividir o consumo de energia por unidades específicas. Esse método de tratar a energia como uma sobrecarga geral cria a percepção de que os custos de energia vão além do controle da unidade de negócios. Mas isso não é verdade.
Um data center pode usar dezenas de vezes mais energia por metro quadrado do que o espaço comercial padrão e, por isso, até mesmo aperfeiçoamentos mínimos na eficiência em data centers podem contribuir com economias significativas. Não é surpresa que a economia seja a principal razão pela qual os data centers estão implementando programas de economia de energia. O problema é que o método de menor custo costuma estar em vigor para controlar o consumo de energia e os custos mensais em operações do data center das instalações são acumulados. Dessa forma, os custos são alocados em grupos com base no espaço que ocupam e/ou por conexão de porta – essa abordagem proporciona uma divisão bem menos precisa dos custos reais para a execução de um equipamento do data center.
É raro que uma organização tenha uma solução em vigor para medir o uso real da energia por dispositivos individuais do data center – principalmente por conta do fato de que a instalação de um sistema para medir e gerar relatórios exige um investimento inicial significativo. No entanto, investir em um sistema como esse pode acarretar uma economia além do esperado.
É claro que apenas um sistema de monitoramento de energia não é o suficiente – você precisará de um plano que use os dados coletados para melhor gerenciar o consumo de energia e acabar obtendo um retorno do investimento. Considere a empresa canadense Abitibi Consolidated, a maior produtora mundial de jornais e de produtos em papel. Em 2001, quando o mercado de energia elétrica de Ontário foi desregulamentado, a Abitibi Consolidated ficou exposta aos preços e à disponibilidade de um mercado instável. Para otimizar as compras de energia, a empresa implementou um sistema de monitoramento e de medição. O novo sistema se pagou em questão de alguns meses, graças a 1% de economia obtido com a simples compra mais eficiente da energia.
Quanta energia você precisa economizar para justificar uma atualização no monitoramento de energia do seu data center? Bill Laing, gerente geral de desenvolvimento do Windows Server® 2008 na Microsoft, disse em entrevista recente que a nova versão do Windows Server, capaz de economizar energia por padrão, poderia reduzir o consumo em até 20%, uma economia significativa (A Figura 1 mostra algumas das Opções de Energia disponíveis no Windows Server 2008 beta 3). Observe, no entanto, que a economia não pode ser calculada como uma redução direta no custo da energia consumida. Há vários outros fatores envolvidos como, por exemplo, o custo da construção de um novo data center e o número de outros sistemas que atualmente dão suporte a configurações menos eficientes.
Figura 1 Opções de Energia no Windows Server 2008 beta 3
Figura 1 Opções de Energia no Windows Server 2008 beta 3
Agora, você poderia selecionar a opção Desempenho e Energia de Processador Balanceados pelo Servidor no Windows Server 2003 SP1. Mas, sem um sistema de medição em vigor, você não conseguirá quantificar a economia ou qualquer outro fator que esteja envolvido na realização e no suporte dessa alteração.
Também vale a pena observar que, para muitos data centers, o consumo de energia normalmente varia apenas 4% durante um período de 24 horas, o que indica que ele independe da carga. Com as recentes inovações feitas por fornecedores de hardware, esse resultado está mudando em novos equipamentos e o volume de energia consumido está ficando abaixo das menores cargas.

Definindo o data center verde
Eu poderia ficar páginas listando os critérios ou as características que tornam um data center verde. É claro que não tenho espaço para abordar tudo neste artigo, mas pretendo realçar algumas características importantes que você deve ter em mente caso realmente pretenda implementar um data center verde. Mesmo que esteja apenas nos estágios de planejamento no momento, você pode fazer uma comparação com esta lista para determinar onde o data center se encontra atualmente:
  1. Os medidores são usados para dividir o uso de energia no nível dos componentes (como, por exemplo, um servidor 2U, um servidor 4U, um comutador, uma SAN e um no-break) e quais são as unidades de negócio responsáveis pela energia usada por esses componentes.
  2. O uso da energia é monitorado continuamente para determinar os picos e as baixas nas demandas de energia.
  3. As capacidades de energia são monitoradas no nível total de um data center até os circuitos para garantir que todos estejam dentro dos limites aceitáveis.
  4. O plano de economia de energia é documentado e recompensado.
  5. O plano de economia de energia é revisado regularmente, e a ação corretiva é tomada para corrigir falhas.
  6. A determinação de como os custos são cobrados das unidades de negócios é usada para formar um comportamento, o que incentiva a economia de energia em todas as unidades de negócios. Esse ponto deve ser administrado em nível executivo.
  7. A limitação de CPU está habilitada nos servidores, e o laboratório de desempenho avalia a energia consumida em várias cargas.
  8. A criação de perfis térmicos é usada para identificar pontos de aquecimento e de sobrecongelamento.
  9. A engenharia de desempenho de TI inclui medidas de eficiência energética.
  10. Os comentários sobre os dados dinâmicos estão disponíveis para organizações individuais, o que permite que elas reajam de acordo. (A California ISO chega a fornecer dados em tempo real para o público em seu site, como mostra a Figura 2.)
Figura 2 O site da California ISO fornece um instantâneo dinâmico que inclui a demanda e o nível atuais da economia solicitada aos clientes
Figura 2 O site da California ISO fornece um instantâneo dinâmico que inclui a demanda e o nível atuais da economia solicitada aos clientes
Quanto mais dessas características estiver em vigor, mais próximo você estará de executar um sistema de monitoramento de energia avançado. Eu incluí um scorecard (consulte a Figura 3) com oito perguntas que você pode se fazer para saber o nível atual do data center: básico, intermediário ou avançado.
Figure 3 Em que medida o seu data center é verde? (Close Figure 3)

Nível | Você ...
Básico | Revisa a sua conta de eletricidade mensalmente?
Verifica o equipamento elétrico regularmente para planejar a capacidade?
Intermediário | Automatizou a medição e a geração de relatórios da carga e do consumo de circuitos elétricos?
Verifica o consumo do equipamento na hora da compra?
Avançado | Monitora o consumo de energia por rack, dispositivo e circuito?
Analisa os dados históricos monitorando e gerando relatórios?
Usa relatórios em tempo real do consumo de energia dos departamentos para compreender o impacto das alterações e das implantações?
Usa dados para negociar tarifas de energia favoráveis com a empresa prestadora de serviços?

Conhecer é metade da batalha
Outro problema que você enfrentará é a padronização em toda a organização. Fazer uma alteração como a que eu descrevi neste artigo – uma que mude o paradigma por meio do qual a energia é medida e outro que envolva a participação de unidades de negócio de toda a organização – envolve o ajuste entre os grupos de instalações de vários data centers que trabalham com um amplo conjunto de grupos de TI. Esses problemas organizacionais são os que mais impedem a colocação de um programa de economia de energia em vigor.
É importante ter certeza de que há apenas uma pessoa ou responsável pela equipe incumbida de compreender o consumo de energia nos data centers. Esse centro de conhecimento (que a grande maioria das empresas não tem quando o assunto é consumo de energia) é essencial. Também é importante que as ferramentas coletem dados de instalações diferentes de maneira uniforme e informem os resultados para cada unidade de negócios de forma consistente (a Figura 4 mostra um painel de exemplo para informar os dados).
Figura 4 Painel de monitoramento de dados globais de exemplo (cortesia da OSIsoft)
Figura 4 Painel de monitoramento de dados globais de exemplo (cortesia da OSIsoft)
Sem os instrumentos certos, você não saberá se está realmente operando com eficiência – nem as unidades de negócio individuais saberão se seus esforços estão produzindo resultados. Se realmente deseja mudar o comportamento humano, você precisa dar aos usuários as informações em tempo real com as tendências históricas de dados para que eles possam visualizar suas ações. Na verdade, você pode recompensar os grupos por feitos relacionados à eficiência energética, caso a unidade de negócios esteja em um sistema diferente, usando um outro conjunto de ferramentas e medidas distintas para informar o sucesso.

Forças do setor
Não se sinta sozinho em suas iniciativas para tornar a empresa verde. Líderes em outros mercados – desde empresas como Boeing e Toyota até órgãos governamentais, como o Estado da Califórnia – estão fazendo grandes investimentos para tornar as operações e os produtos mais eficientes energeticamente.
Para o mundo da TI, em 2006, a Câmara dos Deputados dos EUA aprovou um projeto de lei – H.R. 5646, agora lei promulgada 109-431 – incumbindo a EPA (Environmental Protection Agency, Agência de Proteção Ambiental) de investigar os custos de energia e o consumo de eletricidade por servidores e data centers, além dos possíveis efeitos de passar a usar sistemas de energia mais eficientes. O estudo, realizado pelo programa da EPA, ENERGY STAR, projetou um crescimento a curto prazo no uso da energia por computadores e data centers nos EUA, avaliou o custo potencial e as economias de energia relacionados aos aprimoramentos em eficiência de energia do servidor e do data center, além de ter estimado os incentivos potenciais e os programas de voluntariado para promover servidores e data centers energeticamente eficientes. Os resultados finais do estudo foram apresentados ao Congresso em agosto de 2007. É possível encontrar mais informações sobre esse estudo em energystar.gov.
Também estão sendo desenvolvidos novos padrões para prédios verdes. Esses padrões exigem critérios como recursos de medição por hora para circuitos de acordo com a finalidade e o consumo de energia, medidores que informem os dados do consumo de energia a um sistema de gerenciamento de dados e sistemas medidores de gerenciamento de dados que armazenem dados e criem relatórios de usuário mostrando o consumo de energia calculado por hora, dia, mês e ano para cada medidor. Muitos desses critérios são obrigatórios para sistemas compatíveis caso você esteja inscrito em programas de economia de energia, quando é obrigado a provar que as alterações funcionaram (por exemplo, créditos de energia renovável, créditos em carbono e programas de redução de energia).
Alguns usuários solicitaram testes específicos, mas isso dificilmente representa o espectro de usos. Estão sendo feitas tentativas de padronização dos testes, mas eles – assim como a maioria dos demais testes de desempenho – podem ser usados para otimizar os resultados "percebidos", que não representam o uso real. Considere um consumo de Km/litro, por exemplo. As medidas da Agência Americana de Proteção Ambiental estimam o consumo que um motorista comum deve obter sob condições normais de tráfego na cidade e na estrada. No entanto, a maioria dos fatores e dos ambientes favoráveis não é comum, e os fatores que afetam a eficiência em termos de combustível podem variar muito. A mesma orientação se aplica às economias de energia no data center. Os únicos resultados precisos referentes à organização virão da medição da economia de energia em seu próprio ambiente.

Onde estão as economias?
Há muitos fatores a serem considerados quando se determinam as economias. Você conhece o custo do acréscimo de energia em uma determinada área? Você tem uma estratégia para minimizar as restrições em termos de energia? É possível solucionar o problema localizando os data centers em outro lugar em que a energia seja mais barata? Ou você deve se concentrar no aprimoramento das operações nas instalações existentes?
Para algumas empresas, a melhor forma de reduzir os custos pode ser realocando os data centers para áreas com fontes de eletricidade mais baratas. A virtualização dos servidores oferece outra abordagem de redução do consumo de energia. Na verdade, algumas empresas de energia elétrica, (PG&E, SoCal Edison e SDG&E, para mencionar algumas) oferecem incentivos financeiros para os clientes que realizarem projetos de virtualização para reduzir o número de servidores.
Mas há etapas mais simples e menos drásticas a serem tomadas. Atualmente, a maioria dos departamentos de TI não tem nenhuma idéia da energia que seus sistemas consomem, e isso significa que há uma enorme oportunidade para economia em potencial. Uma primeira etapa poderia ser observar o consumo de energia associado a dispositivos individuais e ver se ainda há alguma alteração que poderia ser feita em cada dispositivo. Muitas alterações pequenas podem trazer boas economias.
Para obter uma comparação, pense em uma residência típica em que o proprietário não tem nenhuma idéia da energia usada por cada item de sua casa – apenas paga uma conta mensal com o total. É possível usar um dispositivo barato como, por exemplo, Kill A Watt, que mede o consumo de energia de dispositivos individuais. Quanto você gasta para manter o seu microondas ligado quando ele não está sendo usado? Quanta energia é gasta quando você deixa o carregador do seu telefone ligado? Usando essa mesma abordagem, é possível adicionar medidores de energia aos racks e coletar dados de vários dispositivos. As ferramentas de gerenciamento podem ser usadas para coletar dados diretamente de alguns servidores com interceptações SNMP de consumo de energia.

Introdução
A Figura 5 apresenta um resumo das práticas recomendadas para pôr o plano em execução. Nesse estágio, o que deve ser compreendido é que você não está limitado a escolhas de dois extremos. É possível optar por uma abordagem mais equilibrada, o que é provavelmente mais realista. Comece um esforço de base, identificando as pessoas dentro da empresa que gostam de economizar energia. Comece medindo alguns dispositivos dentro de uma unidade de negócios para dar visibilidade. Aproveitar um momento favorável e mostrar resultados quantificáveis ajudará você a ter o apoio necessário à expansão do investimento da empresa em busca da economia.
Figure 5 Chaves para pôr um plano de economia de energia em vigor (Close Figure 5)

Colete os dados manualmente para determinar o estado dos sistemas atuais. Determine a energia consumida por dispositivos e aplicativos e divida os custos.
Crie um sistema de comentários fechado para medir a eficiência das alterações feitas.
Não se esqueça de monitorar o consumo de eletricidade nos locais certos e no nível apropriado (por dispositivo, organização de TI, unidade de negócios, aplicativo etc).
Crie um fundo para projetos de economia de energia para angariar capital.
Saiba quem dentro da sua organização pode ajudar a conseguir eficiência energética e os mantenha envolvidos.
Quem são as pessoas que alcançarão eficiência energética em sua empresa? Eles são os executivos de alto nível, administração média ou pessoas que apenas se preocupam com o impacto da empresa no meio ambiente? Há pessoas motivadas em todas as empresas. Uma das primeiras decisões é se você deve envolver as pessoas da base desde o início.
Na verdade, independentemente da direção escolhida, planejar um programa de eficiência energética para o data center exigirá a colaboração entre os grupos de TI. Até recentemente, a abordagem típica para planejar soluções em TI era ignorar os custos de energia já durante a fase de projeto, concentrando-se no hardware e no software comprados, além dos custos de mão-de-obra e de hospedagem da solução. Quando a energia desaparece em meio aos custos da execução de soluções em um data center, é sinal de que a eficiência energética é de baixa prioridade. Expor a energia real consumida pelas soluções é a primeira etapa crítica na mudança de comportamento da organização.

Dave Ohara tem 26 anos de experiência em tecnologia, trabalhando para empresas como Microsoft, Apple e Hewlett-Packard. Com trabalhos em desenvolvimento de produtos, marketing, divulgação técnica, arquitetura de infra-estrutura, engenharia de processo, engenharia de confiabilidade e logística de distribuição, Dave está trabalhando agora com várias empresas na implementação de iniciativas verdes.
© 2007 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..


 Administra&#231;&#227;o do Windows: Um guia para a replica&#231;&#227;o do Active Directory
Administração do Windows Laura E. Hunter

Um guia para a replicação do Active Directory
Visão geral:
  • Transição para o Active Directory
  • Manutenção da consistência
  • Resolução de conflitos
  • Alterações no Windows Server 2008

Antes da introdução do Windows 2000 Server e do Active Directory, muitos ambientes corporativos contavam com o Windows NT para sua infra-estrutura de servidores e gerenciamento de identidades e acessos
. Quando o Windows NT® 4.0 foi lançado, ele era uma opção consistente no espaço NOS (sistema operacional de rede), mas tinha algumas desvantagens que dificultavam a implantação em uma grande empresa.
Para os iniciantes, o Windows NT usava um namespace simples para armazenar os recursos, o que significava que não havia uma boa forma de separar os recursos em subconjuntos menores ou de configurar um tipo de administração granular. Você não podia, por exemplo, configurar um contêiner por departamento para os recursos do departamento de marketing ou configurar um administrador local que tivesse direitos para redefinir senhas dos usuários apenas dentro desse departamento. Dessa forma, a segurança do Windows NT era muito na base do tudo ou nada; se quisesse delegar tarefas administrativas a um engenheiro de suporte desktop, você normalmente era forçado a conceder muito mais permissões do que normalmente faria.
Além disso, o Windows NT armazenava todas as informações em um banco de dados SAM (Gerente de Contas de Segurança) que não podia crescer além dos 40 MB. Caso o banco de dados SAM crescesse além desse máximo recomendado (isso acontecia próximo dos 25 mil a 40 mil objetos, dependendo da configuração), você precisava dividir o ambiente em vários domínios separados, o que complicava a administração da rede e o fornecimento de acesso aos recursos para os usuários. Cada domínio do NT apresentava um PDC (controlador de domínio primário), que contava com a única cópia de leitura/gravação do banco de dados SAM; embora você pudesse implantar um ou mais BDCs (controladores de domínio de backup) para tolerância a falhas, esses BDCs eram somente leitura e não podiam realizar nenhuma atualização como, por exemplo, alterar a senha de um usuário, que exigia uma operação de gravação.
Por fim, o Windows NT contava com a resolução de nomes NetBIOS, que era baseada em difusão e costumava gerar muito tráfego à medida que os usuários procuravam recursos de rede, especialmente se eles precisassem fazer isso em um link WAN lento ou muito usado.

Surge um novo modelo
No ano 2000, a Microsoft lançou o Windows® 2000, que incluía uma revisão substancial das opções do NOS anterior. O novo serviço NOS, o Active Directory®, era mais diferente do Windows NT do que você podia imaginar. Em vez de contar com um namespace simples, o Active Directory foi criado de acordo com o padrão X.500, que criava uma estrutura organizacional hierárquica; você podia organizar os recursos em várias unidades organizacionais dentro de um único domínio e delegar a administração de cada OU em um nível baseado em tarefa.
Outra mudança significativa em relação ao Windows NT foi o novo modelo de replicação de vários mestres. O PDC único gravável e seus BDCs associados eram coisa do passado; no Active Directory, cada controlador de domínio tinha a possibilidade de gravar no banco de dados do Active Directory.
No entanto, embora desse muita flexibilidade em termos de suporte a um ambiente grande e descentralizado, isso também criava novos desafios para a manutenção da integridade do Active Directory. Caso John Smith e Jane Dow façam uma alteração no mesmo objeto em escritórios em pontos distantes do país, o que acontece se essas alterações entrarem em conflito? O modelo de replicação do Active Directory define as formas pelas quais as atualizações são comunicadas a todos os controladores de domínio em um ambiente, bem como lidar com os conflitos que podem surgir como resultado dessa capacidade de vários mestres de fazer alterações praticamente a partir de qualquer lugar.

A mecânica da replicação do Active Directory
Tendo em vista esses exemplos, nós abordaremos apenas a replicação intra-site. Basicamente, a replicação intra-site foi projetada para replicar rapidamente as alterações para DCs dentro do mesmo local e é realizada usando a notificação de alterações. No caso da replicação intra-site, o DC1 notificará o DC2 de que ele tem alterações a serem replicadas, após as quais o DC2 obterá essas alterações do DC1. Da mesma forma, o DC2 notificará o DC1 quando tiver alguma alteração; depois disso, o DC1 obterá essas alterações do DC2. Como é possível ver, toda a replicação do Active Directory acontece em operações de recepção, e não de envio.
Como o Active Directory pode ser dimensionado para centenas de milhares ou até mesmo milhões de objetos, ele é necessário para criar o banco de dados Active Directory em seções, chamadas de contextos de nomenclatura. No mínimo, cada controlador de domínio armazena três NCs em sua cópia local do banco de dados Active Directory.
NC Schema O NC é replicado para todos os demais controladores de domínio da floresta. Ele contém informações sobre o esquema do Active Directory, que, por sua vez, define as classes e os atributos diferentes do objeto dentro do Active Directory.
NC Configuration Também replicado para todos os demais DCs da floresta, o NC contém informações sobre a configuração de toda a floresta pertencente ao layout físico do Active Directory, bem como informações sobre especificadores de exibição e cotas do Active Directory de toda a floresta.
NC de domínio O NC é replicado para todos os demais DCs dentro de um único domínio do Active Directory. Esse é o NC que contém os dados do Active Directory mais acessados: os usuários reais, os grupos, os computadores e os demais objetos que residem dentro de um determinado domínio do Active Directory.
Para otimizar ainda mais o tráfego de replicação, todos os contextos de nomenclatura são replicados separadamente para que um NC que não é alterado com muita freqüência — como o NC Schema —consuma a largura de banda da rede necessária ao NC de domínio, que deve ser alterado com muito mais freqüência.
Como as alterações no diretório podem ser feitas de qualquer DC do Active Directory, há dois tipos de operações de gravação que a replicação do Active Directory precisa controlar. Um tipo é a gravação de origem, quando uma determinada alteração foi realizada diretamente em um determinado DC. Por exemplo, caso você se conecte ao DC1 e altere a senha de um usuário, essa alteração é considerada uma gravação de origem no DC1. O Active Directory também deve controlar as gravações replicadas – como você pode imaginar, isso significa que uma determinada alteração foi replicada de outro controlador de domínio. A alteração considerada uma gravação de origem feita no DC1 será considerada uma gravação replicada quando essa alteração for replicada para DC2, DC3 e todos os demais DCs do domínio.
Os controladores de domínio do Active Directory gerenciam a transmissão de alterações feitas no diretório durante todo o uso dos metadados de replicação. Isso significa que, além de comunicar os dados reais alterados de um DC para outro (a descrição de John Smith foi alterada para "Diretor de RH"), o Active Directory também transmite as informações adicionais sobre essa alteração para permitir que os controladores de domínio gerenciem a replicação da maneira mais eficiente como, por exemplo, o DC de origem da alteração, a hora em que ela foi feita e os demais tipos de informações.
O primeiro item dos metadados de replicação que abordaremos é o USN (número de atualização de seqüência). Todos os controladores de domínio mantêm um USN específico. Sempre que é feita uma alteração no Active Directory nesse DC, o USN é incrementado em 1. Dessa forma, caso um DC tenha um USN igual a 1000 às 11h00 e um 1005 às 11h30, você sabe que foram feitas cinco alterações no banco de dados do Active Directory desse DC. No que se refere ao USN, não importa o que fossem essas alterações — você poderia ter modificado cinco objetos diferentes, criado cinco objetos, excluído cinco objetos ou uma combinação disso — e o USN do DC ainda assim será aumentado em cinco. Além disso, os USNs são internos apenas em um determinado controlador de domínio e não têm nenhuma relevância quando comparados aos demais DCs. Um DC em um domínio pode fazer uma alteração às 11h30, o que atribui um USN 1051, e um segundo DC no mesmo domínio pode fazer uma alteração exatamente no mesmo momento em que atribui um USN igual a 5084. Embora esses dois DCs tenham USNs totalmente diferentes para uma alteração feita mais ou menos na mesma hora, esse fato é irrelevante para a forma com que essas alterações são replicadas; o número de atualização de seqüência de um DC não tem nenhum significado para todos os demais DCs em termos comparativos entre as alterações.
Mas essa não é a única forma com a qual o USN de um DC pode ser incrementado. Não se esqueça de que uma alteração feita no banco de dados Active Directory pode consistir em uma gravação de origem ou uma gravação replicada. O número de atualização de seqüência de um controlador de domínio é incrementado por ambos os tipos de operações de gravação, o que significa que ele é incrementado sempre que as alterações são replicadas de outro DC. Agora, claramente cada DC precisa de uma forma para controlar as alterações que já foram replicadas; do contrário, ele permaneceria enviando todo o banco de dados do Active Directory pela rede a cada replicação. Para impedir isso, todos os controladores de domínio do Active Directory mantêm um valor chamado HWMV (high watermark vector) para todos os demais controladores de domínio que o usam na replicação. Cada DC associará esse HWMV ao GUID (identificador global exclusivo) do DC remoto, para evitar qualquer confusão caso o controlador de domínio remoto seja renomeado ou removido do diretório.
Comecemos com um exemplo simples, no qual você tem dois controladores de domínio configurados no domínio contoso.com, dc1.contoso.com e dc2.contoso.com. Como há apenas dois DCs no domínio contoso.com, DC1 e DC2 só são replicados entre si. (Observe que se trata de um exemplo simplificado que ainda não aborda toda a história da replicação do Active Directory; à medida que formos detalhando, acrescentaremos mais informações.)
Também vamos dizer que o USN atual do DC1 seja 3000, o USN do DC2, 4500, e que esses dois DCs estejam totalmente atualizados um em relação ao outro quando começarmos o nosso exemplo:
Etapa 1: DC1 e DC2 estão atualizados um relação ao outro. DC1 tem um HWMV igual a 4500 para DC2, e DC2 tem um HWMV igual a 3000 para DC1, como mostra a Figura 1.
Figura 1 Estado atual dos dois DCs
Figura 1 Estado atual dos dois DCs
Etapa 2: um administrador cria um novo objeto no DC1, e o USN do DC1 é incrementado para 3001, como mostra a Figura 2. Observe que o HWMV de DC1 não foi alterado no DC2, porque o DC1 ainda não notificou o DC2 de que há alterações em espera.
Figura 2 Um novo objeto é adicionado
Figura 2 Um novo objeto é adicionado
Etapa 3: DC1 notifica DC2 de que há alterações disponíveis. Em seguida, DC2 inicia a replicação com DC1 para solicitar todas as atualizações disponíveis. Como parte dessa solicitação, DC2 envia para DC1 o HWMV armazenado para DC1, como mostra a Figura 3.
Figura 3 Notificação das alterações
Figura 3 Notificação das alterações
Etapa 4: DC1 envia para DC2 a alteração correspondente a USN 3001, ou seja, o objeto criado no DC1 durante a Etapa 2. DC2 atualiza o seu próprio USN para 4501 e seu HWMV de DC1 para 3001, como mostra a Figura 4.
Figura 4 Alterações e atualizações
Figura 4 Alterações e atualizações
Até aqui tudo bem, certo? Mas agora há um problema: DC2 tem uma alteração que deve ser replicada. Se a única coisa a continuar fossem os USNs e os HWMVs, neste ponto, o DC2 entraria em contato com o DC1 para replicar a mesma alteração para DC1 que este acabou de replicar para DC2, o que criaria um ciclo infinito de replicação e consumiria cada vez mais largura de banda. Para combater isso, adicionamos mais algumas peças ao quebra-cabeça, e a primeira é o UTDV (vetor UTD, ou vetor de atualização).
O UTDV é outra parte dos metadados de replicação usados para interromper a propagação, ou seja, sua finalidade é impedir que a mesma alteração cause a perda da largura de banda ao ser replicada repetidas vezes em toda a rede. Cada DC mantém uma tabela UTDV para todos os demais DCs que armazena uma réplica do contexto de nomenclatura em questão. Para o NC de domínio, todos os DCs de um domínio mantêm um UTDV para cada DC; já para os NCs Configuration e Schema NC, ele é mantido para todos os DCs da floresta. A tabela UTDV controla não apenas o USN mais alto recebido em cada um dos DCs dos parceiros de replicação, mas também o valor USN mais alto recebido de todos os DCs que estejam replicando em um determinado NC. Para permitir isso, todas as alterações replicadas também incluem as seguintes informações:
  • o GUID do DC que está replicando a alteração. Essa pode ser uma alteração replicada como gravação de origem ou gravação replicada.
  • o USN do DC que está replicando a alteração. Mais uma vez, essa pode ser uma alteração replicada como gravação de origem ou gravação replicada.
  • o GUID do DC que originou a alteração. Caso esse GUID seja o mesmo do DC que está replicando a alteração, trata-se de uma gravação de origem. Do contrário, a tabela UTDV vem à tona.
  • o USN do DC que originou a alteração. Novamente, caso esse USN seja o mesmo do DC que está replicando a alteração, trata-se de uma gravação de origem. Senão, a tabela UTDV é desconsiderada.
Para melhor ilustrar esse processo, aumentaremos a complexidade do nosso exemplo adicionando um terceiro controlador de domínio, DC3. Nesse exemplo, DC1, DC2 e DC3 são todos parceiros de replicação entre si; DC1 replica com DC2 e DC3, DC2 com DC1 e DC3 e DC3 com DC1 e DC2:
Etapa 1: DC1, DC2 e DC3 estão todos atualizados um relação ao outro.
Etapa 2: DC3 realiza uma gravação de origem simples redefinindo a senha da conta do usuário jsmith. DC3 notifica DC1 e DC2 de que há alterações disponíveis. DC1 e DC2 recebem a gravação de origem do DC3 e atualizam as tabelas HWMV e UTDV de DC3 como mostra a Figura 5.
Figura 5 Atualizando as tabelas HWMV e UTDV
Figura 5 Atualizando as tabelas HWMV e UTDV
Etapa 3: aqui é onde o UTDV aparece. DC2 notifica DC1 de que há alterações disponíveis. Em seguida, DC1 entra em contato com DC2 que está solicitando todas as novas alterações enviando para ele as seguintes informações:
  • A HWMV de DC1 para DC2, nesse caso, é de 4501.
  • A tabela UTDV do DC1 (mostrada na Figura 6) que indica o USN de origem mais alto é recebida de todos os DCs, inclusive do DC3.
Figure 6 Tabela UTDV (Close Figure 6)

Todos os DCs que replicam este NC | UTDV
<GUID de DC2> | 4501
<GUID de DC3> | 7002
Com base no HWMV igual a 4501, o DC2 vê que não replicou a alteração em questão para DC1 (consulte a Figura 7).
Figure 7 Uma alteração que precisa ser replicada (Close Figure 7)

Propriedade | Valor | GUID de DC local | USN local | GUID de DC de origem | USN de origem
Propriedade de senha de jsmith | %#FH%2rfg2 | <GUID de DC2> | 4501 | <GUID de DC3> | 7002
No entanto, com base na tabela UTDV transmitida pelo DC1 antes do início da replicação, o DC2 determina que o DC1, na verdade, não exige essa alteração, uma vez que DC1 já recebeu a alteração de DC3. Nesse ponto, o DC1 apenas atualiza a entrada HWMV do DC2 para refletir o USN incrementado, como mostra a Figura 8. No entanto, para manter largura de banda, os dados reais não são enviados pela rede.
Figura 8 Interrupção da propagação
Figura 8 Interrupção da propagação
Etapa 4: essa mesma interrupção da propagação ocorrerá quando o DC2 notificar o DC3 de que há alterações disponíveis e quando o DC1 notificar, da mesma forma, DC2 e DC3. Todos os três DC3s atualizarão suas respectivas entradas HWMV dos parceiros de replicação como mostra a Figura 8, mas os dados reais não passarão pela rede mais uma vez porque já foram transmitidos para todos os DCs na Etapa 2.

Resolução de conflitos em um ambiente com vários mestres
Até aqui, os nossos exemplos são de um mundo perfeito, em que apenas um administrador está fazendo alterações em um DC por vez e ninguém jamais se intromete nas coisas de outra pessoa. No mundo real, nós sabemos que isso raramente acontece. Como as atualizações feitas em um objeto do Active Directory podem vir de qualquer controlador do domínio, o que acontece se dois administradores fizerem atualizações conflitantes em dois controladores de domínio diferentes? Há três tipos de conflitos que podem ocorrer em um ambiente do Active Directory, e cada um deles usa um método diferente na resolução de conflitos.
Alterações conflitantes nas propriedades . Esse conflito ocorre caso dois administradores atualizem o mesmo objeto de maneira conflitante: um administrador define a descrição de um usuário como "Marketing" e outro, em um DC diferente, define a descrição desse usuário como "Vendas e Marketing".
Criando objetos conflitantes . Esse conflito ocorre caso dois administradores criem um objeto com o mesmo nome simultaneamente como, por exemplo, dois usuários com o nome jsmith.
Movendo um objeto para um contêiner excluído . Esse tipo de conflito é muito mais raro e ocorre caso um administrador crie ou mova um objeto dentro de um contêiner como, por exemplo, uma OU, ao mesmo tempo em que outro administrador, em um DC diferente, exclui esse contêiner.
Para corrigir os dois primeiros tipos de conflito, é hora de apresentarmos mais duas partes dos metadados de replicação usados principalmente na resolução de conflitos. O valor versionID é atribuído a cada atributo individual de um objeto, com um valor inicial igual a 1 quando o objeto é criado pela primeira vez. versionID é incrementado em 1 sempre que um atributo individual é modificado em qualquer DC. Dessa forma, se o atributo de descrição de um determinado usuário for atualizado em relação ao valor padrão (em branco ou <não definido>) para "Departamento de Marketing", o atributo terá um versionID igual a 2. Se a descrição for modificada mais tarde para "Departamento de Vendas e Marketing", o atributo de descrição terá um versionID igual a 3 e assim por diante. Esse versionID é incluído em todas as entradas de replicação com as demais partes dos metadados que já apresentamos.
versionID também pode ser usado para reduzir ainda mais o tráfego de replicação. Por exemplo, se um administrador no DC2 tiver feito várias alterações em um único atributo (talvez ele tenha digitado incorretamente a alteração algumas vezes), de forma que o DC2 tenha gravações de origem correspondentes a versionIDs 2, 3, 4 e 5, o DC2 só replicará a gravação que corresponder à mais recente, versionID 5. Como as alterações anteriores seriam substituídas de qualquer forma, isso proporcionaria um atalho para reduzir o uso desnecessário da largura de banda.
Todas as alterações feitas no Active Directory também incluem a segunda parte adicional dos metadados usados na resolução dos conflitos, um carimbo de data e hora, como parte dos metadados de replicação, que indica quando a modificação foi feita.
O atributo do carimbo de data e hora também é usado como uma medida proativa de integridade da replicação do Active Directory. Se um DC não vir nenhuma alteração com um carimbo de data e hora relativamente recente de um determinado DC, ele começará a gerar mensagens de erro indicando que talvez tenha havido um problema com o DC em questão.
E como esses dois atributos são usados na resolução de conflitos? Examinemos cada tipo de conflito por vez.

Resolvendo alterações em propriedades conflitantes
Considere o exemplo do objeto do usuário jsmith no domínio contoso.com. Um administrador no DC1 altera a descrição de jsmith para "Marketing". Praticamente ao mesmo tempo, um administrador em DC3 altera a mesma descrição do usuário para "Vendas e Marketing". Nesse ponto, as informações de DC1 e DC3 sobre o atributo de descrição de jsmith são semelhantes às mostradas na Figura 9.
Figure 9 Alterações praticamente simultâneas (Close Figure 9)

Servidor | Propriedade | Valor | VersionID | Timestamp | GUID de DC local | USN local | GUID de DC de origem | USN de origem
DC1 | Propriedade de descrição de jsmith | "Marketing" | 2 | 2007-06-07 14:03:25 | <GUID de DC1> | 3003 | <GUID de DC1> | 3003
DC3 | Propriedade de descrição de jsmith | "Vendas e Marketing" | 2 | 2007-06-07 14:04:57 | <GUID de DC3> | 7003 | <GUID de DC3> | 7003
Se o DC2 receber ambas as alterações simultaneamente, será claramente necessário determinar qual delas é a alteração "vencedora". A ordem dos desempates para a resolução dos conflitos é a seguinte:
  1. A modificação com versionID maior será aceita como sendo a alteração "vencedora"; a alteração "perdedora" será substituída. Nesse caso, como versionID é 2 em ambos os registros, nós precisamos passar ao segundo desempate.
  2. Se ambos os registros tiverem o mesmo versionID, a alteração com o maior carimbo de data e hora será aceita como sendo a alteração vencedora; a alteração perdedora será substituída. Nesse caso, como o carimbo de data e hora da gravação de origem do DC3 é posterior, a descrição de jsmith será definida como "Vendas e Marketing". Nas raras instâncias em que o versionID e o carimbo de data e hora são idênticos, nós precisamos de um terceiro e definitivo desempate:
  3. Se ambos os registros tiverem versionID e carimbo de data e hora iguais, a gravação originada pelo DC com o GUID de menor número será a vencedora; a gravação do GUID de maior número será substituída. Portanto, se o GUID do DC1 fosse 1234567890 e o GUID do DC3 fosse 2345678901, a gravação de origem do DC1 seria a vencedora caso o versionID e o carimbo de data e hora fossem idênticos.
Você deve estar pensando, "não seria mais lógico se o carimbo de data e hora fosse o primeiro desempate"? Não é tão simples assim como você talvez esteja pensando. Se o carimbo de data e hora fosse o primeiro desempate na resolução de conflitos do Active Directory, a única coisa que um administrador mal-intencionado precisaria fazer para propagar suas alterações seria voltar o relógio de um determinado DC para que ele sempre ganhasse em meio aos carimbos de data e hora.

Resolvendo a criação de objetos conflitantes
Nos casos em que dois objetos forem criados com o mesmo nome, o Active Directory usará os mesmos três desempates descritos na seção anterior para determinar qual deles é o objeto "vencedor". No entanto, diferentemente da seção anterior, o objeto "perdedor" não é substituído. Na verdade, o objeto perdedor é renomeado usando os caracteres CNF (para o objeto conflitante), seguidos de uma vírgula e o GUID do objeto "perdedor". Isso permite que os administradores determinem de maneira mais metódica quais objetos devem ser mantidos e quais devem ser excluídos.

Resolvendo uma transferência de objeto para um contêiner excluído
Conforme mencionei, resolver uma transferência de objeto para um contêiner excluído é um conflito relativamente raro, que só ocorre em dois cenários. Em um, um administrador em um DC cria um objeto dentro de um determinado contêiner, por exemplo, a OU Training, ao mesmo tempo em que um administrador em outro DC exclui a OU. O segundo cenário por ocorrer quando um administrador em um DC move um objeto para um contêiner ao mesmo tempo em que um administrador em outro DC exclui o contêiner.
Nesse caso, a resolução é bem simples: o Active Directory move o objeto "órfão" para um contêiner especial dentro do Active Directory projetado originalmente com essa finalidade, o contêiner LostAndFound que está fora da raiz de cada domínio do Active Directory. Para o domínio contoso.com, o contêiner LostAndFound seria encontrado no seguinte caminho LDAP: LDAP://cn=LostAndFound,dc=contoso,dc=com. Caso você não veja o contêiner LostAndFound ao abrir o snap-in Usuários e Computadores do Active Directory, basta clicar em Exibir | Recursos Avançados.

Protegendo-se da reversão do USN
Uma das situações mais graves que é possível encontrar em um ambiente do Active Directory também é a mais simples de evitar, uma vez compreendida a causa e como contorná-la. A reversão do USN é uma condição de erro que pode desligar completamente a replicação na rede, e é causada pela permissão para que um controlador de domínio permaneça offline por muito tempo e depois retorne ao serviço ou pela restauração de um controlador de domínio usando um método não suportado.
Uma causa da reversão do USN está relacionada à forma como as exclusões do objeto são processadas no ambiente de vários mestres do Active Directory. Quando um objeto é excluído de um DC, em vez de ser apenas removido imediatamente, ele é marcado para exclusão para que possa ser replicado para os demais DCs, o que os notifica da exclusão. O mais comum é que um objeto marcado para exclusão possua um atributo isDeleted definido como TRUE. Para poder reduzir o tamanho do objeto marcado para exclusão, a maioria dos valores contidos no objeto como, por exemplo, a descrição, as informações pessoais e a associação de grupo de um objeto do usuário, é removida (para obter mais informações sobre esse processo, consulte o artigo de Gil Kirkpatrick "Reanimação de Objetos de Exclusões do Active Directory", disponível online em technetmagazine.com/issues/2007/09).
A reversão do USN pode ocorrer porque esses objetos marcados para exclusão não permanecem ociosos indefinidamente. Por padrão, eles são totalmente limpos do banco de dados do Active Directory depois de 60 ou 180 dias (dependendo da versão do Windows Server® que você estava executando quando criou pela primeira vez o ambiente do Active Directory.) Esse período de 60 ou 180 dias é chamado de tempo de vida da marca para exclusão. Todos os controladores de domínio precisam ser capazes de replicar pelo menos uma vez durante esse período, ou eles se tornam piores do que inúteis; eles criam uma oportunidade para a reversão do USN. Basicamente, a reversão do USN ocorre quando um controlador de domínio está tão desatualizado que "perdeu" um ou mais objetos marcados para exclusão e, por isso, é incapaz de manter sua cópia do banco de dados do Active Directory totalmente atualizada em relação aos demais DCs. Para se proteger contra isso, qualquer controlador de domínio que tenha ficado offline por mais tempo do que o ciclo de vida da marca para exclusão não deve retornar ao serviço; na verdade, ele deve ser recriado do zero após a remoção dos metadados antigos do DC do Active Directory usando as etapas descritas no artigo 216498 da Base de Dados de Conhecimento Microsoft (support.microsoft.com/kb/216498).
A segunda causa da reversão do USN ocorre quando um controlador de domínio foi restaurado usando um método não suportado, mais freqüentemente uma ferramenta de clonagem ou de geração de imagens de disco. Quando isso ocorre, o banco de dados restaurado do Active Directory não percebe que ele sumiu "em tempo", porque o método de restauração não reconhecia o Active Directory. A reversão do USN era difícil de detectar no Windows 2000 e na versão inicial do Windows Server 2003, mas o Windows Server 2003 SP1 (e o próximo Windows Server 2008) têm controles integrados para detectar quando um DC foi restaurado incorretamente. Nessas versões mais recentes do sistema operacional, um DC registrará as identificações de evento 1115, 2095, 2103 e 2110 no log de eventos dos Serviços de diretório; o texto desses eventos, bem como as etapas necessárias à recuperação da reversão do USN, podem ser encontrados no artigo 875495 da Base de Dados de Conhecimento Microsoft (support.microsoft.com/kb/875495) referentes ao Windows Server 2003. (É possível encontrar informações sobre como lidar com a reversão do USN no Windows 2000 in no artigo 885875 da Base de Dados de Conhecimento Microsoft, disponível em support.microsoft.com/kb/885875.)

Atualizando o modelo de vários mestres em 2008
Na próxima versão do Windows Server 2008 a Microsoft incluiu uma pequena alteração no modelo de vários mestres com a instrução do RODC (controlador de domínio somente leitura). O RODC foi projetado essencialmente para implantações de filial ou para cenários em que você não tem uma equipe de TI dedicada no local em uma determinada localização e precisa de mais etapas para assegurar a integridade de um DC em particular. Embora pudéssemos passar um artigo inteiro abordando todos os detalhes técnicos do RODC, revisemos os pontos principais com os quais você deve estar familiarizado.
Como o próprio nome indica, a cópia do banco de dados do Active Directory que reside em um RODC é somente leitura. É possível se conectar a um RODC para ler praticamente todas as informações necessárias, mas você não poderá realizar nenhuma operação de gravação em um RODC.
Em segundo lugar, um RODC não realiza nenhuma replicação de saída. Trata-se de uma mudança fundamental em relação ao modelo de replicação de vários mestres que abordamos até agora. Um RODC receberá a replicação de entrada de todos os demais DCs do Windows Server 2008 graváveis, mas não replicará nenhuma informação para os demais DCs. Isso cria uma camada adicional de segurança de forma que, mesmo se um usuário mal-intencionado pudesse modificar de alguma forma o Active Directory em relação ao RODC, essas modificações não seriam propagadas para o restante do ambiente.
E talvez o mais interessante de tudo, o RODC não replica as senhas de usuário por padrão. Quando o banco de dados do Active Directory é replicado para um RODC de um DC gravável, todos os objetos do usuário são replicados sem as informações sobre a senha. Isso ainda proporciona outra camada de segurança em um ambiente de filial, de forma que se um DC "criasse pernas e saísse andando", não haveria nenhuma informação sobre a senha residindo no disco rígido do DC. Vistas como um todo, essas alterações na idéia original da replicação do Active Directory de vários mestres criam um modelo muito mais aprimorado para proteger os controladores de domínio em filiais ou outros locais remotos.

Laura E. Hunter ganhou quatro vezes o prêmio Microsoft MVP na área de sistema de rede do Windows Server. Ela tem dez anos de experiência no setor de TI e é a autora e co-autora de vários livros, artigos e white papers relacionados ao setor, inclusive o Active Directory Cookbook (Manual do Active Directory, Segunda Edição; O'Reilly, 2006).


 System Center: Novas ferramentas para o gerenciamento de atualiza&#231;&#245;es de software
System Center Steve Rachui

Novas ferramentas para o gerenciamento de atualizações de software
Visão geral:
  • O método antigo de gerenciamento de atualizações
  • O novo processo no SCCM 2007
  • Configuração personalizada e flexibilidade
  • Agendamento de atualizações com ajuste preciso

O gerenciamento de atualizações de software foi introduzido inicialmente no SMS (Systems Management Server) 2.0, com as ferramentas de verificação de segurança e de atualizações do Office. Essas ferramentas já passaram por várias revisões: a ferramenta
estendida de inventário de atualizações de segurança foi revisada para dar suporte à verificação de produtos adicionais; a Inventory Tool for Microsoft® Updates, para combinar as ferramentas de segurança e do Office em um único produto; e a Inventory Tool for Dell Updates. A Custom Updates Publish Tool também foi introduzida para dar suporte à aplicação de patches em produtos de terceiros. A ITMU (Inventory Tool for Microsoft Updates) já passou por três revisões. Cada uma dessas ferramentas conta com catálogos próprios, com uma infra-estrutura de verificação e com requisitos e desafios específicos. Com o tempo, os catálogos desses sistemas se tornaram muito grandes. Na verdade, tão grandes que as atualizações mais antigas foram removidas e substituídas pelas mais novas, devido a restrições de tamanho.
Com a variedade de opções existentes, implantar atualizações com essas ferramentas poderia representar um desafio. Existia a clara necessidade de simplificar o processo. A próxima versão do SMS — o SCCM (System Center Configuration Manager) 2007 — faz grandes progressos nesse sentido. No SCCM, o mecanismo de atualizações de software foi criado de forma a garantir melhores resultados finais. Com uma abordagem totalmente diferente para as operações de gerenciamento de atualizações, os catálogos e mecanismos de verificação antigos agora são coisa do passado. O status de atualização, que historicamente tem sido reportado via inventário de hardware, usa um novo mecanismo — a mensagem de estado — para garantir melhor determinação da conformidade, e também imposição das atualizações em cada cliente. Acredito que você perceberá que a nova abordagem para o gerenciamento de atualizações no SCCM 2007 representa um aperfeiçoamento significativo.
O SCCM 2007 traz dois novos componentes que abordarei antes de nos aprofundarmos na funcionalidade de gerenciamento de atualizações.
SUP (ponto de atualização de software) Como já mencionei, não existem mais catálogos no SCCM. Em vez disso, o SCCM funciona diretamente com um servidor WSUS (Windows Server® Update Services) dedicado, que atua como um SUP (ponto de atualização de software), fornecendo downloads de metadados e verificação de clientes. No SCCM, os recursos de entrega de binários de atualização do WSUS são desabilitados para permitir o foco no processo de verificação. Com esse ajuste, o WSUS é dimensionado para realizar a verificação de até 25 mil clientes por SUP em um servidor dedicado. O SCCM permite também configurar o SUP nos bastidores de um cluster de NLB (balanceamento de carga de rede) para obter maior disponibilidade e escala, habilitando até quatro SUPs para um total de 100 mil possíveis clientes por site primário.
CIs (itens de configuração) O item de configuração é uma nova abordagem usada no SCCM para definir configurações específicas que devem existir nos sistemas de destino. O gerenciamento de atualizações do SCCM agora usa essa infra-estrutura. Não se deve mais pensar nas atualizações em termos de distribuição normal de software — embora ainda existam semelhanças. Em vez disso, as atualizações residem em seu próprio nó no console do administrador e usam um mecanismo exclusivo de CIs. No lado do cliente, as atualizações são baixadas de forma seletiva e armazenadas localmente.

Configurando o gerenciamento de atualizações
A configuração do gerenciamento de atualizações recai sobre três áreas gerais — habilitar o agente cliente, configurar o SUP e configurar as atualizações para distribuição.
O agente cliente do SCCM (conforme mostrado na Figura 1) é semelhante a outros agentes clientes e é configurado no mesmo nó do console administrativo. A página de propriedades do nó Software Updates Client Agents (Agentes Clientes de Atualizações de Software) é onde os administradores habilitam esse agente e definem as configurações de instalação de atualizações e reavaliação de implantação. A configuração para habilitar o Agente Cliente de Atualizações de Software tem efeito sobre todo o site, ou seja, todos os clientes do SCCM atribuídos ao site onde a função estiver ativada terão a função habilitada. Caso alguns sistemas em um ambiente não devam ter essa função habilitada, é possível substituir a configuração para todo o site por uma configuração por sistema, usando as configurações locais de substituição de políticas.
Figura 1 Propriedades do agente cliente
Figura 1 Propriedades do agente cliente
Essas configurações permitem também que o administrador especifique como lidar com os prazos de atualização. Suponha, por exemplo, que você tem quatro atualizações com instalação pendente. Uma delas (atualização A) tem um dia a mais de prazo em relação às outras três. Mas suponha que seja preferível instalar as quatro atualizações ao mesmo tempo — até mesmo aquelas que cujo prazo ainda não venceu. A opção "Enforce all mandatory deployments" (Impor todas as implantações obrigatórias) na guia permite configurar essa opção. Além disso, as configurações permitem que os administradores especifiquem a supressão de todas as notificações e indicações visíveis do processo de atualização. Essas opções são mostradas na Figura 1.
As configurações na guia Deployment Re-evaluation (Reavaliação de Implantação) permitem aos administradores agendar quando as implantações serão reavaliadas. Os clientes do SCCM serão avaliados de acordo com esse agendamento para verificar se as atualizações instaladas anteriormente ainda são necessárias e, se estiverem ausentes, reinstalá-las.

Configurando o SUP
Como já foi mencionado, o SUP é o componente responsável pelo download de todas as informações disponíveis sobre atualizações em uma agenda, e pela interação direta com os clientes do SCCM para realizar verificações de conformidade com base em seu banco de dados de atualizações. Antes que um SUP possa ser configurado, é preciso que um servidor WSUS 3.0 ou superior esteja instalado, pois o processo do SUP na verdade não instala o WSUS — ele apenas configura o WSUS para uso com o SCCM. Além disso, o Console do Administrador do WSUS precisa ser instalado no servidor do site para habilitar a conectividade com o servidor WSUS. Quando o SCCM assume o controle do servidor WSUS para a função de SUP, o servidor WSUS passa a ser dedicado ao SCCM e só pode ser usado pelos clientes do SCCM.
O SUP é uma nova função de sistema de site presente no SCCM. Para iniciar a configuração, navegue até o nó dos sistemas de site no console do administrador e adicione um novo sistema de site. A próxima etapa consiste em selecionar Software Update Point (Ponto de Atualização de Software) e prosseguir no assistente, que coletará as seguintes informações:
  • Configuração de proxy
  • Informações sobre porta e SSL
  • Como o SUP deve sincronizar as atualizações — a partir do Microsoft Update, por meio de um SUP upstream ou manualmente
  • Agenda de sincronização
  • Classificações relevantes das atualizações, como atualizações críticas, drivers, atualizações de segurança, pacotes cumulativos de atualizações e assim por diante
  • Produtos com atualizações disponíveis — Windows®, Exchange, SQL Server™ e assim por diante (mostrados na Figura 2)
  • Idioma
Figura 2 Configurações de produtos no assistente de função do site
Figura 2 Configurações de produtos no assistente de função do site
Quando o assistente for concluído, o SUP será instalado e as configurações internas serão ajustadas para dar suporte aos requisitos do SCCM. Convém confirmar se a instalação foi bem-sucedida, examinando o SUPSetup.log localizado na pasta de logs onde o SCCM foi instalado.
Quando o SUP estiver instalado, será preciso realizar a sincronização para fazer com que o SUP recupere atualizações e armazene-as no banco de dados do SUP e do SCCM. A sincronização pode ser executada manualmente ou segundo uma agenda configurada ao executar o assistente de instalação do SUP. A sincronização manual de atualizações pode ser inicializada a qualquer momento e convém garantir que aconteça após a primeira instalação do SUP. A Figura 3 mostra como fazer isso.
Figura 3 Execução manual da sincronização
Figura 3 Execução manual da sincronização
O processo de sincronização tem duas etapas. Primeiro, o servidor SUP (WSUS) é configurado para corresponder às configurações do SCCM e as atualizações configuradas são sincronizadas com o servidor SUP (WSUS) propriamente dito. Quando a primeira etapa é concluída, as informações sobre atualizações no SUP (WSUS) são sincronizadas com o banco de dados do SCCM e disponibilizadas para a implantação de atualizações. Essa segunda etapa cria os CIs necessários (um para cada atualização de software) no banco de dados do SCCM e pode ser demorada. A sincronização inicial pode levar várias horas. É possível analisar o processo de sincronização no log WSyncMgr. Uma parte dele é mostrada nas Figuras 4 e 5. A Figura 4, especificamente, mostra o processo de sincronização solicitando que o servidor SUP (WSUS) atualize sua lista de atualizações a partir do Microsoft Update. A Figura 5 mostra o início do processo para sincronizar o inventário do SUP com o banco de dados do SCCM.
Figura 4 Sincronização da lista de atualizações
Figura 4 Sincronização da lista de atualizações
Figura 5 Sincronização das atualizações como CIs no banco de dados do SCCM
Figura 5 Sincronização das atualizações como CIs no banco de dados do SCCM
Quando um servidor WSUS é configurado como um SUP, qualquer tarefa de administração necessária pode ser realizada via console do administrador do SCCM. Se forem feitas alterações de configuração diretamente no servidor WSUS, o SCCM poderá ser prejudicado. Além disso, essas configurações serão redefinidas de hora em hora, quando o SCCM verificar o SUP para garantir que as configurações estão corretas.
Em uma hierarquia com várias camadas, é preciso ter pelo menos um SUP em cada site primário onde as atualizações de software serão implantadas. Esses SUPs trabalharão juntos em uma hierarquia e apenas um SUP, geralmente o de posição mais alta na hierarquia, fará a sincronização com o Microsoft Updates. Os demais SUPs farão a sincronização com um parceiro de replicação de SUP upstream configurado.

Configurando a implantação de atualizações
Quando o agente cliente estiver configurado e o SUP, configurado e sincronizado, você estará pronto para preparar uma implantação real. Primeiro, vamos analisar os vários nós da interface do usuário do administrador do SCCM. Basicamente, há cinco nós principais relevantes — Update Repository (Repositório de Atualizações), Update Lists (Listas de Atualizações), Deployment Templates (Modelos de Implantação), Deployment Management (Gerenciamento de Implantação) e Deployment Packages (Pacotes de Implantação).
O Update Repository é onde todas as atualizações sincronizadas são armazenadas e ficam disponíveis para implantação. É possível implantar atualizações selecionando uma ou mais e iniciando o assistente Deploy Software Updates (Implantar Atualizações de Software), que realiza duas tarefas: configurar o modelo de implantação (ou selecionar um já existente) e configurar a implantação propriamente dita. Abordarei esse processo um pouco mais adiante. A lista de atualizações pode ficar bem grande. Por isso, as pastas de pesquisa, um novo recurso do SCCM 2007, podem ajudar muito na localização de atualizações relevantes com base em 28 critérios relacionados a atualizações, inclusive gravidade, classificação, produto, data de lançamento e precedência.
As listas de atualizações permitem que os administradores criem um conjunto fixo de atualizações a serem gerenciadas. Podem ser usadas para relatórios de conformidade, criação de implantações e delegação de administração. Uma vez criadas, essas listas são replicadas por toda a hierarquia para reutilização nos sites filhos — da mesma forma que pacotes e anúncios. As listas de atualizações não se vinculam a nenhuma implantação específica quando replicadas; são apenas listas de atualizações. Quando a lista é concluída e replicada, as atualizações nela contidas podem ser implantadas como uma unidade. Para isso, basta selecionar a lista e optar por implantar as atualizações.

Modelos de implantação
Os modelos de implantação contêm configurações comuns (como informações de agenda e coleção de destino) usadas durante a implantação das atualizações de software. Esses modelos foram desenvolvidos para diminuir o tempo necessário para administrar a implantação das atualizações. É possível criar modelos para lidar com diversas condições de implantação em um ambiente. Eles podem ser usados no assistente de implantação, com a simples seleção do modelo adequado. As configurações preenchidas previamente pelo modelo de implantação incluem a coleção de destino, configurações de prazo de atualização (conforme mostrado na Figura 6), configurações de reinicialização e janelas de manutenção. Quando há um grande número de atualizações em uma implantação, o desempenho do sistema de destino pode ser afetado pela simultaneidade dos prazos de atualização. Observe também que as configurações no modelo são aplicadas à implantação quando ela é criada. Essas configurações permanecem em vigor na implantação, a menos que sejam modificadas manualmente na própria implementação. É importante lembrar-se de que a simples modificação posterior das configurações do modelo não fará com que essas configurações modificadas sejam alteradas nas implantações existentes que utilizam o modelo modificado.
Figura 6 Definição de agendas de implantação no assistente
Figura 6 Definição de agendas de implantação no assistente
As opções na Figura 6 podem ser configuradas ao executar o assistente de modelo de implantação ou o assistente para implantar atualizações de software (se um novo modelo for criado). Observe que a configuração de duração na tela está definida como 0. O valor padrão dessa configuração é de duas semanas. Se essa configuração for definida com um valor diferente de 0, haverá, antes da implantação das atualizações, um atraso no cliente correspondente à extensão desse valor. No período entre a disponibilização da implantação e a imposição do prazo configurado, a atualização ficará disponível para instalação manual pelos usuários finais, como uma instalação agendada que pode ser realizada antes do prazo. No prazo estabelecido, a atualização será imposta e instalada. Se você se deparar com atrasos na implantação de atualizações, verifique se essa configuração está definida corretamente de acordo com as suas necessidades.

Gerenciamento de implantação
Depois que uma implantação de atualizações de software é configurada, ela pode ser acessada no nó Deployment Management. Observe que uma implantação de software configurada não é igual a um pacote de implantação. As configurações relacionadas à implantação, assim como as atualizações incluídas nela, podem ser exibidas e manipuladas nesse nó, mas não o pacote propriamente dito. Essas configurações de implantação refletem as configurações advindas do assistente de atualizações de software, e também aquelas herdadas do modelo escolhido.

Pacotes de implantação
Os pacotes de implantação se assemelham a pacotes SMS padrão, pois definem as especificidades da atualização — diretório de origem, ponto de distribuição e assim por diante. Os pacotes de implantação são independentes da implantação propriamente dita usada para distribuir as atualizações; são, essencialmente, um local de armazenamento para as atualizações. Se mais de um pacote de implantação contiver as atualizações necessárias a uma implantação, os agentes do SCCM determinarão o melhor local onde recuperar a atualização, podendo usar qualquer pacote de implantação disponível que a contenha.
O assistente Deploy Software Updates é usado para implantar atualizações no SCCM. Esse assistente pode ser usado com atualizações individuais ou com listas de atualizações. A Figura 7 mostra como iniciá-lo.
Figura 7 Como iniciar o assistente Deploy Software Updates
Figura 7 Como iniciar o assistente Deploy Software Updates
O assistente prossegue solicitando um nome para a implantação, perguntando se você deseja utilizar as configurações do modelo existente ou de um novo modelo (se for escolhido um novo modelo, o assistente solicitará as configurações de modelo descritas anteriormente), solicitando as configurações do pacote de implantação (existentes ou novas), as configurações do ponto de distribuição, as opções de localização para download, os idiomas de atualização a serem baixados e informações sobre a agenda de implantação.
Quando a configuração for concluída, a política será atualizada para notificar os clientes sobre as atualizações programadas, e as atualizações serão instaladas nos sistemas clientes. Os processos nos clientes são bastante diferentes das versões anteriores e estão além do escopo definido para este artigo. No entanto, uma diferença fundamental é que as verificações de atualizações não são mais realizadas localmente, pois o SUP realiza todas elas. Contudo, os detalhes de conformidade das atualizações são armazenados no repositório local do WMI (Windows Management Instrumentation), de forma semelhante às versões anteriores.
Ao contrário das versões anteriores, o inventário de hardware não é mais usado para enviar o status de atualização para o servidor do site. Em vez disso, as mensagens de estado (um tipo novo e simplificado de mensagem de status) são enviadas para o servidor do site via ponto de gerenciamento. Essas mensagens fornecem dados sobre cada cliente gerenciado, para verificações de conformidade e para controlar o progresso das implantações. Há vários novos relatórios no SCCM para o gerenciamento de atualizações de software, inclusive conformidade geral por máquina para todas as atualizações implantadas em cada cliente; estado de imposição da implantação por cliente; e relatórios de erro dos clientes para verificações e implantações, fornecendo uma lista classificada por pilhas com os principais problemas a serem resolvidos.
Além da tradicional imposição agendada/obrigatória das implantações de atualizações, o SCCM permite instalar atualizações aprovadas antes do prazo, em uma agenda muito semelhante à existente no Automatic Updates. Esse acréscimo bastante útil contribuirá para aumentar o número de sistemas em conformidade antes do prazo de implantação.
Se você tem interesse em atualizações personalizadas, o SCCM também as permite. A ferramenta de publicação de atualizações personalizadas do SMS 2003 R2 foi modificada para uso com o SCCM 2007 como System Center Updates Publisher. Assim, qualquer atualização personalizada pode ser implantada da mesma forma já descrita.
Há várias alterações no gerenciamento de atualizações no SCCM. Mas, sob o ponto de vista do administrador, os novos recursos devem ser mais fáceis de usar e representam um aperfeiçoamento bem-vindo em relação às versões anteriores. Embora algumas alterações conceituais possam ser desafiadoras a princípio para os usuários acostumados com o SMS 2003, definitivamente vale a pena investir na nova abordagem. Aproveite!

Steve Rachuié engenheiro de escalonamento de suporte de gerenciamento no grupo de serviços de suporte a produtos da Microsoft. Ele trabalha no SMS desde a versão 1.2. Entre em contato com Steve pelo email steverac@microsoft.com.


 Comunica&#231;&#245;es: Servidores de Transporte de Borda do Exchange na Microsoft
Comunicações Kay Unkroth

Servidores de Transporte de Borda do Exchange na Microsoft
Visão geral:
  • A função de servidor Transporte de Borda do Exchange
  • Configuração de laboratório de teste
  • Agentes e eventos de transporte
  • Internos do agente
Faça download do código deste artigo: ExchangeEdge2007_10.exe (354KB)

Em um dia útil, a Microsoft recebe aproximadamente 13 milhões de tentativas de envio de mensagens provenientes da Internet e bloqueia mais de 10,5 milhões delas por não serem legítimas. Em situações críticas
como, por exemplo, durante ataques de spam ou invasões de vírus na Internet, o volume pode ultrapassar os 90 milhões. É claro que essa constatação é específica da Microsoft, ainda que scamming, spam, phishing, vírus em emails, coletas de diretório, ataques DDoS (ataque de negação de serviço distribuído) e preocupações semelhantes não sejam exclusivas da Microsoft. Diante desses problemas, como você faz para garantir a entrega de todas as mensagens legítimas aos usuários e ao mesmo tempo afastar do ambiente de mensagens o fluxo de conteúdo mal-intencionado e ilegítimo?
Uma forma de obter uma proteção confiável para as mensagens é implantar os servidores de Transporte de Borda do Exchange Server 2007 e o Forefront Security for Exchange Server em uma rede de perímetro entre a Internet e o ambiente de produção. Isso coloca uma equipe organizada com mais de 10 agentes de Transporte de Borda no perímetro para ajudar a proteger os sistemas de produção e os usuários. É óbvia a importância de bloquear o conteúdo indesejado com a maior antecedência possível. O ideal é que isso ocorra antes mesmo que o conteúdo seja entregue aos servidores, considerando a carga que o ambiente de mensagens deveria ser capaz de sustentar em uma situação crítica. Além disso, há muito mais na proteção das mensagens do que simplesmente bloqueá-las.
Esta é a primeira parte das duas que abordam a arquitetura e os principais recursos dos agentes de anti-spam e de antivírus disponíveis no Exchange Server 2007 e no Forefront Security for Exchange Server. Para manter as explicações realistas e práticas, neste primeiro artigo, mostrarei a você como criar um laboratório de teste que espelhe o projeto de proteção das mensagens usado pela Microsoft em seu próprio ambiente de produção corporativo. Em seguida, abordarei a arquitetura do Transporte de Borda do Exchange Server 2007 mais detalhadamente.
Durante todo o artigo, usarei muitos scripts e arquivos em lotes para automatizar as tarefas de configuração mais importantes. Esses arquivos incluem comentários que explicam as etapas realizadas individualmente. É possível baixar os scripts com o download disponível no site da TechNet Magazine em technetmagazine.com/code07.aspx.

Topologia do Transporte de Borda
A Figura 1 ilustra o projeto do Transporte de Borda implementado pela TI da Microsoft no ambiente de produção corporativo. Há alguns recursos muito interessantes no projeto que eu gostaria de ressaltar antes de apresentar a você a arquitetura do Transporte de Borda. Caso você esteja interessado nos detalhes completos da implementação, consulte o white paper do IT Showcase mencionado na barra lateral "Recursos do Exchange".
Figura 1 Topologia do Transporte de Borda na Microsoft
Figura 1 Topologia do Transporte de Borda na Microsoft
Ao analisar a Figura 1, observe que a topologia do Transporte de Borda na Microsoft é totalmente redundante. Não há nenhum ponto de falha em um local sequer. Para o balanceamento de carga, a TI da Microsoft usa rodízio externo de DNS e conectores de mensagens com várias pontes internas. Também vale a pena observar o fato de que todos os servidores de transporte (Transporte de Hub e Transporte de Borda) executam o Forefront Security for Exchange Server para a verificação de vírus. Isso permite que a TI da Microsoft examine todas as mensagens de entrada, de saída e internas assim que chegam a um servidor de transporte na topologia de roteamento das mensagens.
Outro recurso importante do projeto relacionado à segurança é que os servidores do Transporte de Borda não fazem parte do ambiente do Active Directory® corporativo. Na verdade, não é necessário implantar os servidores do Transporte de Borda em nenhuma floresta do Active Directory. No entanto, para manter uma estrutura de gerenciamento consistente, aplicar um conjunto de diretivas em comum e dar suporte a logon único, a TI da Microsoft implanta todos os servidores do Transporte de Borda em uma floresta externa, separada do ambiente de produção.
Por fim, é possível ver claramente que todas as mensagens provenientes da Internet chegam à Microsoft por meio de servidores do Transporte de Borda situados na América do Norte. Os servidores do Transporte de Borda em Dublin e em Cingapura só manipulam mensagens de saída. A vantagem de concentrar todo o tráfego de entrada nos servidores do Transporte de Borda da América do Norte é centralizar o controle de segurança e de anti-spam ao mesmo tempo em que se evita a transferência das mensagens de saída de grandes data centers regionais em todo o backbone das mensagens internas.
O engenheiro de sistemas da TI da Microsoft, Omesh Desai, projetou a topologia do Transporte de Borda da Microsoft. Quando perguntei a Omesh a respeito dos recursos mais importantes do projeto, ele disse: "Em nosso projeto do Transporte de Borda, nós aproveitamos os recursos de anti-spam e de antivírus nativos do Exchange para a proteção das mensagens em vários níveis no backbone das mensagens. A segurança do perímetro das mensagens é a maior prioridade, embora um modelo simples de gerenciamento e administração também seja importante para nós. Os servidores do Transporte de Borda nos ajudam a aumentar a segurança por meio de configurações de firewall mais rígidas, ao mesmo tempo em que aumentam a precisão da filtragem de spam por meio dos serviços de reputação de IP, das atualizações automáticas do filtro de conteúdo, da agregação de lista segura e da validação do carimbo postal de email. Por padrão, toda a comunicação interna entre os servidores é criptografada, e nós também criptografamos a comunicação com os destinos externos, se possível.
"Nós usamos dois processadores dual-core de 64 bits e oito gigabytes de memória em nossos servidores do Transporte de Borda. Com seis desses servidores, com balanceamento de carga em dois data centers, temos capacidade suficiente para suportar grandes picos de mensagens enviadas como, por exemplo, durante invasões de vírus na Internet."

Laboratório de teste do Transporte de Borda
Configuração do laboratório de teste
Por ser uma prática recomendada usar nomes de domínio não existentes e endereços IP particulares, eu uso AdventureWorks.com e intervalos de endereços IP 192.168.xxx.0 a 24. Não há sistemas redundantes ou matriz de firewalls porque não estou testando o balanceamento de carga ou a tolerância a falhas. (E, obviamente, os sistemas de firewall reais usados pela TI da Microsoft não podem ser abordados por motivos de segurança.) De qualquer forma, esses detalhes não são importantes para o ambiente de teste.
O meu ambiente de teste usa o ISA Server 2006 por se tratar de um dos sistemas de firewall mais comumente usados com o Exchange Server 2007. A execução do ISA Server 2006 nos firewalls externos e internos ajuda a manter a complexidade do ambiente de teste em um nível moderado, embora eu recomende, para ambientes de produção, o uso de vários sistemas de firewall externo e interno para aumentar a segurança. Eu não implantei as diretivas de protocolo IPSec (IP Security) ou preparei o ambiente para o protocolo TLS (Transport Layer Security) porque esses tópicos estão fora do escopo deste artigo.
No entanto, usei máquinas virtuais e um software de avaliação de 32 bits, que é possível baixar no site da Microsoft. A Microsoft não dá suporte à versão de 32 bits do Exchange Server 2007 em produção, embora isso não seja problema em um ambiente de teste.
Meu laboratório de teste usa as configurações padrão sempre que possível. Apenas a configuração de IP, os firewalls e as zonas DNS exigem atenção especial antes da execução da configuração do Exchange Server 2007 e da inscrição do servidor do Transporte de Borda no ambiente de produção. Para obter detalhes sobre a configuração de IP, consulte o arquivo Test Lab—IP Configuration.xls que você encontrará no download complementar. Caso use as mesmas atribuições de endereço IP, você pode configurar rapidamente o firewall externo, chamado ISA01, executando o script ISA01_Firewall_Policies.vbs diretamente no computador ISA01, e usar ISA02_Firewall_Policies.vbs para o firewall interno (ISA02). O download complementar também inclui arquivos em lotes para configurar os servidores DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat e AD02_DNS_Config.bat). Como esses arquivos em lotes usam a ferramenta de linha de comando DNS (dnscmd.exe), você precisa ter as Ferramentas de Suporte do Windows instaladas; do contrário, você deve criar manualmente os registros DNS usando o console DNS.
Para evitar qualquer interferência dos ambientes existentes, o meu laboratório de teste não está conectado à Internet. Esse isolamento é uma boa precaução. Isso faz com que haja falha em todos os downloads das atualizações de assinatura, da reputação de IP e das atualizações do filtro de conteúdo, mas isso não é crítico para fins de teste. Para evitar mensagens de erro, vá para Atualizações do Scanner no console do Forefront Server Security Administrator e defina a freqüência de atualizações de todos os mecanismos de verificação para uma vez e especifique uma data anterior.

Para explorar esses recursos em ação, criar um ambiente de teste é uma prática recomendada – o senso comum sugere jamais usar um sistema de produção para fins de teste. Ele usa, no mínimo, um servidor com o Exchange Server 2007 em execução para as funções de servidor Caixa de correio, Acesso de cliente e Transporte de Hub. Você precisará de um segundo servidor do Exchange para a função de servidor Transporte de Borda. Você poderia ignorar a instalação do servidor de Transporte de Borda se implantasse todos os agentes de transporte no servidor de várias funções executando o script Install-AntispamAgents.ps1 (é possível encontrá-lo em servidores do Transporte de Borda na pasta %ProgramFiles%\Microsoft\Exchange Server\Scripts). Mas essa abordagem pouco se assemelharia à implantação da TI da Microsoft. Para obter um laboratório de teste realista, você precisará incluir mais alguns servidores. A Figura 2 mostra o ambiente de teste que usei na pesquisa deste artigo. Há uma ilustração mais detalhada disponível no download complementar. Para obter mais informações sobre como configurar o laboratório, consulte a barra lateral "Configuração do laboratório de teste".
Figura 2 Ambiente de teste do Transporte de Borda
Figura 2 Ambiente de teste do Transporte de Borda
Durante a inscrição do servidor do Transporte de Borda e a configuração dos conectores associados, a TI da Microsoft remove todos os conectores padrão e, em seguida, continua criando quatro conectores de envio para se comunicar de maneira eficiente com tipos diferentes de hosts de protocolo SMTP (Simple Mail Transfer Protocol) e servidores do Transporte de Borda internos. O primeiro conector de envio é um conector da Internet para todos os destinos que não correspondem a definições de espaço de endereçamento específicas.
O segundo conector de envio é um conector da Internet com definições de espaço de endereçamento detalhadas para destinos conhecidos que não dão suporte a SMTP estendido (domínios HELO). Configurando o parâmetro ForceHELO para esse conector como $true, a TI da Microsoft evita uma seqüência desnecessária de EHLO, Resposta de Falha 500, HELO durante o estabelecimento de conexões SMTP.
O terceiro conector de envio é um conector da Internet com definições de espaço de endereçamento detalhadas para parceiros e outros domínios remotos que dão suporte a TLS na comunicação segura por meio de conexões criptografadas (domínios TLS). Esse conector tem o parâmetro RequireTLS definido como $true.
O quarto conector de envio é um conector de entrada para transferir mensagens de Internet recebidas para servidores de Transporte de Hub no ambiente corporativo. Mais uma vez, para obter mais detalhes a respeito da configuração do servidor do Transporte de Borda, consulte o white paper do IT Showcase mencionado na barra lateral "Recursos do Exchange" ao final deste artigo.
Para aplicar uma topologia de conector ao estilo da TI da Microsoft ao laboratório de teste, eu usei um procedimento com base nos scripts criados por Omesh para uso interno da TI da Microsoft. Por motivos de segurança, eu alterei e reduzi drasticamente os comandos individuais, mas a topologia de conector resultante continua correspondendo à topologia da TI da Microsoft. Aqui estão as etapas:
  1. No servidor do Exchange de várias funções (HUB-MBX-01) e no servidor do Transporte de Borda (EDGE01), remova os conectores padrão.
  2. Em HUB-MBX-01, crie um novo conector de recebimento executando o script HUB-MBX-01_recv_connector.ps1 encontrado no download deste artigo.
  3. Em EDGE01, crie dois novos conectores de recebimento para conectividade das mensagens internas e externas executando o script EDGE01_recv_connector.ps1.
  4. Em EDGE01, crie um arquivo de inscrição executando este comando:
    New-EdgeSubscription -FileName
    "c:\subscriptionfile.xml"
Em seguida, copie o arquivo de inscrição resultante para a pasta raiz do servidor de Transporte de Hub (c:\subscriptionfile.xml).
5. Em HUB-MBX-01, verifique se o caminho para o arquivo de inscrição é c:\subscriptionfile.xml e execute o script HUB-MBX-01_complete_subscription.ps1. Esse script importa o arquivo de inscrição para Sincronização de Borda sem a criação automática do conector de envio, cria os conectores de envio para conectividade interna e da Internet e replica a configuração resultante para o servidor do Transporte de Borda por meio da Sincronização de Borda.
6. Verifique a configuração enviando mensagens de teste como Contoso.User@contoso.com e Fabrikam.User@fabrikam.com do host da Internet para Administrator@adventureworks.com e respondendo às mensagens recebidas para garantir o funcionamento da transferência das mensagens de entrada e de saída.
Eu sugiro que você abra os arquivos de script individuais no Bloco de notas e analise os cmdlets e os parâmetros usados pelos scripts para realizar a configuração. Há informações detalhadas sobre esses cmdlets e parâmetros disponíveis on-line na documentação do produto do Exchange Server 2007.

Arquitetura do Transporte de Borda
Agora vejamos os agentes do Transporte de Borda, que têm aguardado alguém dizer HELO ou EHLO desde o momento em que eu instalei a função de servidor Transporte de Borda. Caso execute o cmdlet Get-TransportAgent no servidor do Transporte de Borda, você deve ver as 11 entradas listadas na Figura 3. Por padrão, todos os agentes são habilitados para fornecer proteção às mensagens com as configurações apropriadas.
Figure 3 Agentes de transporte (Close Figure 3)

Agentes de recebimento SMTP
Agente de filtro de conexão
Agente Reconfiguração de Endereço na Entrada
Agente de regras de borda
Agente de filtro de conteúdo
Agente de ID do remetente
Agente de filtro por remetente
Agente de filtro de destinatários
Agente de análise de protocolo
Agente de filtragem de anexos
Agentes de roteamento
Agente Reconfiguração de Endereço na Saída
Agente de roteamento de FSE
O cmdlet Get-TransportAgent e a Figura 3 listam os agentes na ordem de prioridade, embora essa não seja a ordem na qual os agentes realizam o trabalho. A ordem dos trabalhos depende essencialmente da seqüência dos eventos de recebimento SMTP e dos eventos de roteamento nos quais os agentes estão registrados. Para ver como os agentes e os eventos se adaptam, observe o diagrama mostrado na Figura 4, que ilustra a forma como os agentes de transporte se integram à arquitetura do Transporte de Borda.
Figura 4 Agentes de transporte dentro da arquitetura do Transporte de Borda
Figura 4 Agentes de transporte dentro da arquitetura do Transporte de Borda
Os eventos de transporte ocorrem em vários estágios durante o processamento das mensagens para invocar um código adicional para filtragem anti-spam, verificação de vírus e outras tarefas. Nesse projeto flexível e extensível, o processo Transporte de Borda (EdgeTransport.exe) assume a função de origem do evento. Os manipuladores de eventos, em outras palavras, os agentes de transporte, são objetos delegados baseados no Microsoft® .NET Framework 2.0, registrados na origem do evento para receber notificações de retorno de chamada.
A Figura 5 mostra os registros de evento para todos os agentes instalados em um servidor do Transporte de Borda com o Forefront Security. Talvez seja um pouco difícil classificar esses registros por conta do grande número de registros de agente, mas não se desespere. Caso execute o comando Get-TransportPipeline | Format-List em um servidor do Transporte de Borda, você pode analisar os registros de cada evento de transporte individual com mais calma. Apenas verifique se o serviço Transporte do Microsoft Exchange (MSExchangeTransport.exe) está em execução e se você enviou pelo menos uma mensagem pelo servidor do Transporte de Borda desde a última reinicialização do serviço. Como a saída indica, vários agentes podem se registrar no mesmo tipo de evento e agentes individuais podem se registrar em vários eventos. Os registros de evento dependem apenas dos requisitos de processamento do agente correspondente.
Figura 5 Registros de evento para agentes de transporte
Figura 5 Registros de evento para agentes de transporte
Um dos eventos mais importantes é o evento de roteamento OnSubmittedMessage, disparado quando uma mensagem chega à fila de envio. Todas as mensagens devem passar por essa fila, independentemente de chegarem por meio do SMTP, do sistema de arquivos ou de qualquer outro mecanismo. O categorizador é um componente essencial da arquitetura de transporte do Exchange Server, responsável pela resolução do destinatário, da bifurcação e do roteamento da mensagem e da geração de DNS (notificação de status de entrega). Por isso, o evento OnSubmittedMessage é uma opção de registro perfeita para agentes que precisem processar todas as mensagens recebidas. O Agente de roteamento de FSE é um componente do Forefront Security registrado no evento OnSubmittedMessage para poder passar todas as mensagens recebidas aos mecanismos de verificação de vírus. Como o Agente de roteamento de FSE está registrado no evento OnSubmittedMessage, nenhuma mensagem pode ignorar a solução de antivírus.
E por que não basta registrar todos os agentes no evento OnSubmittedMessage e considerar o trabalho pronto? Porque você deseja bloquear as mensagens indesejadas com a maior antecedência possível, antes de que o servidor confirme o êxito na entrega. Do contrário, os servidores teriam que processar 90 milhões de mensagens indesejadas durante um spam ou ataque de vírus, precisando gerar possivelmente 90 milhões de NDRs (notificações de falha na entrega), o que, por sua vez, poderia oferecer uma ameaça grave a espectadores inocentes. Spam e ataques de vírus quase sempre usam informações falsificadas sobre o remetente. Enviar milhões de NDRs para destinatários que não criaram as mensagens originais não é apenas uma perda dos seus recursos e dos das organizações de destino, mas também uma oportunidade para que usuários mal-intencionados iniciem inundações de emails e ataques DDoS. É importante parar os acompanhamentos por parte de remetentes mal-intencionados para a sua própria proteção e para a proteção dos demais.
Para bloquear uma mensagem com eficiência, um agente de transporte deve interromper a conversa SMTP com o host remoto antes que o servidor confirme o recebimento dos dados com um código de status 250 OK. De acordo com o princípio armazenar e encaminhar SMTP, o servidor pode descartar com segurança qualquer dado recebido sem gerar NDRs caso a entrega da mensagem não tenha sido confirmada. Os agentes de recebimento SMTP são capazes disso. Eles interagem com a sessão SMTP porque o pipeline de transporte invoca esses agentes com base nos eventos SMTP de recebimento quando o host remoto se conecta ao servidor, estabelece uma sessão SMTP, transmite verbos SMTP, envia mensagens e encerra a conexão. (Os eventos de recebimento SMTP relacionados a cada etapa estão listados na Figura 6.) Por conta da capacidade de rejeitar mensagens antes da entrega e de desconectar hosts SMTP remotos, todos os agentes de anti-spam do Exchange Server 2007 são implementados como agentes de recebimento SMTP.
Figure 6 Eventos de sessão SMTP (Close Figure 6)

Ação | Eventos relacionados
Conexão com o servidor | OnConnectEvent
Estabelecimento de sessão SMTP | OnHeloCommand, OnEhloCommand, OnAuthCommand, OnEndOfAuthentication
Transmissão de verbos SMTP | OnMailCommand, OnRcptCommand, OnDataCommand, OnNoopCommand, OnHelpCommand
Envio de mensagens | OnEndOfHeaders, OnEndOfData
Rejeição de comando ou mensagem | OnReject
Redefinição da conexão | OnRsetCommand
Encerramento da conexão | OnDisconnect
É importante reconhecer a diferença entre os agentes de recebimento SMTP e os agentes de roteamento em relação ao contexto de processamento. Muito embora os agentes de roteamento tenham acesso total às propriedades da mensagem, os agentes de recebimento SMTP são mais contextuais porque interagem com a sessão SMTP. Por exemplo, não é possível para um filtro anti-spam atuar nas propriedades da mensagem até que o host remoto tenha realmente transferido a mensagem. Por isso, é importante registrar o agente no evento de recebimento SMTP correto. Consulte a barra lateral "Desenvolvimento do agente de transporte" para obter mais detalhes.

Recursos do Exchange
  • Transporte de Borda do Microsoft Exchange Server 2007 e proteção das mensagens (white paper técnico do Microsoft IT Showcase)
  • Script Center do Windows PowerShell
  • TechCenter do Exchange Server 2007
  • Blog da equipe do Microsoft Exchange "You Had Me From EHLO"

Fique ligado
Façamos um intervalo antes de nos aprofundarmos na arquitetura de transporte e nos cenários de teste. Eu abordei várias coisas, desde a implantação dos servidores do Transporte de Borda ao estilo da TI da Microsoft até eventos internos disparados no pipeline de transporte durante o processamento das mensagens. Na segunda e última parte desta série, continuarei analisando o comportamento dos agentes do Transporte de Borda em alguns cenários de teste interessantes.
Enquanto isso, recomendo o download da versão de avaliação válida por 90 dias do Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043), e siga as explicações de Steve para compilar e instalar agentes de exemplo no seu ambiente de teste. Mesmo que não seja um desenvolvedor, você verá que cumprir essas tarefas é algo bem simples. Não me surpreenderia ver um número cada vez maior de aplicativos de negócios usando agentes personalizados, dada sua praticidade no Exchange Server 2007 de desenvolver esses componentes com o Visual Studio 2005.

Kay Unkroth é empresário e já trabalhou como engenheiro de suporte, desenvolvedor de sistema, consultor, instrutor e autor especializado em tecnologias de servidor Microsoft por mais de 15 anos. Kay também é co-fundador e presidente da Biblioso Corporation, uma empresa especializada em serviços de documentação gerenciada e de localização.


 SQL Server: Otimizando o desempenho de CPU do SQL Server
SQL Server Zach Nichter

Otimizando o desempenho de CPU do SQL Server
Visão geral:
  • Solução de problemas de desempenho do banco de dados
  • Exame de causas de hardware
  • Uso do PerfMon para controlar afunilamentos do banco de dados
  • Avaliação do desempenho de consultas

Solucionar problemas de desempenho em um sistema de banco de dados pode ser uma tarefa árdua. Saber onde procurar problemas é importante, mas é crucial saber por que o sistema reage dessa forma a uma determinada solicitação. Vários fatores podem afetar a utilização da CPU
em um servidor de banco de dados: compilação e recompilação de instruções SQL, índices ausentes, operações multithreaded, afunilamentos de disco, afunilamentos de memória, manutenções de rotina, atividades ETL (extração, transformação e carregamento) etc. A utilização da CPU não é algo ruim por si só – a CPU está lá justamente para realizar trabalhos. A chave para uma utilização íntegra da CPU é verificar se ela está mesmo dedicando seu tempo a processar o que você deseja que seja processado, e não desperdiçando ciclos com código mal otimizado ou hardware ineficiente.

Dois caminhos que levam ao mesmo lugar
Quando a visão é de um nível mais alto, há dois caminhos para identificar problemas de desempenho da CPU. O primeiro é examinar o desempenho de hardware do sistema, um exercício que ajuda a determinar onde procurar quando você passa ao segundo caminho, examinar a eficiência de consulta do servidor. Esse segundo caminho costuma ser mais eficiente na identificação de problemas de desempenho do SQL Server™. A menos que saiba exatamente onde estão os problemas de desempenho de consulta, você deve sempre começar com uma avaliação do desempenho do sistema. Ao final, você normalmente acaba usando os dois caminhos. Vejamos alguns aspectos básicos para que possamos examinar ambos os caminhos.

Estabelecendo a base
Hyperthreading
Hyperthreading é um tópico que vale a pena abordar um pouco mais por conta da forma com que ele afeta o SQL Server. Na verdade, o hyperthreading apresenta dois processadores lógicos ao sistema operacional para cada processador físico. Basicamente, ele concede tempo nos processadores físicos para que cada processador acabe sendo utilizado por completo. O site da Intel (intel.com/technology/platform-technology/hyper-threading/index.htm) oferece uma descrição bem mais detalhada de como funciona o hyperthreading.
Em sistemas com o SQL Server, como o DBMS, na verdade, processa de maneira extremamente eficiente seu próprio enfileiramento e threading no sistema operacional, o hyperthreading só serve para sobrecarregar as CPUs físicas em sistemas que já têm alta utilização de CPU. Quando o SQL Server coloca várias solicitações na fila para realizar o trabalho em vários agendadores, o sistema operacional precisa alternar continuamente o contexto dos threads nos processadores físicos para atender às solicitações feitas, mesmo que os dois processadores lógicos estejam acima do mesmo processador físico. Caso esteja vendo Alternâncias de Contexto/s superiores a 5.000 por processador físico, você deve considerar a desativação do hyperthreading no sistema e testar novamente o desempenho.
Em casos raros, aplicativos que enfrentam a alta utilização da CPU no SQL Server podem efetivamente usar o hyperthreading. Sempre teste os aplicativos em relação ao SQL Server com hyperthreading ativado e desativado, antes de implementar alterações nos sistemas de produção.

Um processador dual-core avançado superará facilmente a RAM de um computador, que, por sua vez, será mais rápido do que um dispositivo de armazenamento conectado. Uma boa CPU pode processar aproximadamente seis vezes a produtividade da memória DDR2 avançada atual e cerca de duas vezes a produtividade da memória DDR3 avançada. A produtividade de memória típica é mais de 10 vezes a das unidades de Fiber Channel mais rápidas. Já os discos rígidos só podem realizar um número finito de IOPS (operações de entrada/saída por segundo), um valor inteiramente limitado pelo número de buscas por segundo que uma unidade pode realizar. Para ser justo, não é comum que apenas uma unidade de armazenamento seja usada para atender a todas as necessidades de armazenamento em sistemas de bancos de dados corporativos. A maioria das configurações atuais utiliza SANs (redes de área de armazenamento) em servidores de bancos de dados corporativos ou grupos de RAID maiores capazes de anular ou minimizar o problema do processador de E/S do disco. O mais importante é se lembrar de que, independentemente de como seja a configuração, afunilamentos de disco e de memória podem afetar o desempenho dos processadores.
Por conta das diferenças na velocidade de E/S, recuperar dados do disco é muito mais caro do que recuperar dados da memória. Uma página de dados no SQL Server tem 8 KB. Uma extensão no SQL Server é formada por oito páginas de 8 KB, o que equivale a 64 KB. Isso é importante compreender porque quando o SQL Server solicita uma determinada página de dados, não se recupera apenas ela, mas também toda a extensão na qual a página de dados está. Há razões que efetivamente tornam o SQL Server mais econômico, mas eu não entrarei em detalhes aqui. Receber uma página de dados que já esteja armazenada no cache do pool de buffers, no pico do desempenho, deve durar menos de meio milissegundo; recuperar uma única extensão do disco deve levar entre 2 e 4 milissegundos em um ambiente ideal. Eu normalmente espero que a leitura de um subsistema de discos íntegro, com bom desempenho, demore de 4 a 10 milissegundos. Recuperar uma página de dados da memória costuma ser entre 4 e 20 vezes mais rápido do que receber uma página de dados do disco.
Quando solicita uma página de dados, o SQL Server verifica o cache de buffer na memória antes de procurá-la no subsistema de discos. Se a página de dados for encontrada no pool de buffers, o processador recuperará os dados e realizará o trabalho solicitado. Isso se chama falha de página simples. As falhas de página simples são ideais para o SQL Server porque os dados recuperados como parte de uma solicitação devem estar no cache de buffer para que sejam usados. Uma página de dados que não seja encontrada no cache de buffer deve ser recuperada no subsistema de discos do servidor. Quando o sistema operacional precisa recuperar a página de dados do disco, isso é conhecido como falha de página complexa.
Durante a correlação entre desempenho de memória, desempenho de disco e desempenho de CPU, um denominador comum nos ajuda a colocar tudo em uma só perspectiva: produtividade. Em termos nem tão científicos, produtividade é a avaliação de quantos dados é possível transmitir por um pipe limitado.

Caminho 1: desempenho do sistema
Há, de fato, alguns poucos métodos para determinar se um servidor tem um afunilamento de CPU, embora haja muitas causas possíveis para uma alta utilização de CPU. Alguns desses problemas podem ser controlados com PerfMon ou uma ferramenta de monitoramento de sistema semelhante, e outros são controlados usando SQL Profiler ou ferramentas similares. Outro método é usar comandos SQL via Query Analyzer ou SSMS (SQL Server Management Studio).
A filosofia que uso ao avaliar o desempenho de um sistema é "Começar pelo todo e ir se aprofundando". Obviamente, não é possível se concentrar em áreas com problemas até que você as identifique. Depois de avaliar a utilização geral da CPU usando uma ferramenta como PerfMon, você pode usá-la para observar alguns contadores de desempenho bastante simples e de fácil compreensão.
Um dos contadores de desempenho mais conhecidos é % Tempo de Processador; no PerfMon, ele é realçado assim que você abre a janela Adicionar Contador. % Tempo de Processador é o tempo no qual os processadores se mantêm ocupados com a execução do trabalho. A utilização dos processadores costuma ser considerada alta quando esse valor é igual a 80% ou mais para o pico do tempo de operação. É típico e esperado que você veja picos de até 100 por cento às vezes, mesmo quando o servidor não está operando com 80 por cento de utilização.
Outro contador que você deve examinar é Comprimento da fila de processador, que pode ser encontrado no objeto de desempenho Sistema no PerfMon. Comprimento da fila de processador mostra quantos threads estão aguardando a realização do trabalho na CPU. O SQL Server gerencia seu trabalho por meio de agendadores no mecanismo do banco de dados, em que ele coloca na fila e processa suas próprias solicitações. Por gerenciar seu próprio trabalho, o SQL Server só utilizará um único thread da CPU para cada processador lógico. Isso significa que deve haver um mínimo de threads aguardando na fila do processador para realizar o trabalho em um sistema dedicado ao SQL Server. Normalmente, não deve haver nada maior do que cinco vezes o número de processadores físicos em um SQL Server dedicado, mas eu considero mais de duas vezes algo já problemático. Nos servidores em que o DBMS compartilha um sistema com outros aplicativos, você desejará examinar isso com os contadores de desempenho % Tempo de Processador e Alternâncias de contexto/s (abordarei as alternâncias de contexto daqui a pouco) para determinar se os demais aplicativos ou DBMS precisam ser movidos para um servidor diferente.
Quando vejo o processador colocando na fila com uma utilização de CPU alta, eu observo os contadores Compilações/s e Recompilações/s no SQL Server: objeto de desempenho Estatísticas do SQL (consulte a Figura 1). Compilar e recompilar planos de consulta acrescentam à utilização da CPU de um sistema. Você deve ver valores próximos de zero referentes a Recompilações, mas observe as tendências nos sistemas para determinar de que forma o servidor normalmente se comporta e quantas compilações são normais. Nem sempre é possível evitar as recompilações, mas as consultas e os procedimentos armazenados podem ser otimizados para minimizá-las e reutilizar planos de consulta. Compare esses valores com as instruções SQL reais que chegam ao sistema por meio de Solicitações em Lote/s, também encontrado no SQL Server: objeto de desempenho Estatísticas do SQL. Caso as compilações e recompilações por segundo formem um alto percentual das solicitações em lote recebidas pelo sistema, essa é uma área que deve ser examinada. Em algumas situações, os desenvolvedores SQL talvez não compreendam como ou por que o código pode contribuir para com esses tipos de problemas de recurso do sistema. Ainda neste artigo eu darei algumas referências para ajudar você a minimizar esse tipo de atividade.
Figura 1 Selecionando os contadores a serem monitorados
Figura 1 Selecionando os contadores a serem monitorados
Enquanto você estiver no PerfMon, verifique o contador de desempenho chamado Alternâncias de contexto/s (consulte a Figura 2). Esse contador informa quantas vezes os threads precisam ser retirados dos agendadores do sistema operacional (e não do SQL) a fim de realizar o trabalho para os demais threads em espera. As alternâncias de contexto costumam ser muito mais freqüentes em sistemas de bancos de dados compartilhados com outros aplicativos como IIS ou outros componentes do servidor de aplicativos do fornecedor. O limite que eu uso para Alternâncias de contexto/s é de aproximadamente 5 mil vezes o número de processadores no servidor. Esse valor também pode ser alto em sistemas que tenham o hyperthreading ativado e utilização da CPU entre moderada e alta. Quando a utilização da CPU e as alternâncias de contexto excedem regularmente seus limites, isso indica um afunilamento de CPU. Caso isso seja algo regular, você deve começar a planejar a compra de mais CPUs ou CPUs mais rápidas, em caso de desatualização do sistema. Para obter mais informações, consulte a barra lateral "Hyperthreading".
Figure 2 Contadores de desempenho a serem observados (Close Figure 2)

Contador de desempenho | Objeto de contador | Limite | Observações
% Tempo de Processador | Processador | > 80% | As causas em potencial incluem pressão de memória, baixa reutilização do plano de consulta, consultas não otimizadas.
Alternâncias de contexto/s | Sistema | > 5 mil processadores | As causas em potencial incluem os demais aplicativos no servidor, mais de uma instância de SQL Server em execução no mesmo servidor, hyperthreading ativado.
Comprimento da fila de processador | Sistema | > cinco processadores | As causas em potencial incluem outros aplicativos no servidor, muitas compilações ou recompilações, mais de uma instância do SQL Server em execução no mesmo servidor.
Compilações/s | SQLServer:Estatísticas do SQL | Tendência | Comparar com Solicitações em Lote/s
Recompilações/s | SQLServer:Estatísticas do SQL | Tendência | Comparar com Solicitações em Lote/s
Solicitações em Lote/s | SQLServer:Estatísticas do SQL | Tendência | Compare com Compilações e Recompilações por segundo.
Expectativa de Vida da Página | SQLServer:Gerenciador de Buffer | < 300 | Potencial de pressão de memória.
Gravações Lentas/s | SQLServer:Gerenciador de Buffer | Tendência | Potencial de muitas liberações do cache de dados ou pressão de memória.
Pontos de verificação/s | SQLServer:Gerenciador de Buffer | Tendência | Avaliar pontos de verificação em relação a PLE e Gravações Lentas/s
Taxa de Acessos ao Cache: Planos SQL | SQLServer:Cache de Planos | < 70% | Indica baixa reutilização do plano.
Taxa de Acessos ao Cache do Buffer | SQLServer:Gerenciador de Buffer | < 97% | Potencial de pressão de memória.
O Gravador Lento do SQL Server (como ele é chamado no SQL Server 2000) ou o Monitor de Recursos (como ele é chamado no SQL Server 2005) é outra área a ser monitorada quando a utilização da CPU é alta. Liberar o buffer e os caches de procedimento pode acrescentar à hora da CPU por meio do thread de recurso chamado Monitor de Recursos. O Monitor de Recursos é um processo do SQL Server que determina as páginas a serem mantidas e as páginas a serem liberadas do pool de buffers para o disco. Todas as páginas no buffer e nos caches de procedimento são originalmente atribuídas a um custo que representa os recursos consumidos quando elas são colocadas no cache. Esse valor de custo será decrementado sempre que o Monitor de Recursos verificá-lo. Quando uma solicitação exige espaço em cache, as páginas são liberadas da memória com base no custo associado a cada uma delas; as páginas com os menores valores são as primeiras a serem liberadas. A atividade do Monitor de Recursos pode ser controlada por meio do contador de desempenho Gravações Lentas/s no SQL Server: Objeto Gerenciador de Buffer dentro do PerfMon. Você deve controlar essas tendências de valor para determinar o limite típico no sistema. Esse contador costuma ser examinado com os contadores Expectativa de Vida da Página e Pontos de verificação/s para determinar se há pressão de memória.
O contador PLE (Expectativa de Vida da Página) ajuda a determinar a pressão de memória. O contador PLE mostra por quanto tempo uma página de dados permanece no cache de buffer. O limite aceito pelo setor é de 300 segundos para esse contador. Tudo o que estiver abaixo de uma média de 300 segundos durante um período estendido informa você de que as páginas de dados estão sendo liberadas da memória com muita freqüência. Quando isso acontece, ele faz com que o Monitor de Recursos trabalhe mais, o que força mais atividades nos processadores. O contador PLE deve ser avaliado com o contador Páginas do Ponto de Verificação/s. Quando ocorre um ponto de verificação no sistema, as páginas de dados sujas no cache de buffer são liberadas para o disco, o que faz com que o valor PLE diminua. Como o processo Monitor de Recursos é o mecanismo que efetivamente libera essas páginas para o disco, durante esses pontos de verificação, você também deve ver o valor Gravações Lentas/s aumentar. Caso o valor PLE aumente imediatamente após a conclusão de um ponto de verificação, é possível ignorar esse sintoma temporário. Por outro lado, caso você ache que sempre está abaixo do limite de PLE, há uma chance muito boa de que essa memória adicional minimize os problemas e, ao mesmo tempo, libere alguns recursos novamente para a CPU. Todos esses contadores são encontrados no SQL Server: Objeto de desempenho Gerenciador de Buffer.

Caminho 2: desempenho de consultas
Controle SP
Durante o rastreamento do aplicativo do SQL Server, ele é familiarizado com os procedimentos armazenados usados no rastreamento. Usar a interface GUI (SQL Server Profiler) no rastreamento pode aumentar a carga do sistema em 15% a 25%. Caso seja possível usar procedimentos armazenados no rastreamento, isso pode cair pela metade.
Quando sei que há um afunilamento em algum lugar do meu sistema e eu desejo determinar quais são as instruções SQL atuais que estão causando problemas no meu servidor, eu executo a consulta abaixo. Essa consulta me ajuda a ter uma visão individual das instruções e dos recursos usados atualmente, bem como das instruções que precisam ser examinadas para aprimoramentos de desempenho. Para obter mais informações sobre as consultas SQL, consulte msdn2.microsoft.com/ms191006.aspx.
SELECT
    substring(text,qs.statement_start_offset/2
        ,(CASE
            WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2)
    ,qs.plan_generation_num as recompiles
    ,qs.execution_count as execution_count
    ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time
    ,qs.total_worker_time as cpu_time
    ,qs.total_logical_reads as reads
    ,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    LEFT JOIN sys.dm_exec_requests r
        ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC

Os planos de consulta são avaliados, otimizados, compilados e colocados no cache de procedimento quando uma nova consulta é enviada para o SQL Server. Sempre que uma consulta é enviada para o servidor, o cache de procedimento é examinado para verificar se há uma correspondência entre um plano de consulta e uma solicitação. Se houver uma, o SQL Server criará um novo plano para ela, o que pode ser uma operação dispendiosa.
Algumas considerações sobre a otimização de CPU de T-SQL:
  • Reutilização do plano de consulta
  • Redução de compilações e recompilações
  • Classificação de operações
  • Junções incorretas
  • Índices não encontrados
  • Verificações de tabela/índice
  • Uso de funções em cláusulas SELECT e WHERE
  • Operações multithreaded
Então, coloquemos isso um pouco em perspectiva. O SQL Server normalmente recebe dados da memória e do disco, e não é muito comum trabalhar com apenas uma página de dados. Mais freqüentemente, você tem várias partes de um aplicativo funcionando em um registro, executando várias consultas menores ou unindo tabelas para fornecer uma visão completa dos dados relevantes. Em ambientes OLAP, os aplicativos podem receber milhões de linhas de uma ou duas tabelas para que seja possível consolidar, acumular e resumir dados de um relatório de vendas regional. Em situações como essas, o retorno dos dados pode ser medido em milissegundos se os dados estiverem na memória, mas esses milissegundos podem se transformar em minutos com a recuperação dos mesmos dados do disco, e não da RAM.
O primeiro exemplo é uma situação com um grande volume de transações e a reutilização do plano depende do aplicativo. A baixa reutilização do plano causa um grande número de compilações de instruções SQL, o que, por sua vez, resulta em um grande volume de processamento na CPU. No segundo exemplo, a grande reutilização de recursos do sistema pode causar um excesso de atividade da CPU do sistema, uma vez que os dados existentes devem ser constantemente liberados para o cache de buffer para dar espaço ao grande volume de novas páginas de dados.
Considere um sistema altamente transacional, em que uma instrução SQL como a mostrada abaixo é executada 2 mil vezes em um período de 15 minutos para poder recuperar as informações sobre a remessa de caixas. Sem a reutilização de um plano de consultas, hipoteticamente, você poderia ter um tempo de execução individual de aproximadamente 450 ms por instrução. Se o mesmo plano de consultas fosse usado depois da execução inicial, todas as consultas subseqüentes seriam possivelmente executadas em aproximadamente 2 ms, o que resulta em um tempo total de execução de cerca de 5 segundos.
USE SHIPPING_DIST01;
SELECT
    Container_ID
    ,Carton_ID
    ,Product_ID
    ,ProductCount
    ,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;
A reutilização do plano de consulta é crítica para que haja o desempenho ideal em sistemas altamente transacionais e ela costuma ser obtida com a parametrização das consultas ou dos procedimentos armazenados. Aqui estão algumas fontes de informações excelentes sobre a reutilização do plano de consulta:
  • Problemas de compilação em lote, de recompilação e de cache no SQL Server 2005 (microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
  • Otimizando procedimentos armazenados do SQL Server para evitar recompilações (sql-server-performance.com/rd_optimizing_sp_recompiles.asp)
  • Recompilação de consultas no SQL Server 2000 (msdn2.microsoft.com/aa902682.aspx)
Um lugar útil que conta com muitas informações são as DMVs (exibições de gerenciamento dinâmico) do SQL Server 2005. Quando a utilização da CPU é alta, há algumas DMVs que eu uso para me ajudar a determinar se a CPU está sendo utilizada corretamente ou não.
Uma das DMVs examinadas por mim é sys.dm_os_wait_stats, usada para fornecer DBAs com um meio de determinar cada tipo de recurso ou função usado pelo SQL Server, e ela mede o tempo durante o qual o sistema aguarda por conta desse recurso. Os contadores nessa DMV são cumulativos. Isso significa que, para ver claramente os recursos que poderiam afetar diferentes áreas do sistema, você primeiro precisará emitir um comando DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) para redefinir todos os contadores depois de examinar os dados em busca de algum problema pendente. A DMV sys.dm_os_wait_stats é o equivalente do comando SQLPERF(WAITSTATS) do DBCC de verificação da consistência do banco de dados no SQL Server 2000. É possível saber mais informações sobre os tipos diferentes de espera no SQL Server Books Online em msdn2.microsoft.com/ ms179984.aspx.
É importante saber que as esperas são típicas em um sistema, mesmo quando tudo está sendo executado em termos ideais. Você só precisa determinar se as esperas estão sendo afetadas por um afunilamento de CPU. As esperas de sinal devem ser as mínimas possíveis em relação ao tempo de espera geral. O tempo que um determinado recurso aguarda para que um recurso do processador pode ser determinado com a simples subtração do tempo de espera do sinal do tempo de espera total; esse valor não deve ser maior de que aproximadamente 20% do tempo de espera total.
A DMV sys.dm_exec_sessions mostra todas as sessões abertas no SQL Server. Essa DMV oferece uma exibição em alto nível do desempenho de cada sessão e todo o trabalho realizado por cada uma desde sua criação. Isso inclui o tempo total que a sessão perdeu esperando, a utilização da CPU total, o uso da memória e uma contagem das leituras e das gravações. A DMV também fornecerá a você o login, a hora do login, o computador host e o último momento em que a sessão enviou uma solicitação do SQL Server.
Usando a DMV sys.dm_exec_sessions, você poderá determinar apenas as sessões ativas; portanto, caso você esteja vendo uma alta utilização da CPU, esse é o primeiro local a ser observado. Examine as sessões que tenham uma alta contagem de CPU primeiro. Determine o aplicativo e o usuário que estão realizando o trabalho e comece a se aprofundar. Comparar sys.dm_exec_sessions com a DMV sys.dm_exec_requests pode oferecer grande parte das informações disponíveis por meio dos procedimentos armazenados sp_who e sp_who2. Caso relacione esses dados à DMF (função de gerenciamento dinâmico) sys.exec_sql_text usando a coluna sql_handle, você pode obter a consulta atualmente em execução da sessão. O trecho na Figura 3 mostra como integrar esses dados para ajudar a determinar o que realmente está acontecendo em um servidor.
Figure 3 Determinando atividade do servidor (Close Figure 3)
SELECT es.session_id
    ,es.program_name
    ,es.login_name
    ,es.nt_user_name
    ,es.login_time
    ,es.host_name
    ,es.cpu_time
    ,es.total_scheduled_time
    ,es.total_elapsed_time
    ,es.memory_usage
    ,es.logical_reads
    ,es.reads
    ,es.writes
    ,st.text
FROM sys.dm_exec_sessions es
    LEFT JOIN sys.dm_exec_connections ec
        ON es.session_id = ec.session_id
    LEFT JOIN sys.dm_exec_requests er
        ON es.session_id = er.session_id
    OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50    -- < 50 system sessions
ORDER BY es.cpu_time DESC
Eu achei que essa instrução ajuda a determinar os aplicativos que precisam de atenção. Quando eu comparo CPU, memória, leituras, gravações e leituras lógicas de todas as sessões dentro de um aplicativo e determino que o recurso de CPU é muito maior do que os demais recursos utilizados, começo a me concentrar nessas instruções SQL.
Para controlar historicamente as instruções SQL de um aplicativo, eu uso os rastreamentos do SQL Server. É possível acessá-los por meio da ferramenta SQL Server Profiler ou dos procedimentos armazenados do sistema de rastreamento para ajudar a avaliar o que está acontecendo. (Consulte a barra lateral "Controle SP" para obter mais informações sobre o tópico.) O Profiler deve ser examinado em busca de instruções com alta utilização da CPU, bem como avisos de hash e de classificação, perdas de cache e outros sinalizadores vermelhos. Isso pode ajudar você a restringir instruções SQL específicas ou um período específico que tenha causado uma alta utilização do recurso. O Profiler é capaz de controlar coisas como o texto da instrução SQL, os planos de execução, a utilização da CPU, o uso da memória, as leituras lógicas, as gravações, o armazenamento em cache dos planos de consulta, as recompilações, as ejeções dos planos de consulta do cache, as perdas de cache, as verificações de tabela e índice, as estatísticas não encontradas e muitos outros eventos.
Depois de colher os dados dos procedimentos armazenados sp_trace ou do SQL Server Profiler, eu costumo usar um banco de dados, preenchido com dados de rastreamento após o fato ou com a configuração do rastreamento para gravar no banco de dados. Preencher o banco de dados após o fato pode ser feito usando a função do sistema do SQL Server chamada fn_trace_getinfo. O benefício dessa abordagem é que eu posso consultar e classificar os dados de várias formas para ver quais instruções SQL mais usaram a CPU ou tiveram mais leituras, contar quantas recompilações houve e muitas outras coisas. Eis um exemplo de como essa função é usada para carregar uma tabela com um arquivo de rastreamento do Profiler. O padrão determina que todos os arquivos deste rastreamento serão carregados na ordem em que foram criados:
SELECT * INTO trc_20070401
FROM fn_trace_gettable('S:\Mountpoints\TRC_20070401_1.trc', default);
GO

Conclusão
Como você viu, a alta utilização da CPU não necessariamente indica a existência de um afunilamento de CPU. A alta utilização da CPU talvez esteja escondendo vários outros afunilamentos de aplicativo ou de hardware também. Depois de identificar que você tem uma alta utilização da CPU, apesar dos demais contadores parecerem íntegros, é possível começar a procurar a causa dentro do sistema e isolar uma solução (seja a compra de mais CPUs ou a otimização do código SQL). E independentemente do que você faça, não desista! Com as dicas fornecidas neste artigo, com um pouco de prática e de pesquisa, a otimização da utilização da CPU no SQL Server é um plano de execução possível.

Zach Nichter é um profissional de SQL Server com mais de dez anos de experiência. Ele tem assumido várias funções de suporte do SQL Server, incluindo administrador de banco de dados, chefe de equipe, gerente e consultor. Atualmente, Zach trabalha na Levi Strauss & Co. como o arquiteto do banco de dados, enfocando o desempenho, o monitoramento, a arquitetura e outras iniciativas estratégicas. Além disso, Zach é autor do blog de vídeo em www.sqlcatch.com.


 Do editor: O melhor ainda est&#225; por vir
Do editor
O melhor ainda está por vir
Joshua Hoffman

Acredite ou não, mas começarei minha Nota do Editor com um flashback. Saiba você que usar esse tipo de artifício literário tão cedo não me agrada muito, mas, de qualquer forma, aqui vamos nós.
No segundo semestre de 2005, as duas edições inaugurais da TechNet Magazine foram tão bem recebidas que era o momento de aumentar o cronograma de produção e de começar a oferecer excelente conteúdo técnico para profissionais de TI regularmente. Joshua Trupin, o nosso editor executivo, e Stephen Toub (o então editor técnico da nossa publicação irmã, a MSDN Magazine), tinham feito um trabalho incrível reunindo especialistas e planejando as suas primeiras edições, mas ambos tinham que voltar a seus trabalhos.
Então, eu entrei para a equipe como editor técnico, agradecido pela confiança que eles depositaram em mim e pelo trabalho que haviam feito até então. Afinal, produzir uma revista não é nada simples. Tenho um histórico profissional de TI (totalmente especializado), tendo passado os quatro anos anteriores nos Serviços de Consultoria Microsoft. Eu tinha relativamente pouca (nenhuma) noção de como funcionava uma publicação. Tinha uma lista de leituras quilométrica. Havia três edições para começar a planejar imediatamente. Tinha novos colegas, autores, revisores técnicos, parceiros comerciais e, claro, leitores para conhecer. E, sobretudo, eu tinha prazos de impressão que não poderiam ser alterados (o que, como você pode imaginar, é um conceito difícil para um antigo funcionário da Microsoft entender).
Mas a equipe me recebeu, me suportou e me animou, além de ter feito mais para me ajudar na execução do trabalho do que você possa imaginar. Os autores, revisores, parceiros e vocês – nossos leitores – fizeram deste um trabalho fascinante, desafiador e muito recompensador, e eu sou privilegiado por ter feito tantos novos amigos. Eu olho para os dois anos que passamos com orgulho do que essa equipe conseguiu. Mas agora, como novo editor-chefe, estou ainda mais entusiasmado com o que nos espera à frente.
Esta revista existe com a única missão de tornar profissionais de TI bem-sucedidos em relação aos produtos e tecnologias Microsoft (acredite, os nossos salários dependem essencialmente disso). Você nos disse onde fomos bem e, o que é mais importante, onde tínhamos que melhorar. Levamos esses comentários muito a sério. Nos próximos meses e anos, continuaremos melhorando, agregando novos autores e novas colunas, aprimorando a nossa plataforma on-line com novo conteúdo e novas mídias e, esperamos, permitindo que você aprenda da maneira que melhor lhe convier. No entanto, nada disso pode dar certo sem a sua permanente colaboração. Diga-nos o que funciona e o que não funciona para você. Onde devemos usar o nosso tempo? Como é você quem está no controle, você também pode aproveitar isso. Envie um email para tnmag@microsoft.com e faça-se ouvir. —Joshua Hoffman

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Omesh Desai, Raja Ganjikunta, Saleem Hakani, Justin Hall, Michael Murgolo, John Orefice, Jim Truher, Marc Umeno, Jeff Wettlaufer, Buck Woody e Minxiao Zhou.


 Toolbox: Novos produtos para profissionais de TI
Toolbox
Novos produtos para profissionais de TI
Greg Steen

Scripts mais poderosos
PowerShell Analyzer
www.pwershellanalyzer.com
Muito tem se falado a respeito do Windows PowerShell™, e com razão. Se você ainda não teve oportunidade de experimentar essa linguagem de script de última geração, procure fazê-lo. E aqueles que já fizeram a atualização para o Microsoft® Exchange 2007 rapidamente perceberão que o novo Shell de Gerenciamento do Exchange foi criado com base no Windows PowerShell, permitindo fazer tudo o que o Console de Gerenciamento do Exchange faz, só que a partir da linha de comando, o que é ótimo para automatizar tarefas repetitivas. Infelizmente, pode haver uma certa curva de aprendizagem para o uso da sintaxe e da semântica. É aqui que entra o PowerShell Analyzer, da ShellTools.
O aplicativo é basicamente um IDE para escrever e depurar scripts do Windows PowerShell. Mas, ao contrário do ciclo tradicional de escrever-compilar-testar, o aplicativo é ideal para o administrador que prefere usar o teclado, permitindo a interatividade em tempo real com um espaço de execução do Windows PowerShell. O PowerShell Analyzer permite digitar comandos linha por linha ou então criar, editar e executar scripts do Windows PowerShell em um editor na parte inferior da interface do usuário. As duas opções proporcionam o preenchimento básico do código, uma grande ajuda para orientá-lo quanto aos diversos parâmetros dos cmdlets (se você é iniciante no Windows PowerShell, cmdlets são comandos abstratos, orientados a tarefas e parametrizados).
Para ajudar ainda mais, o PowerShell Analyzer traz uma guia de acesso rápido que mostra descrições detalhadas, sintaxe, explicações de parâmetros e exemplos de cada cmdlet. Além disso, há referências de provedores do Windows PowerShell, os arquivos internos de ajuda disponíveis e os aliases curtos dos cmdlets.
Quando você executa comandos no Windows PowerShell, na verdade recebe como retorno objetos do Microsoft .NET Framework, e não apenas os resultados de texto aparentes na tela. O PowerShell Analyzer permite capturar as propriedades dos resultados retornados e passá-las para diversos "visualizadores". Esses visualizadores permitem interagir com os objetos — por exemplo, oferecendo uma exploração em formato de árvore dos dados XML ou uma visualização hierárquica, classificável e agrupável dos dados em tabela — e também gerar vários gráficos diferentes para representar visualmente o conjunto de dados retornado. Claro que nem todas essas opções estão disponíveis para todos os comandos ou scripts executados. Mas, quando são aplicáveis, fornecem um amplo conjunto de representações dos dados, que você pode salvar ou exportar para reutilização.
O PowerShell Analyzer possibilita ainda trabalhar simultaneamente com vários espaços de execução, facilitando a alternância entre tarefas. E a janela do editor traz estilos de contorno de código e realce de código personalizável para ajudar a tornar seus scripts mais legíveis.
Enfim, se você vai trabalhar com o Windows PowerShell, uma ferramenta como o PowerShell Analyzer tornará muito mais fácil criar, editar e depurar seus scripts.

Preço: US$ 129 (para venda direta) por licença de usuário.
Figura do PowerShell
Figura do PowerShell

Desfragmentação de discos
Auslogics Disk Defrag
www.auslogics.com/disk-defrag
Quanto mais você usa seu disco rígido, mas fragmentados ficam os arquivos contidos nele. Criar e excluir arquivos, instalar e remover aplicativos e até mesmo gerar caches e arquivos temporários em disco — tudo isso contribui para a fragmentação. E a taxa de fragmentação pode aumentar drasticamente quando o espaço livre na unidade é limitado, pois os novos arquivos se espalham pelos "buracos" disponíveis em um espaço quase totalmente preenchido. Toda essa fragmentação leva à lentidão no desempenho do sistema.
Logicamente, todos sabem que as versões atuais do Windows® contam com ferramentas internas de desfragmentação. Mas se você busca uma opção dedicada ou fez recentemente a atualização para o Windows Vista® e sente falta do controle e da apresentação da interface do usuário que eram oferecidos pelas versões anteriores da ferramenta de desfragmentação, há uma alternativa muito interessante para experimentar: o Disk Defrag, da Auslogics.
O Disk Defrag funciona com Windows XP, Windows 2000, Windows Server® 2003 e Windows Vista. E, como você provavelmente já imagina, é capaz de desfragmentar volumes FAT16, FAT32 e NTFS. É um aplicativo simples e a instalação é feita rapidamente, com alguns cliques.
Executar o aplicativo é igualmente fácil. Basta escolher a unidade que deseja desfragmentar, clicar em Next (Avançar) e assistir enquanto a ferramenta faz o trabalho. Quando a execução é concluída, o Disk Defrag apresenta uma breve visão geral dos resultados, mostrando o número total de arquivos, diretórios, arquivos fragmentados, arquivos desfragmentados e arquivos ignorados, além da redução percentual da fragmentação. Se quiser, você pode também clicar no botão Display Report (Exibir Relatório) do Disk Defrag para que o aplicativo gere uma versão do relatório de desfragmentação em HTML. Esse relatório traz mais algumas informações úteis relativas ao seu disco, como uma lista de arquivos ignorados com a localização, o número de fragmentos, o tempo decorrido na execução e as informações de cluster do disco.

Preço: gratuito.
O Disk Defrag é fácil de instalar e usar
O Disk Defrag é fácil de instalar e usar

Transferência de arquivos
FileZilla
filezilla.sourceforge.net
Nada como um bom cliente de SFTP para tornar seu trabalho mais fácil. Isso é especialmente verdadeiro no caso de um cliente bem escrito e gratuito como o FileZilla. O FileZilla é um projeto de código aberto hospedado em SourceForge.net, iniciado por Tim Kosse e alguns colaboradores em 2001 como um trabalho para uma aula de ciência da computação. O FileZilla pode ser executado em todas as versões do Windows, desde o Windows NT®4.0 até o Windows Vista. O projeto teve um crescimento considerável nos últimos seis anos, mas Kosse ainda é o líder no que se refere ao aplicativo.
Além de conexões FTP padrão, o cliente oferece suporte a conexões via SFTP com Secure Shell versão 2 (SSH2), FTP via TLS e FTP via SSL com criptografia implícita e explícita, permitindo a conexão com uma grande variedade de servidores. O FileZilla é capaz de acomodar firewalls locais, permitindo limitar as portas locais usadas e também definir uma ligação IP específica para transferências não-passivas, tanto para IPv4 quanto para IPv6. O cliente ainda oferece suporte a diversas configurações de proxy, inclusive proxies SOCKS4/5, HTTP1.1 e FTP.
Em termos de autenticação de servidor para conexões FTP, o FileZilla oferece suporte a configurações anônimas, normais com nome de usuário e senha e baseadas em conta. Você pode também habilitar o suporte aos GSS (Generic Security Services) da Kerberos (para isso, é preciso que o Kerberos para Windows esteja instalado no sistema) e criar uma lista de servidores habilitados para GSS. Logicamente, você precisará de um tíquete válido do Kerberos v5 para que os GSS funcionem. Também é possível habilitar o suporte para o seu servidor Ident, permitindo a conexão com servidores que exigem isso como forma de identificar seu cliente.
O FileZilla gerencia facilmente uma grande coleção de sites FTP e permite organizar suas conexões em uma estrutura de árvore. Para cada conexão configurada, também é possível definir os diretórios padrão local e remoto, especificar a porta com a qual conectar-se, optar por ignorar o proxy configurado, escolher explicitamente entre os modos de transferência ativo e passivo e até mesmo definir uma compensação de fuso horário do servidor. Além das conexões salvas, o FileZilla conta ainda com o recurso Quickconnect, para transferências feitas uma só vez. Basta digitar o endereço, o nome de usuário, a senha e a porta, e então clicar em um botão para conectar-se. Quando tiver todas as suas configurações e conexões definidas, você poderá exportá-las para XML para backup ou reutilização em outros sistemas.
A interface do usuário do aplicativo, semelhante à do Windows Explorer, permite arrastar e soltar arquivos facilmente entre os sistemas local e remoto. Para transferências de arquivos, é possível especificar uma configuração padrão de substituição de arquivos, além da opção de limitar as velocidades de download e upload com base em um conjunto predefinido de regras ou em um limite de velocidade constante em kBs. Por padrão, o FileZilla é configurado para usar transferências de arquivos compactados MODE Z em servidores com suporte, mas você pode ajustar o nível de compactação ou desativar esse recurso. O cliente conta também com um recurso de fila de transferência que permite colocar em fila um conjunto de arquivos a serem transferidos e, em seguida, importar e exportar essa lista de transferência para reutilização. Isso é muito útil quando se trata de tarefas repetitivas de administração do sistema.

Preço: gratuito.

Edição de executáveis
PE Explorer
www.heaventools.com
Para aqueles que realmente gostam de chegar ao âmago dos aplicativos, é interessante conhecer o PE Explorer, da HeavenTools. Esse aplicativo permite aprofundar-se nos aspectos internos de arquivos PE (executáveis portáteis), usados para binários executáveis em aplicativos do Windows. Simplesmente, o PE Explorer fornece uma interface do usuário para explorar e editar o conteúdo desses executáveis. O PE Explorer é capaz de abrir uma grande variedade de tipos de arquivos, desde os mais comuns, como EXEs e DLLs, até os menos familiares, como DPLs e CPLs.
Da primeira vez que você opta por explorar um executável, o PE Explorer mostra informações sobre os cabeçalhos do arquivo, como o número de seções de código, o tamanho da imagem, o subsistema do aplicativo e o tamanho da pilha. Outra exibição traz uma visão geral dos cabeçalhos de seção no executável. Clicar duas vezes em um cabeçalho de seção abre uma janela que permite explorar o conteúdo de cada seção.
Certamente destinado aos mais corajosos, o aplicativo permite extrair, recalcular e excluir seções do PE carregado. É uma ótima ferramenta para detectar vírus, malware e outros elementos desagradáveis encontrados em executáveis. Você pode usar o recurso Digital Signature Viewer do aplicativo para revisar e validar a assinatura digital Microsoft Authenticode do arquivo executável carregado, se estiver presente. Essa é uma forma eficaz de verificar o editor e a integridade do executável.
O PE Explorer contém um recurso interno de desmontagem rápida que permite ver o código de assembly do executável. E ainda oferece suporte aos conjuntos comuns de instruções do Intel x86, juntamente com extensões como MMX, 3D Now! e SSE/2/3. O recurso de desmontagem extrai também cadeias de texto ASCII da parte de dados do PE.
Outro recurso é o Dependency Scanner, que examina todos os módulos aos quais o arquivo PE se vincula estaticamente e aqueles que têm o carregamento atrasado, exibindo-os em uma estrutura de árvore hierárquica e mostrando até onde vai o raio de alcance do PE.
Na minha opinião, uma das partes mais divertidas do PE Explorer é o Resource Editor. Esse recurso permite exibir, extrair, substituir, editar e excluir os recursos de um executável especificado. A interface do usuário mostra uma estrutura semelhante a um diretório com os recursos incorporados, como imagens, sons, caixas de diálogo, menus, dados XML, dados HTML e barras de ferramentas. Nem todos esses recursos oferecem suporte à edição direta, mas a maioria pode ser substituída e editada. Isso permitiria, por exemplo, que você adicionasse sua marca personalizada a um aplicativo, alterasse as mensagens das caixas de diálogo, personalizasse as ações das barras de ferramentas e assim por diante, sem ter acesso ao código-fonte propriamente dito. O PE Explorer é uma ferramenta muito útil para quem deseja aprofundar-se nos executáveis. Contudo, se o único recurso que você realmente deseja é o Resource Editor, avalie o aplicativo Resource Tuner, da mesma empresa e muito mais barato.

Preço: US$ 129 (para venda direta) para uma licença pessoal; US$ 199 (para venda direta) para uma licença comercial.
Figura do PE Explorer
Figura do PE Explorer

Resenha de livro
Segurança de pontos de extremidade
www.awprofessional.com
Acrescentar um perímetro de rede de tradição sólida à sua infra-estrutura interna é uma etapa importante na proteção dos seus ativos. Mas não é infalível. Com a mobilidade e a conectividade crescentes do hardware e do software na atualidade, sua infra-estrutura corporativa não tem um perímetro real. Em vez disso, ela se estende a pontos de extremidade remotos. Na verdade, enquanto você se protege contra ataques vindos de fora do ambiente, é mais provável que um ataque seja iniciado acidentalmente por um usuário que traz o laptop de casa e se conecta à sua rede corporativa não controlada.
Se você está em busca de atualização para controlar o acesso à rede e proteger os pontos de extremidade da sua infra-estrutura, deve consultar o livro de Mark Kadrich, Endpoint Security (Segurança de pontos de extremidade; Addison-Wesley Professional, 2007). Inicialmente, o livro define o que são exatamente os pontos de extremidade. Depois, traz uma visão geral das muitas variações existentes — clientes Windows, clientes Linux, dispositivos incorporados, celulares e PDAs. Kadrich encara a rede como um "problema de controle". O autor rejeita a representação típica de uma rede complexa análoga a um sistema orgânico. Em vez disso, ele a descreve como algo que pode ser delineado e visualizado de forma útil e gerenciável.
O livro analisa os fundamentos de NAC (controle de acesso à rede) e de como estabelecer um nível básico de confiança. Essa discussão inclui como implantar uma linha de base segura para seus sistemas de ponto de extremidade, protegendo e controlando o software de origem e o ambiente de compilação. Há uma visão geral das ferramentas que ajudam a manter a segurança dos pontos de extremidade abordando pontos familiares, como o uso de software de firewall e antivírus, e apontando a necessidade de um gerenciamento proativo de patches. Por fim, são abordadas ferramentas mais avançadas, como sistemas de detecção e prevenção de intrusões, verificadores de integridade de hosts e criptografia.
A segunda metade do livro explora detalhes da proteção dos sistemas operacionais de vários tipos de clientes, inclusive Microsoft Windows, Apple OS X e Linux. Cada um desses capítulos traz uma visão geral de como realizar uma verificação de integridade inicial no sistema dos seus pontos de extremidade. Há também capítulos dedicados a PDAs, Smartphones e dispositivos incorporados, discutindo como esses dispositivos se tornaram uma grave ameaça à infra-estrutura e como proteger vários tipos de comunicações realizadas por eles.
Por fim, Kadrich analisa quatro estudos de caso e identifica, em cada um deles, como os pontos de extremidade foram comprometidos e como a falha poderia ter sido atenuada. De forma geral, Endpoint Security traz muitas informações úteis para os profissionais de segurança e apresenta uma visão independente de fornecedor para a proteção da sua rede, privilegiando o perímetro dos pontos de extremidade.

Preço: US$ 54,99 em catálogo.

Greg Steen é um profissional de tecnologia, empreendedor e entusiasta em busca de novas ferramentas e referências para ajudar a tornar as operações e o desenvolvimento mais fáceis para os profissionais de TI. Tem alguma sugestão? Então entre em contato com ele pelo email tntools@microsoft.com


 P&amp;R do SQL: Disparadores de logon, desfragmenta&#231;&#245;es de arquivos de dados e muito mais
P&R do SQL
Disparadores de logon, desfragmentações de arquivos de dados e muito mais
Editado por Nancy Michell

Configurando a conta de serviço
Dica: senhas mais seguras
O mecanismo do SQL Server 2000 mantém duas cópias de cada senha de logon no SQL Server. Uma versão é a senha propriamente dita, fornecida pelo usuário; a outra é a senha com todas as letras maiúsculas.
Essa prática ajuda na validação de senhas sem diferenciação entre maiúsculas e minúsculas, pois o usuário pode fazer logon usando a senha com maiúsculas e minúsculas ou só com maiúsculas e ter o acesso ao servidor concedido. No entanto, essa conveniência gera um problema. Salvar senhas com todas as letras maiúsculas facilita os ataques maciços de quebra de senha, por reduzir o número de combinações de senhas possíveis.
O SQL Server 2005 armazena somente a cópia da senha original. A senha digitada pelo usuário deve corresponder àquela armazenada no servidor. Se não houver correspondência, o logon falhará e o usuário terá o acesso negado. Se o uso específico de maiúsculas e minúsculas for esquecido, a senha precisará ser redefinida.
Supondo que o nome de logon de um usuário seja SQLCOMMUNITY, é possível redefinir sua senha no SQL Server usando o comando a seguir:
Use Master;
ALTER LOGIN SQLCOMMUNITY WITH PASSWORD = 'k3t9h4s8wJF7t';
Esse comando redefiniria a senha do logon SQLCOMMUNITY no SQL Server para "k3t9h4s8wJF7t".

P No SQL Server™ 2000, eu costumava definir a conta de serviço do SQL Server Engine e Agent usando o miniaplicativo Serviços, em Ferramentas Administrativas. No entanto, tenho ouvido falar que, no SQL Server 2005, devo usar a ferramenta Configuration Manager. Por que não posso simplesmente continuar usando as ferramentas do Windows?
R O SQL Server 2005 foi criado para ser mais seguro do que as versões anteriores. Em muitos ambientes, os usuários simplesmente definiam contas internas, como LocalSystem, para executar o SQL Server. Mas, em geral, essas contas têm, no Windows®, mais ou menos permissões do que realmente necessitam. Você deve criar uma conta do Windows sem privilégios elevados para executar os serviços do SQL Server 2005 Engine e Agent. Se essas contas forem selecionadas com o Configuration Manager, os direitos e as permissões adequados serão concedidos a elas automaticamente, tanto no SQL Server quanto no sistema operacional. Caso você use as ferramentas do Windows para gerenciar os serviços do SQL Server, talvez não conceda os direitos adequados, ou então conceda direitos demais.
Para obter mais detalhes, consulte a dica Alterando a conta de serviço.

Quem está fazendo logon no meu servidor?
P Quero saber quem está fazendo logon no meu servidor e quando. Quero também restringir alguns usuários específicos a determinados períodos e gostaria de saber como acionar um rastreamento para monitorar as atividades dos usuários. Isso é possível?
R Sim, você pode fazer tudo isso com o SQL Server 2005 se tiver o Service Pack 2 instalado.
O SQL Server 2005 permite criar disparadores de logon capazes de acionar um procedimento T-SQL ou armazenado em resposta a um evento LOGON. Você pode usar um disparador de logon para auditar e controlar os usuários, rastreando as atividades de logon, restringindo os logons no SQL Server ou limitando o número de sessões para logons específicos. Observe que o evento só é acionado depois que um logon é autenticado com sucesso, mas logo antes do estabelecimento efetivo da sessão do usuário. Por isso, todas as mensagens originadas no disparador (como mensagens ou erros), a partir da instrução PRINT, são enviadas para o log de erros do SQL Server. Se houver falha na autenticação de um logon, os disparadores de logon não serão acionados.
O exemplo a seguir mostra como você pode criar um disparador de logon e enviar uma mensagem para o log de erros do SQL Server assim que qualquer usuário fizer logon:
ALTER TRIGGER Ops_Login
ON ALL SERVER
AFTER LOGIN
AS
PRINT SUSER_SNAME() + ' has just logged in to ' + LTRIM(@@ServerName) + ' SQL Server at '+LTRIM(getdate())
GO
Para exibir todos os disparadores definidos em nível de servidor, use esta consulta:
SELECT * FROM sys.server_triggers;

Práticas recomendadas de desfragmentação
P Qual a melhor forma de corrigir a fragmentação dos arquivos de dados no SQL Server? Se usamos as ferramentas de desfragmentação do Windows, elas tratam o arquivo de dados SQL como um todo e não o desfragmentam de forma granular.
R Você pode fazer backup do banco de dados e depois restaurá-lo. Se houver espaço para um arquivo contíguo, então o banco de dados deve ser gravado de forma contígua. Isso posto, normalmente a tentativa de desfragmentar os arquivos físicos não vale a pena, devido ao tempo de inatividade necessário. Em geral, não há mesmo muita fragmentação externa. É mais útil reindexar seus dados regularmente para reduzir tanto quanto possível a fragmentação interna. Isso elevará ao máximo a eficácia dos read-aheads e a quantidade de dados que pode ser armazenada em buffer.
Os fatores mais importantes para uma E/S de disco eficiente são verificar se o alinhamento do disco e a configuração de RAID estão corretos, dimensionar suas matrizes de discos para manipular adequadamente a carga de E/S e manter um layout adequado dos arquivos Log, Data, TempDB e de backup. Se você evitar o uso do crescimento automático e da redução automática como métodos principais para dimensionar arquivos de dados, reduzirá o número de fragmentos de arquivos criados em nível de volume. Por exemplo, realizar 10 crescimentos automáticos de 500 MB cada um provavelmente adicionaria 10 novos fragmentos de arquivos físicos. Por outro lado, um único crescimento manual de 5 GB adicionaria apenas um.

Dica: alterando a conta de serviço
Você sabia que quando a conta de logon de serviço do SQL Server é configurada com uma conta do Windows NT®, o SQL Server define os direitos de usuário e as permissões do Windows em vários arquivos, pastas e chaves do Registro? Também é possível definir a conta de serviço do SQL Server no console Serviços, em Ferramentas Administrativas. No entanto, quando você fizer isso em Serviços, os direitos e as permissões não serão definidos e poderão ocorrer sérios problemas, devido à ausência de configurações adequadas de segurança nos itens já mencionados do SQL Server e do Windows.
Portanto, é altamente recomendável que você use o SQL Server Configuration Manager, e não o console Serviços, ao alterar a conta de serviço do SQL Server ou do SQL Server Agent. No entanto, se você já fez alterações na conta usando o console Serviços, ainda pode corrigir esse problema.
Etapa 1: aplique permissões totais às seguintes chaves do Registro e às suas subchaves:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>
Etapa 2: defina controle total para a conta de inicialização do serviço MSSQLServer e para o serviço SQLServerAgent (uma conta local do Windows NT ou uma conta de domínio do Windows NT) nesta pasta NTFS:
Drive:\Program Files\Microsoft SQL Server\<MSSQL.1>\MSSQL
Contudo, em vez de fazer isso manualmente, é recomendável usar o SQL Server Configuration Manager para fazer alterações em contas de serviço do SQL Server/Agent.

Meus agradecimentos aos seguintes profissionais de TI da Microsoft por seus conhecimentos técnicos: Cary Gottesman, Saleem Hakani, Trayce Jordan, Peter Kalbach, Al Noel, Uttam Parui, Amber Sitko e Buck Woody.


 Utilit&#225;rio em destaque: Virtual Machine Remote Control Plus
Utilitário em destaque
Virtual Machine Remote Control Plus
Matthijs ten Seldam
Faça download do código deste artigo: UtilitySpotlight2007_10.exe (10163KB)

A virtualização é um assunto em alta. Muitos profissionais de TI usam a virtualização de hardware para o aprendizado e o teste de cenários. Em função disso, a Microsoft agora oferece o Virtual PC 2007, uma solução de virtualização de software destinada a instalações autônomas com um número limitado de máquinas virtuais. Observe que esse novo produto não substitui o Virtual Server
2005, que trouxe a virtualização para o datacenter.
O Microsoft® Virtual Server 2005 permite virtualizar várias cargas de trabalho de servidor mas, ao contrário do Virtual PC, a interface do Virtual Server é um aplicativo Web. Embora o gerenciamento baseado na Web tenha suas vantagens, muitos profissionais preferem, na administração cotidiana, uma interface do usuário avançada que se comporte como um aplicativo do Windows®.
O Virtual Machine Remote Control Plus, ou simplesmente VMRCplus, é uma interface do usuário alternativa para o Virtual Server 2005. Por ser um aplicativo do Windows Forms, o VMRCplus permite gerenciar facilmente o Virtual Server e suas máquinas virtuais. Observe que o Virtual Server vem com uma ferramenta denominada VMRC, usada para o controle remoto de máquinas virtuais. Mas o VMRCplus oferece o gerenciamento de configuração do Virtual Server e também o controle remoto de máquinas virtuais — tudo em um só aplicativo.

O Virtual Machine Manager
A janela principal do VMRCplus, denominada Virtual Machine Manager, é mostrada na Figura 1. Nesse exemplo, o Virtual Machine Manager está conectado ao localhost, com cinco máquinas em execução, três em estado salvo e todas as demais desligadas. A sexta máquina da lista está selecionada, exibindo informações adicionais, inclusive o sistema operacional convidado, a carga de CPU, estatísticas de E/S de disco e de rede e a versão das adições instaladas. Observe que a lista está classificada por Status.
Figura 1 O Virtual Machine Manager do VMRCplus
Figura 1 O Virtual Machine Manager do VMRCplus
Com o Virtual Machine Manager, você pode se conectar aos hosts do Virtual Server e exibir suas máquinas virtuais. Para alternar entre hosts, basta selecionar a guia de um host. É possível conectar-se a um host usando a lista suspensa na barra de ferramentas ou digitando o nome ou o endereço IP do host. Quando a conexão é realizada com êxito, o VMRCplus acrescenta à lista o nome ou o endereço IP.
Algumas propriedades de hosts do Virtual Server, como informações sobre CPU e memória, são exibidas na parte inferior da janela. Um medidor de memória permite visualizar rapidamente a quantidade de RAM ainda disponível para as máquinas virtuais.

Gerenciamento do Virtual Server
O Virtual Machine Manager faz mais do que simplesmente exibir informações. Ele permite também definir configurações. Na opção de menu View (Exibir), é possível definir o intervalo adotado pelo VMRCplus para atualizar a lista de máquinas virtuais. A configuração atual do intervalo de atualização é exibida no canto inferior direito da janela, conforme mostrado na Figura 1.
O menu Virtual Server fornece acesso à configuração do Virtual Server, o que inclui as configurações do VMRC (Virtual Machine Remote Control), a localização padrão das novas máquinas virtuais, configurações de segurança e propriedades de serviço. Na página de configurações do VMRC, é possível definir qualquer propriedade, desabilitar totalmente o VMRC ou reverter as configurações ao padrão do Virtual Server.
Na página de configurações de segurança, é possível especificar as permissões do Virtual Server. Por padrão, o grupo Administradores local tem total controle sobre o Virtual Server. Você pode especificar permissões para grupos de usuários. Se não for membro do grupo Administradores local, precisará primeiro adicionar um grupo ou a sua conta e definir permissões apropriadas. No entanto, não é preciso executar o VMRCplus como administrador. Os privilégios de usuário comum são suficientes.
As propriedades do host do Virtual Server, inclusive físicas, são mostradas na Figura 2. Observe que esse host oferece suporte à virtualização assistida por hardware, como pode ser visto nos recursos do processador.
Figura 2 Propriedades do Virtual Server
Figura 2 Propriedades do Virtual Server

Gerenciamento de discos e redes virtuais
O VMRCplus inclui outros gerenciadores destinados a recursos específicos do Virtual Server. O Virtual Disks Manager tem uma interface com guias correspondentes aos tipos de discos virtuais que podem ser criados, inclusive discos rígidos (dinâmicos ou fixos), disquetes e discos de diferenciação. Você pode também inspecionar seus discos virtuais.
O Virtual Networks Manager permite gerenciar redes virtuais. Você pode adicionar uma rede virtual a partir de um arquivo de VNC (configuração de rede virtual) ou criar uma nova. Ao criar a rede virtual, você pode conectar um adaptador de rede de host ou designar a rede como "somente convidados". Na mesma janela, é possível habilitar um servidor DHCP virtual e abrir suas configurações.

Gerenciamento de máquinas virtuais
Todos os gerenciadores anteriores se concentravam no gerenciamento do Virtual Server. O que o VMRCplus oferece em termos de criação e configuração de máquinas virtuais?
É muito fácil criar máquinas virtuais: basta selecionar Virtual Machine (Máquina Virtual) | Create (Criar) no menu. A caixa de diálogo resultante oferece vários padrões equivalentes aos do Virtual Server, mas existem diferenças por trás da interface. Por exemplo, o VMRCplus sempre cria dois discos rígidos virtuais e os conecta à SCSI. O VMRCplus também permite criar várias máquinas virtuais de uma só vez. Basta selecionar "Create multiple virtual machines" (Criar várias máquinas virtuais) e definir o número desejado. O VMRCplus adiciona um hífen e um número de seqüência ao nome de máquina virtual fornecido.
Um recurso realmente poderoso é a capacidade de criar várias máquinas virtuais a partir de uma máquina virtual primária. Suponha que você criou uma máquina virtual com as adições, o service pack, os hotfixes e as ferramentas mais recentes, e gostaria de usá-la como base para outras máquinas virtuais. Se você tiver executado sysprep como estágio final e desligado a máquina primária, agora poderá criar várias máquinas virtuais que herdarão as propriedades da primária.
Em poucos segundos, será possível criar várias máquinas virtuais com base na máquina primária. Você pode também iniciar rapidamente as novas máquinas virtuais a partir da mesma referência. Quando terminar — um teste, por exemplo — basta excluí-las. E isso também é fácil: o VMRCplus oferece suporte à seleção múltipla na lista de máquinas virtuais, e também à classificação por colunas. Então, pode-se facilmente selecionar e remover várias máquinas virtuais (o que apenas cancela o registro dessas máquinas), ou então excluí-las (o que exclui também os arquivos).
Há outros comandos de seleção múltipla que você pode usar nas máquinas virtuais, como seleção múltipla e iniciar, seleção múltipla e abrir console ou seleção múltipla e salvar estado. Tudo isso pode ser feito com a interface do usuário ou por meio de teclas de atalho.
Também é fácil configurar uma máquina virtual usando a página de configurações de hardware. Você pode definir a quantidade de memória, adicionar controladores SCSI, conectar discos ou imagens (com o recurso de arrastar e soltar) e habilitar e configurar adaptadores de rede. A janela de propriedades avançadas permite definir os itens de configuração mais avançados. É possível, por exemplo, executar máquinas virtuais em uma conta de usuário específica, possibilitando definir uma máquina para ser iniciada automaticamente na inicialização do Virtual Server.

Controle remoto
Por fim, o VMRCplus oferece também o Console Manager, que contém as sessões de controle remoto (sessões VMRC) com máquinas virtuais. Para abrir um console, basta selecionar uma máquina virtual em execução (ou várias) e clicar no botão do console da máquina virtual, na barra de ferramentas de propriedades.
A janela do Console Manager, mostrada na Figura 3, oferece suporte ao ordenamento das sessões remotas em guias. Você pode alternar entre máquinas virtuais selecionando a guia correspondente. Há também uma barra de ferramentas contendo as funções usadas com mais freqüência.
Figura 3 Console Manager
Figura 3 Console Manager
Como você pode ver, o Console Manager conta com menus de contexto que permitem conectar uma imagem de disquete ou uma imagem ISO virtual, montar unidades de host e instalar as adições atuais. Há também uma barra de status que mostra o status das mídias de CD/DVD e disquete, a versão das adições atuais na máquina virtual, a chave de host ativa no momento e a configuração de redimensionamento dinâmico da tela. O VMRCplus permite definir a chave de host. Você pode também acessar as configurações de hardware e as propriedades avançadas da máquina virtual.
O VMRCplus conta com alguns recursos muito úteis. Por exemplo, é possível tirar uma captura de tela das configurações das máquinas virtuais e salvá-la como um arquivo .jpg, algo bastante útil em cenários de solução de problemas. Você pode também usar a opção "Send Text to Virtual Machine" (Enviar Texto para Máquina Virtual), que permite enviar texto para a máquina virtual com o pressionamento de teclas. Esse recurso não foi criado como uma função da área de transferência, mas é muito útil, por exemplo, em situações nas quais você precisa copiar e colar uma chave de produto do host para a máquina virtual.
O VMRCplus foi originalmente criado por Paul Despe como uma ferramenta para desenvolvedores capaz de lidar com algumas funções básicas, mas não com todos os recursos do Virtual Server. Era usado somente para fins de teste e apresentava alguns problemas. Há cerca de um ano, comecei a reescrever, aperfeiçoar e ampliar a funcionalidade do código. Desde então, tornou-se extremamente popular entre os usuários do Virtual Server na Microsoft. Observe, contudo, que o VMRCplus não é um aplicativo com suporte da Microsoft. Ele é fornecido na forma com está e sujeito ao contrato de licença de usuário final incluído.
O VMRCplus foi desenvolvido para o Virtual Server 2005 Service Pack 1. Embora deva haver compatibilidade com as versões anteriores, ele foi testado somente com o Service Pack 1. Portanto, os usuários devem atualizar seus hosts do Virtual Server para o Service Pack 1 antes de usá-lo. O VMRCplus está disponível para download no site da TechNet Magazine em technetmagazine.com/code07.aspx.

Matthijs ten Seldam é consultor principal dos Serviços de Consultoria Microsoft. Sua atuação se concentra nas áreas de segurança, implantação e automação. Ele também é especialista na área de virtualização.


 The Business of IT: Calculando o valor da infra-estrutura de TI no setor governamental
The Business of IT
Calculando o valor da infra-estrutura de TI no setor governamental
Acer Maamoun

Em organizações governamentais, pode ser difícil demonstrar os benefícios do investimento em infra-estrutura de TI — tanto em hardware quanto em software. Assim como em outras organizações de grande porte, os gerentes precisam apresentar um caso comercial para fazer qualquer melhoria ou acréscimo, e que terá de ser priorizado em relação a outras solicitações de fundos.
Como existem várias formas distintas de enquadrar casos comerciais, os gerentes de TI precisam escolher a mais adequada à cultura específica da organização. Isso é válido em relação às organizações governamentais, da mesma forma que nas empresas. É fundamental alinhar a TI às outras prioridades de negócios. No setor governamental, as organizações de TI têm obtido sucesso ao articular casos comerciais utilizando o conceito de valor público na abordagem para criar portfólios de projetos e iniciativas.
É um processo difícil construir um caso comercial capaz de demonstrar como o aperfeiçoamento da infra-estrutura leva ao aumento da produtividade ou a melhores serviços. Vejamos algumas soluções para definir e medir o valor associado aos investimentos em infra-estrutura de TI que vêm sendo adotadas por organizações reais de TI no setor governamental.

Justificando investimentos
Uma reclamação comum nas organizações de TI é que recebem solicitações demais de muitas áreas de negócios diferentes — sendo que cada solicitação, logicamente, tem um alto nível de urgência. As novas iniciativas tendem a fazer o mapeamento das exigências normativas de cada departamento ou de prioridades associadas a missões. Talvez essas iniciativas sejam uma classificação aleatória, mas em geral estão estreitamente alinhadas ao valor público buscado por determinado departamento.
Por outro lado, os custos operacionais distribuídos de acordo com o valor utilizado para dar suporte às operações de um departamento individual podem ocultar o custo (e o valor) de funções de toda a empresa ou serviços compartilhados. Nesse ambiente, pode ser muito difícil avaliar corretamente o valor dos investimentos em uma nova infra-estrutura ou em aperfeiçoamentos na infra-estrutura existente com impacto sobre toda a empresa ou com mapeamento indireto dos objetivos de cada departamento.
Conseqüentemente, a organização de TI como um todo geralmente encontra dificuldades para dar suporte a uma visão empresarial da TI, conforme descrita pela FEAF (Estrutura Federal para Arquitetura Empresarial) da Administração de Serviços Gerais dos EUA (whitehouse.gov/omb/egov/a-1-fea.html). Nesse ambiente, é difícil concretizar a maioria das iniciativas para adotar uma visão compartilhada da arquitetura empresarial, um modelo comum de desenvolvimento de casos comerciais e um processo de gerenciamento de portfólio que nivele as solicitações de investimento e as despesas com TI. Um modelo mais eficaz consiste em dar suporte a um portfólio de atividades de TI que efetivamente valorizem mais os benefícios públicos. Isso exige a seleção e a imposição de critérios comuns de valor público nos processos de desenvolvimento de casos comerciais, gerenciamento de portfólio, identificação de benefícios e avaliação.

Medindo o valor
Há vários problemas reais associados aos investimentos em TI para toda a empresa. Em primeiro lugar, eles têm um impacto mais indireto e de maior duração, em termos de benefícios para o valor público. Esses benefícios são acumulados, geralmente sem uniformidade, por diferentes partes da organização, de formas nem sempre fáceis de identificar à primeira vista. Além disso, os riscos e os custos associados são percebidos de forma mais imediata do que o valor público, bem menos visível e quantificável.
Um caso comercial deve se basear na forma como um investimento em infra-estrutura possibilita futuros investimentos e também atividades atuais. Há diferentes formas de se calcular esse valor, cada qual com vantagens e desvantagens, e cada qual com um nível diferente de adequação à cultura e à maturidade específicas de determinada organização.
Matemático Esse tipo de método se baseia em uma modelagem matemática dos benefícios potenciais. Um método eficaz, chamado de opções reais, tem por base a teoria financeira. Ele incorpora a análise de futuras alterações e de flexibilidade, levando em conta explicitamente o direito de adotar uma ação (ou seja, a opção real) por determinado custo e durante determinado período. As opções incluem adiar, expandir, preparar ou abandonar investimentos; alterar entradas ou saídas; e desenvolver pilotos.
As opções reais são especialmente adequadas quando uma decisão de investimento é influenciada por eventos futuros. No caso da infra-estrutura de TI, tais eventos podem incluir exigências normativas, demandas de negócios ou até mesmo um evento crítico como uma grande falha operacional.
Simulação A análise de incerteza se baseia na simulação de Monte Carlo, que utiliza ferramentas automatizadas para calcular os resultados de cenários alternativos com base na seleção de valores de variáveis e na repetição do processo. A simulação requer a identificação de um conjunto de valores (como o número de estações de trabalho afetadas ou a saturação dos canais eletrônicos) e a distribuição da probabilidade de cada variável. O resultado de uma simulação consiste em diversos resultados possíveis e permite a identificação do valor médio dos benefícios, assim como dos custos e riscos. A escolha cuidadosa das variáveis de valor e risco, de forma a refletir o possível impacto dos investimentos em infra-estrutura, permite pôr em perspectiva o retorno do investimento.
Cenários Quando modelos matemáticos ou de simulação são inviáveis ou não se ajustam à cultura e às habilidades da organização, é possível adotar técnicas baseadas em cenários. Levando em consideração os negócios ou os objetivos do departamento, as prioridades políticas e as tendências ambientais (inclusive de tecnologia), a organização pode desenvolver um número limitado de cenários plausíveis para os próximos três a cinco anos. Cada cenário deve se concentrar exclusivamente em demonstrar os benefícios do investimento em infra-estrutura.
Ao contrário de exercícios de planejamento de longo prazo, os cenários não precisam ser mutuamente exclusivos e podem ter probabilidades atribuídas. Os cenários podem levar em conta futuras eleições, resultados de debates políticos e possíveis eventos do mercado de TI, como aquisições ou mudanças importantes na estratégia dos fornecedores.
Cenário mais desfavorável Essa variação da abordagem baseada em cenários é aplicada quando a organização de TI acredita existir a necessidade urgente de um investimento para atender a desafios futuros relacionados aos negócios ou à missão da agência, ou simplesmente para manter os atuais níveis de serviço. Quando os problemas de infra-estrutura não são tratados, eles pioram, aumentando o esforço necessário para corrigi-los. Quem propuser mudanças provavelmente encontrará resistência e é pouco provável que receba crédito por sua iniciativa. Uma situação assim pode ser parcialmente remediada enfatizando-se a métrica e a medição relevantes para alguns elementos de desempenho afetados — como o tempo de resposta a solicitações e o tempo de reparo. Essas informações devem ser amplamente divulgadas, de forma que todos fiquem cientes das possíveis alterações no desempenho.
Os cenários mais desfavoráveis destacam intencionalmente as conseqüências da não realização do investimento, concentrando-se nos efeitos negativos e no aumento dos riscos. Essa abordagem deve ser adotada de forma muito cuidadosa e somente em circunstâncias excepcionais. Seu uso rotineiro poderia criar a impressão de que a organização de TI está tentando derrubar os processos estabelecidos de gerenciamento de investimentos, o que poderia levar a conflitos e desalinhamentos que esses mesmos processos ajudaram a solucionar.

Escolhendo uma metodologia de planejamento
A Figura 1 resume os prós e os contras de cada método e quando se deve avaliar sua utilização. Quando um método é selecionado, deve ser usado de forma coerente em toda a organização para garantir a possibilidade de comparação.
Figure 1 Metodologias de casos comerciais (Close Figure 1)

Método Vantagens Desvantagens Quando avaliar a utilização
Opções reais (matemático)
  • Rigoroso
  • Base teórica sólida
  • Complexo
  • Inadequado quando prevalecem os valores intangíveis
  • O valor e o valor futuro são predominantemente quantificáveis
  • Há uma forte cultura de avaliação de investimentos
  • As habilidades estão disponíveis de imediato
Simulação
  • Permite a exploração de valores alternativos
  • É uma forma fácil de criar alternativas
  • Talvez os valores médios façam pouco sentido para elementos intangíveis
  • A seleção do intervalo de variáveis é um fator crítico
  • Prevalecem os benefícios tangíveis
  • Há disponibilidade de suporte a ferramentas
Cenário
  • Permite qualquer combinação de benefícios tangíveis e intangíveis
  • Permite explorar cenários muito diferentes, combinando técnicas distintas
  • Requer grande disciplina para a convergência no sentido de cenários comparáveis
  • O prazo pode variar
  • Prevalecem os valores intangíveis ou a verdadeira natureza dos benefícios não está clara
  • A cultura da organização é hostil a outros métodos
Cenário mais desfavorável
  • Visualiza de forma efetiva as conseqüências da não realização de um investimento
  • Criação simples
  • Não ajuda na priorização
  • Pode ser usado indevidamente
  • Os investimentos são absolutamente essenciais e estão atrasados
A eficácia de qualquer uma dessas abordagens depende de diversos fatores. Responder às perguntas a seguir é um bom ponto de partida. Até que ponto a abordagem está integrada ou é compatível com os processos obrigatórios (como o planejamento de orçamento e capital)? O método de caso comercial escolhido é fácil de usar e eficaz em comunicar o valor às partes interessadas?
As organizações precisam buscar o equilíbrio entre a flexibilidade na escolha de indicadores de valor que se ajustem à agência específica e a orientação para garantir a possibilidade de comparação entre agências. Além disso, é de fundamental importância a capacidade de usar determinada métrica de valor em todo o ciclo de vida do investimento, e não apenas no momento de elaboração do caso comercial. Da mesma forma, o plano deve ter utilidade para diferentes tipos de investimentos.
Conseqüentemente, uma abordagem de valor deve ser selecionada e desenvolvida em conjunto com os participantes da estrutura de governança da organização. É essencial que a estrutura selecionada proporcione uma forma eficaz de comunicar o valor às partes interessadas, tanto internas quanto externas. Isso é válido, da mesma forma, para executivos de empresas e para autoridades eleitas ou a gerência de uma agência governamental.
Recursos adicionais
  • Webcast: a TI como um ativo comercial estratégico
  • Série sobre as conexões dos gerentes de TI

Acer Maamoun é um consultor de estratégia corporativa a serviço da Microsoft. Ele tem mais de 18 anos de experiência em estratégia de TI e alinhamento de negócios.


 The Cable Guy: O protocolo Authenticated IP
The Cable Guy
O protocolo Authenticated IP
Joseph Davies
Trechos desta coluna abordam uma versão de pré-lançamento do Windows Server 2008. Esses detalhes estão sujeitos a alteração.

O Windows Vista e o Windows Server 2008 (atualmente em teste beta) dão suporte ao protocolo AuthIP (Authenticated IP), uma versão aprimorada do protocolo IKE (Internet Key Exchange). AuthIP e IKE são protocolos usados para determinar material para chave e negociar parâmetros de segurança para comunicações protegidas que usam
protocolo IPSec (Internet Protocol security). AuthIP oferece configuração e manutenção simplificadas da diretiva IPSec em muitas configurações, além de flexibilidade adicional para autenticação IPSec de mesmo nível. Este artigo descreve os detalhes do protocolo AuthIP e os comportamentos de coexistência entre protocolos IPSec de mesmo nível que dão suporte tanto a AuthIP quanto a IKE ou apenas a IKE.

Visão geral do IKE
Exemplos de negociação
Para demonstrar o comportamento de coexistência, examinemos o que acontece entre os protocolos IPSec de mesmo nível baseado no Windows Vista e no Windows XP durante a tentativa de negociação da proteção IPSec.

Exemplo 1: dois protocolos IPSec de mesmo nível baseados no Windows Vista no modo de solicitação
Nesse exemplo, um IPSec de mesmo nível baseado no Windows Vista (Mesmo nível 1) é o iniciador, e o respondente está executando o Windows Vista (Mesmo nível 2). Ambos os níveis estão configurados com o modo de solicitação para comunicações de entrada e de saída. No modo de solicitação, um IPSec de mesmo nível solicita a proteção IPSec, embora ela não seja necessária. As mensagens trocadas são as seguintes:
  1. Mesmo nível 1 envia um segmento de sincronização (SYN) TCP de texto não criptografado, o que inicia uma conexão TCP com Mesmo nível 2.
  2. Mesmo nível 2 envia um segmento de confirmação (ACK) de SYN TCP.
  3. Mesmo nível 1 envia um segmento ACK TCP.
  4. Mesmo nível 1 envia uma mensagem de protocolo ISAKMP baseada em AuthIP, o que inicia uma negociação no modo principal de AuthIP.
  5. Mesmo nível 1 envia uma mensagem ISAKMP baseada em IKE, o que inicia uma negociação no modo principal de IKE.
  6. Mesmo nível 2 responde com uma mensagem ISAKMP baseada em AuthIP, o que continua uma negociação no modo principal de AuthIP.
  7. Os protocolos de mesmo nível 1 e 2 concluem a negociação no modo principal de AuthIP, no modo rápido e no modo estendido (opcional).
  8. Os segmentos subseqüentes enviados pela conexão TCP são protegidos pelo IPSec.
A ordem exata das mensagens de 1 a 5 depende da latência da rede. Os exemplos descritos neste artigo são para uma rede de latência muito baixa, em que o handshake TCP (mensagens de 1 a 3) é concluído antes que o Mesmo nível 1 possa enviar as mensagens ISAKMP iniciais (mensagens 4 e 5). Em uma rede de latência maior, você veria Mesmo nível 1 enviando o segmento SYN TCP de texto não criptografado, a mensagem ISAKMP baseada em AuthIP e a mensagem ISAKMP baseada em IKE como as três primeiras mensagens da troca.

Exemplo 2: IPSec de mesmo nível baseado no Windows Vista no modo de solicitação e um IPSec de mesmo nível baseado no Windows XP no modo de solicitação
Nesse exemplo, um IPSec de mesmo nível baseado no Windows Vista (Mesmo nível 1) é o iniciador, e o respondente está executando o Windows XP (Mesmo nível 2). Ambos os níveis estão configurados com o modo de solicitação para comunicações de entrada e de saída. As mensagens trocadas são as seguintes:
  1. Mesmo nível 1 envia um segmento SYN TCP de texto não criptografado, o que inicia uma conexão TCP com Mesmo nível 2.
  2. Mesmo nível 2 envia um segmento SYN-ACK TCP.
  3. Mesmo nível 1 envia um segmento ACK TCP.
  4. Mesmo nível 1 envia uma mensagem de protocolo ISAKMP baseada em AuthIP, o que inicia uma negociação no modo principal de AuthIP.
  5. Mesmo nível 1 envia uma mensagem ISAKMP baseada em IKE, o que inicia uma negociação no modo principal de IKE.
  6. Mesmo nível 2 responde com uma mensagem ISAKMP baseada em IKE, o que continua uma negociação no modo principal de IKE.
  7. Os protocolos de mesmo nível 1 e 2 concluem a negociação no modo principal de IKE e no modo rápido.
  8. Os segmentos subseqüentes enviados pela conexão TCP são protegidos pelo IPSec.

Exemplo 3: IPSec de mesmo nível baseado no Windows Vista no modo de solicitação e um IPSec de mesmo nível baseado no Windows XP no modo de exigência
Nesse exemplo, um IPSec de mesmo nível baseado no Windows Vista (Mesmo nível 1) é o iniciador, e o respondente está executando o Windows XP (Mesmo nível 2). Mesmo nível 1 está configurado com o modo de solicitação para comunicações de saída e Mesmo nível 2 está configurado com o modo de exigência para comunicações de entrada. No modo de exigência, um IPSec de mesmo nível exige a proteção IPSec e descarta silenciosamente os pacotes desprotegidos. As mensagens trocadas são as seguintes:
  1. Mesmo nível 1 envia um segmento SYN TCP de texto não criptografado, o que inicia uma conexão TCP, descartada silenciosamente pelo Mesmo nível 2.
  2. Mesmo nível 1 envia uma mensagem ISAKMP baseada em AuthIP, o que inicia uma negociação no modo principal de AuthIP, descartada silenciosamente pelo Mesmo nível 2.
  3. Mesmo nível 1 envia uma mensagem ISAKMP baseada em IKE, o que inicia uma negociação no modo principal de IKE.
  4. Mesmo nível 2 responde com uma mensagem ISAKMP baseada em IKE, o que continua uma negociação no modo principal de IKE.
  5. Mesmo nível 1 e 2 concluem a negociação no modo principal de IKE e no modo rápido.
  6. Mesmo nível 1 retransmite o segmento SYN TCP (protegido com IPSec).
  7. Mesmo nível 2 envia o segmento SYN-ACK TCP (protegido com IPSec).
  8. Mesmo nível 1 envia o segmento ACK TCP (protegido com IPSec).

IKE é um padrão de Internet, definido no RFC 2409 (ietf.org/rfc/rfc2409.txt), que define um mecanismo para estabelecer SAs (associações de segurança) IPSec. Uma SA é uma combinação entre uma diretiva de acordo mútuo e chaves que definem os serviços de segurança e os mecanismos que ajudam a proteger a comunicação entre protocolos IPSec de mesmo nível. Especificamente, IKE combina o protocolo ISAKMP (Internet Security Association and Key Management Protocol) do RFC 2408 e o protocolo OKDP (Oakley Key Determination Protocol) do RFC 2412. IKE usa OKDP para gerar material de chave secreta para comunicações protegidas.
IKE usa ISAKMP para negociar SAs. ISAKMP inclui recursos para identificar e autenticar protocolos de mesmo nível, gerenciar SAs e trocar material para chave. ISAKMP é uma estrutura para negociar comunicações protegidas que independe de determinados protocolos de troca, algoritmos de criptografia e integridade, além de métodos de autenticação.
Os protocolos de mesmo nível IPSec usam IKE para realizar a negociação no modo principal e no modo rápido. A negociação no modo principal cria ISAKMP SA, que protege negociações de segurança. Durante a negociação no modo principal, o iniciador e o respondente trocam uma série de mensagens ISAKMP para poder negociar os algoritmos de criptografia e hash para ISAKMP SA, trocar material de determinação da chave, identificar e autenticar um ao outro.
Na fase de negociação no modo rápido, as duas SAs IPSec (uma SA para dados de entrada e outra SA para dados de saída) são criadas, o que protege os dados enviados entre dois protocolos IPSec de mesmo nível. Durante a negociação no modo rápido, o iniciador e o respondente trocam uma série de mensagens ISAKMP criptografadas para poder negociar os algoritmos de criptografia e hash para SAs IPSec de entrada e de saída.
Para obter mais informações sobre as negociações no modo rápido e no principal baseadas em IKE, consulte "IKE Negotiation for IPsec Security Associations" em microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Visão geral de AuthIP
AuthIP é uma versão aprimorada de IKE que oferece flexibilidade adicional com suporte à autenticação baseada no usuário, autenticação com várias credenciais, negociação do método de autenticação aprimorada e autenticação assimétrica. Assim como IKE, AuthIP dá suporte à negociação no modo principal e no modo rápido. AuthIP também dá suporte ao modo estendido, uma parte da negociação IPSec de mesmo nível durante a qual uma segunda sessão de autenticação pode ser realizada. O modo estendido, que é opcional, pode ser usado para várias autenticações. Por exemplo, com o modo estendido, é possível realizar autenticações baseadas no computador e no usuário.
O suporte a várias autenticações faz parte da imposição de IPSec para a plataforma NAP (Proteção de Acesso à Rede), na qual protocolos IPSec de mesmo nível se autenticam com credenciais de computador e também usam um certificado de integridade para provar que são compatíveis com os requisitos de integridade do sistema. Para obter mais informações sobre a Proteção de Acesso à Rede, visite microsoft.com/nap. E para obter mais informações sobre os recursos de AuthIP, consulte "AuthIP in Windows Vista" em microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Mensagens de AuthIP
Tanto IKE quanto AuthIP usam ISAKMP como seu principal protocolo de troca e negociação SA. As mensagens de ISAKMP são enviadas pelo protocolo UDP (User Datagram Protocol) e consistem em um cabeçalho ISAKMP e em uma ou mais cargas ISAKMP. O cabeçalho ISAKMP contém informações sobre a mensagem, inclusive o tipo de mensagem. A Figura 1 mostra o formato do cabeçalho ISAKMP.
Figura 1 Formato do cabeçalho ISAKMP
Figura 1 Formato do cabeçalho ISAKMP
No cabeçalho ISAKMP, os cookies iniciador e respondente estão definidos como um número aleatório não nulo escolhido pelos protocolos IPSec de mesmo nível. O campo Próxima carga indica a primeira carga na mensagem ISAKMP, um pouco além do cabeçalho ISAKMP. O RFC 2408 lista os valores definidos do campo Próxima carga. Os tipos de carga entre 128 e 255 estão reservados para uso particular. Os campos Versão principal e Versão secundária indicam as versões de ISAKMP no protocolo IPSec de mesmo nível que envia a mensagem ISAKMP. Para IKE e AuthIP, a versão principal é 1 e a secundária, 0.
O campo Tipo de intercâmbio indica o tipo de troca ISAKMP que está sendo realizada. O tipo de troca estabelece a estrutura e a ordem das cargas ISAKMP. O RFC 2408 define os valores do campo Tipo de intercâmbio. Os tipos de intercâmbio entre 128 e 255 estão reservados para uso particular.
O campo Sinalizadores contém três sinalizadores definidos no RFC 2408. O bit de ordem inferior (bit 0) é Criptografia, o que indica que as cargas ISAKMP são criptografadas (quando definido como 1) ou não (quando definido como 0). A criptografia é feita com o algoritmo negociado para ISAKMP SA, o que é identificado pela combinação dos campos Cookie iniciador e Cookie respondente. O próximo bit de ordem inferior (Bit 1) é Confirmar, o que indica que a troca de chaves está sincronizada (quando definido como 1) ou não (quando definido como 0). O bit Confirmar é usado para garantir que a SA conclua a negociação antes do envio de dados criptografados. O próximo bit de ordem inferior (Bit 2) é Somente autenticação, usado para indicar que a mensagem contém (quando definido como 1) ou não (quando definido como 0) toda a carga Notificar do tipo de intercâmbio informativo e que ela foi autenticada, mas não criptografada.
O campo ID da mensagem contém um identificador exclusivo da mensagem. ID da mensagem é usado para impedir colisões quando ambos os protocolos IPSec de mesmo nível tentam estabelecer uma SA IPSec simultaneamente. O campo Tamanho indica o tamanho de toda a mensagem ISAKMP.
Para IKE, a mensagem ISAKMP contém uma série de cargas ISAKMP. A primeira carga é indicada pelo campo Próxima carga do cabeçalho ISAKMP. Todas as cargas ISAKMP têm seu próprio campo Próxima carga para indicar a carga seguinte. O campo Próxima carga na última carga está definido como 0. A Figura 2 mostra o formato das mensagens IKE.
Figura 2 Formato das mensagens IKE
Figura 2 Formato das mensagens IKE
AuthIP usa mensagens ISAKMP com os tipos de troca 243 (Modo principal), 244 (Modo rápido), 245 (Modo estendido) e 246 (Notificar) no campo Tipo de intercâmbio do cabeçalho ISAKMP. Uma diferença importante nas mensagens ISAKMP baseadas em AuthIP é que elas contêm apenas uma carga ISAKMP: Criptografia ou Notificar. A carga Criptografia contém as cargas incorporadas usadas na negociação em modo principal, modo rápido ou modo estendido. A carga Criptografia pode conter um conjunto de cargas criptografadas ou em texto sem formatação, dependendo do bit Criptografia no campo Sinalizadores do cabeçalho ISAKMP. A Figura 3 mostra o formato das mensagens AuthIP que contêm a carga Criptografia.
Figura 3 Formato das mensagens AuthIP que contêm a carga Criptografia
Figura 3 Formato das mensagens AuthIP que contêm a carga Criptografia

Coexistência entre AuthIP e IKE
O Windows Vista® e o Windows Server® 2008 dão suporte tanto a IKE quanto a AuthIP. No entanto, o Windows® XP e o Windows Server 2003, dão suporte apenas a IKE. Um protocolo IPSec inicial que dê suporte a AuthIP e IKE e que tenha uma diretiva de segurança da conexão que usa AuthIP e IKE deve determinar se o IPSec de resposta dá suporte a AuthIP e IKE. Em seguida, ele deve usar o protocolo mais apropriado à negociação da proteção de IPSec, dando preferência ao uso de AuthIP em relação a IKE.
Para determinar o protocolo de negociação do protocolo IPSec de mesmo nível de resposta, um IPSec de mesmo nível inicial que usa AuthIP e IKE envia as seguintes mensagens simultaneamente:
  • Mensagem 1 – uma mensagem AuthIP que inicia uma negociação no modo principal
  • Mensagem 2 – uma mensagem IKE que inicia uma negociação no modo principal
Caso o nó de resposta dê suporte a AuthIP, ele deve responder à Mensagem 1 com uma mensagem AuthIP de continuidade da negociação no modo principal e descartar silenciosamente a Mensagem 2. Um nó de resposta que não dê suporte a AuthIP descarta silenciosamente a Mensagem 1 porque o campo Tipo de intercâmbio contém um valor para o qual ele não dá suporte e responde à Mensagem 2.
Para impedir a negociação baseada em IKE entre dois protocolos IPSec de mesmo nível em execução no Windows Vista ou no Windows Server 2008 quando a Mensagem 1 é descartada da rede ou chega depois da Mensagem 2, os protocolos IPSec em execução no Windows Vista ou no Windows Server 2008 enviam a Mensagem 2 com uma carga ISAKMP do ID do fornecedor com suporte de AuthIP. A carga do ID do fornecedor com suporte de AuthIP indica que o protocolo IPSec de mesmo nível dá suporte a AuthIP.
Por isso, caso um protocolo IPSec de mesmo nível em execução no Windows Vista ou no Windows Server 2008 receba uma Mensagem 2 com a carga do ID do fornecedor com suporte de AuthIP, ele aguarda o protocolo IPSec de mesmo nível de inicialização para retransmitir as mensagens 1 e 2 e responde à Mensagem 1.
O protocolo IPSec de mesmo nível de inicialização continua retransmitindo as mensagens 1 e 2 até receber uma resposta ou expirar. Quando recebe uma resposta, o iniciador determina a capacidade do respondente a partir do cabeçalho ISAKMP da resposta. Caso o Tipo de intercâmbio esteja definido como 243 (o tipo de intercâmbio para negociação no modo principal baseada em AuthIP), o respondente é compatível com AuthIP. Caso o Tipo de intercâmbio esteja definido como 2 (o tipo de intercâmbio para Proteção de identidade e negociação no modo principal baseada em IKE), o respondente é compatível com IKE.
Com base na resposta, o iniciador responde com a próxima mensagem AuthIP para a negociação no modo principal AuthIP ou com a próxima mensagem IKE para a negociação no modo principal IKE. Os protocolos IPSec de mesmo nível usam o mesmo protocolo usado na negociação da SA ISAKMP durante o tempo de vida da SA.

Joseph Davies é redator técnico da Microsoft e autor da coluna online mensal da TechNet, The Cable Guy, em Microsoft.com/technet/community/columns/cableguy.


 Windows PowerShell: Trabalhando sem script
Windows PowerShell
Trabalhando sem script
Don Jones

Sempre que estou conversando com os colegas sobre o Windows PowerShell – seja em uma conferência, no grupo de notícias público Windows PowerShell ou mesmo no meu site –, encontro administradores que me dizem que "irão esperar" para aprender o Windows PowerShell. Por quê? A razão mais comum que eles apresentam é que
"não têm tempo para aprender como criar um script agora".
Trata-se de um sentimento comum. Nós, os administradores, formamos um grupo ocupado e realmente não temos muito tempo livre para aprender uma nova tecnologia. Mas temos que seguir em frente, aprendendo novos softwares como, por exemplo, o Windows Vista®, o Windows Server® 2008 e o Exchange Server 2007, para que possamos nos manter atualizados em relação às tecnologias essenciais para os nossos trabalhos. E o Windows PowerShell™ é parte importante dessas tecnologias.
Outra razão que eu costumo ouvir os administradores citarem para deixar de aprender a criar scripts no Windows PowerShell é que eles têm "medo de se tornar um programador", como disse um colega administrador. Bem, isso é algo no qual eu posso ajudá-lo. Você talvez se surpreenda ao saber que é possível fazer coisas verdadeiramente incríveis usando o Windows PowerShell, tudo isso sem escrever uma linha de código.

Preparando-se para pipeline
Eu já escrevi sobre a extrema flexibilidade e a eficiência do pipeline orientado a objeto usado pelo Windows PowerShell (mesmo que as palavras "orientado a objeto" possa fazer você suspeitar de que estou na direção da seara dos programadores, fique comigo). Uma das minhas coisas favoritas sobre o pipeline é como ele pode ser usado interativamente. Ele pode oferecer a você resultados instantâneos e permite que você os refine facilmente para poder obter exatamente o que deseja. Por exemplo, vamos supor que eu queira ter um inventário do espaço livre em disco destinado a vários computadores remotos. Agora digamos que os nomes dos computadores sejam listados em um arquivo de texto chamado C:\Computers.txt. Trata-se apenas de um arquivo de texto sem formatação com um nome de computador por linha – nada tão complicado quanto um banco de dados.
Para começar, verei se consigo recuperar essas informações do meu computador local. Afinal, se eu consigo descobri-las em um computador, realizar a tarefa em vários computadores deve ser bem fácil. E não se esqueça de que não há nenhum script envolvido aqui! Farei tudo interativamente no shell, obtendo os resultados assim que eu pressionar a tecla Enter.
Aqui está uma dica sobre esse tipo de tarefa. Sempre que quiser fazer um inventário das informações de gerenciamento dos computadores remotos, você provavelmente usará o WMI (Instrumentação de Gerenciamento do Windows®). Agora vamos supor que, para as finalidades desse exemplo, eu não saiba nada além de que preciso usar o WMI. Então, salto até o Live Search e digito "espaço livre em disco wmi windows" como meu termo de pesquisa. Vários resultados na lista apresentam a frase "Win32_LogicalDisk" em seus trechos. Para mim, isso parece uma classe do WMI e talvez seja a que eu estou procurando. Eu sequer me importo em clicar em algum desses resultados de pesquisa. Na verdade, digito "Win32_LogicalDisk" como novo termo de pesquisa e o resultado principal é de uma página de documentação Win32_LogicalDisk no site da MSDN® (msdn2.microsoft.com/aa394173.aspx). Dessa forma, acesso essa página e vejo se uma das propriedades da classe é FreeSpace, o que parece ser muito promissor.

Encontrando um Cmdlet
Na próxima etapa, preciso encontrar um cmdlet que recupere as propriedades de uma classe do WMI para mim. Um dos aspectos notáveis do Windows PowerShell é que ele conta com recursos de descoberta automática internos fantásticos – ou seja, o shell pode ajudá-lo a conhecer seus próprios recursos. Então, digito Help *wmi* para descobrir o que o shell sabe sobre o trabalho com o WMI. Os resultados, mostrados na Figura 1, são o alias Gwmi e o cmdlet para o qual ele aponta, Get-WMIObject. Basicamente, há duas formas de acessar a mesma funcionalidade, o que significa que eu não tenho que tomar uma decisão muito difícil sobre qual usar. Como elas fazem a mesma coisa e Gwmi é menor para digitar, eu usarei:
Figura 1 O que o shell sabe sobre o trabalho com o WMI
Figura 1 O que o shell sabe sobre o trabalho com o WMI
PS C:\> gwmi win32_logicaldisk
Observe que o Windows PowerShell não diferencia maiúsculas de minúsculas – ele sabe que nós, administradores, não temos tempo para detalhes como pressionar a tecla Shift.
Os resultados desse comando, mostrados na Figura 2, incluem todas as minhas cinco unidades locais e as propriedades FreeSpace, que aparecem listadas como bytes. Também está listada uma propriedade DriveType para cada uma dessas unidades, e estou vendo valores iguais a 2, 3 e 5 no meu computador.
Figura 2 Todas as minhas unidades locais e suas propriedades FreeSpace
Figura 2 Todas as minhas unidades locais e suas propriedades FreeSpace

Cmdlet do mês
Você talvez tenha usado Get-Content para ler o conteúdo de um arquivo de texto. Ele trata cada linha do arquivo como sendo um objeto [string], passando esses objetos pelo pipeline para que funcionem com outros cmdlets. Mas Get-Content tem várias opções que o tornam mais flexível: o parâmetro –readCount, por exemplo, permite que você especifique quantos objetos [string] são passados pelo pipeline de uma só vez (o padrão é enviá-los todos) e o parâmetro –totalCount controla o número total de linhas lidas do arquivo. Ambos os parâmetros são úteis no trabalho com arquivos realmente grandes, quando você talvez queira processar todo o arquivo de uma só vez por motivos de desempenho.
Eis aqui outro que você achará útil. O parâmetro –encoding permite que vários tipos de codificação de arquivo sejam lidos corretamente, inclusive Unicode, ASCII, UTF7, UTF8 e muitos outros. Para ver uma lista completa dos tipos de codificação suportados, execute help gc (gc é um alias de Get-Content).

Refinando os dados
Tenho dois problemas nesse ponto. Primeiro, não me importo com todas as demais propriedades; quero apenas FreeSpace. Segundo, não quero saber do espaço livre das unidades óticas, unidades removíveis ou de rede; estou preocupado apenas com os discos rígidos locais. Talvez essa propriedade DriveType possa me ajudar a diferenciá-los. Retorno ao meu navegador da Web e vejo que a documentação contém uma tabela explicando o que os valores DriveType diferentes representam. Quero apenas os com DriveType igual a 3, o que indica que a unidade é um disco rígido local. Jamais tendo feito isso antes, eu optei por ver se o comando Gwmi pode fazer algum tipo de filtragem para mim. Executar Help Gwmi –full recupera os detalhes sobre como funciona o comando, incluindo vários exemplos. Encontrei um parâmetro que parece ser útil, –filter, e decidi tentar executá-lo:
gwmi win32_logicaldisk -filter "drivetype = 3"
E funcionou! Agora a minha lista de unidades contém apenas os discos fixos locais. O segundo problema foi resolvido; agora eu preciso resolver o primeiro – me livrar de todas as propriedades que não me preocupam.
Executo Get-Command para listar todos os cmdlets do Windows PowerShell e acabo recorrendo a Select-Object. A descrição diz que isso "selecionará as propriedades específicas de um objeto ou conjunto de objetos". Então, eu tentei isso:
gwmi win32_logicaldisk -filter "drivetype = 3" | select freespace
Orientando os resultados de Gwmi para Select (o alias de Select-Object), consigo exatamente a propriedade que quero. Opa! Esses resultados não são tão bons, uma vez que tudo o que tenho é uma lista de números – não preciso mais saber qual unidade está relacionada a que lista de espaço livre. Então, volto à documentação e vejo que a propriedade DeviceID contém a letra da unidade. Reviso rapidamente o meu comando e tento novamente:
gwmi win32_logicaldisk -filter "drivetype = 3" | select deviceid,freespace
Perfeito! E como apenas duas propriedades estão sendo listadas, o shell é capaz de colocar as informações em uma tabela de aparência agradável (no mês que vem, eu explicarei quando o Windows PowerShell opta por usar listas e tabelas).

Calculando
Eu recuperei as informações sobre o espaço livre, mas elas estão em bytes, e isso não ajuda tanto quanto se elas fossem em megabytes ou em gigabytes. Talvez eu não queira exatamente a propriedade FreeSpace, e sim um valor calculado a partir dela. O cmdlet ForEach-Object (ou um de seus muitos aliases como, por exemplo, %) pode ajudar nisso. Esse cmdlet me permite usar uma variável especial, $_, para fazer referência ao disco lógico atual e acessar as propriedades de cada disco individualmente e fazer algumas contas. Aqui é possível ver o meu comando revisado:
gwmi win32_logicaldisk -filter "drivetype = 3" | % { $_.deviceid; $_.freespace/1GB }
Tudo o que fiz aqui foi remover Select e substituí-lo pelo alias de ForEach-Object (%). Esse cmdlet apenas quer que eu o informe o que fazer com cada Win32_LogicalDisk obtido e eu já disse para ele obter a propriedade DeviceID e dividir a propriedade FreeSpace por um gigabyte – o Windows PowerShell "sabe" o que são KB, MB e GB – para que a minha saída seja informada em gigabytes.

Muitos computadores
Agora que isso está funcionando para um computador, é hora de fazê-lo funcionar para vários sistemas. Eu sei como obter o conteúdo de um arquivo de texto. Isso é feito da mesma forma como fazíamos no tempo do MS-DOS® – usando o comando Type, que, no Windows PowerShell, se transforma em um alias de Get-Content:
Type c:\computers.txt
O que eu quero fazer é pegar cada um desses computadores e, para cada um deles, executar o comando do WMI no qual eu já trabalhei. A frase "para cada um deles" deve fazê-lo se lembrar de um cmdlet – mais especificamente, ForEach-Object. Então, vamos ao grande truque, como dizem naqueles programas de televisão, e vejamos o meu comando final:
type c:\computers.txt | % { $_;
gwmi –computername $_ win32_logicaldisk -filter "drivetype=3" | % { $_.deviceid; $_.freespace/1GB} }
Assustador, não é? Graças ao meu uso exclusivo de aliases, e não aos nomes de cmdlet, é difícil de ler. No entanto, é bem fácil decifrar se você acompanhá-lo bit a bit:
  • Começo "digitando" o conteúdo do meu arquivo de texto.
  • Oriento o conteúdo para ForEach-Object.
  • ForEach-Object produz o item atual, usando a variável $_. (Esse é o nome do computador atual.)
  • Em seguida, ForEach-Object executa o meu comando do WMI, que tem outra chamada ForEach-Object.
Expandir os nomes de alias em nomes de cmdlet pode ajudar. Aqui está o mesmo comando, mas desta vez eu escrevi os cmdlets e separei o comando em linhas individuais para que você possa examinar cada seção com mais facilidade:
Get-Content C:\Computers.txt |
ForEach-Object {
 $_; Get-WMIObject –computername $_
Win32_LogicalDisk -filter "DriveType=3" |
 ForEach-Object {
 $_.DeviceID; $_.FreeSpace/1GB
 }
}
Os resultados – que não são muito atrativos, embora sejam funcionais – são mostrados na Figura 3.
Figura 3 Os resultados finais
Figura 3 Os resultados finais

Nenhum script necessário
A idéia desse acompanhamento é demonstrar que é possível usar o Windows PowerShell sem criar nenhum script. E, com apenas alguns exemplos como esse, além de explorar um pouco mais o próprio Windows PowerShell, é possível encontrar alguns dos bits necessários para a realização de qualquer tarefa à qual você tenha se proposto a fazer.
A idéia final é de que o Windows PowerShell veio para ficar. E por que não aprender a usá-lo agora mesmo? Você pode até mesmo se perguntar como viveu tanto tempo sem ele – e certamente não deixará que a palavra script o afaste de você.

Don Jones é o maior especialista em scripts da SAPIEN Technologies e instrutor do ScriptingTraining.com. Entre em contato com Don através do seu site, ScriptingAnswers.com.


 Ei, Equipe de Scripts!: Que venha o Silverlight
Ei, Equipe de Scripts!
Que venha o Silverlight
A Equipe de Scripts da Microsoft
Faça download do código deste artigo: HeyScriptingGuy2007_10.exe (156KB)

A história humana tem sido marcada há muito pela colisão de forças diametralmente opostas: os romanos contra as hordas bárbaras; os Hatfields contra os McCoys; a Equipe de Scripts contra os que acreditam que uma coluna sobre scripts para administração de sistemas deva, na realidade, abordar scripts para administração de sistemas, e não, digamos, o confronto histórico de forças diametralmente opostas. [Ou, digamos, apontar uma arma... —Ed.]
O mundo dos computadores não está imune a confrontos entre essas forças. Em especial, temos a lembrança do confronto entre desenvolvedores e administradores do sistema. Como disse Karl Marx ao pesquisar a situação, "Ou este homem está morto ou meu relógio parou".
Espere, desculpe – na verdade, quem disse isso foi Groucho Marx. Karl Marx disse: "sempre e em toda parte, a arte é a confissão secreta e o movimento imortal de sua época". Para falar a verdade, não temos a menor idéia do que isso significa. Além disso, Groucho Marx era bem mais engraçado do que Karl Marx, mesmo que as brincadeiras de Groucho não sejam especialmente relevantes para o confronto entre desenvolvedores e administradores do sistema.
No entanto, temos a mais absoluta certeza de que era Karl Marx quem costumava fazer a Equipe de Scripts recitar o juramento de lealdade à automação todas as manhãs antes do trabalho: "administradores do sistema não são desenvolvedores". E isso é realmente verdade: os administradores do sistema não eram desenvolvedores. Os desenvolvedores eram pessoas que escreviam programas de computador, e os administradores do sistema eram as pessoas que... bem, para falar a verdade, não temos certeza se alguém na Microsoft realmente sabia o que os administradores de sistema faziam. Mas, seja lá o que fosse, certamente não era escrever programas de computador.
É claro que Karl Marx também chegou a compor aquela canção "The Times, They Are A-Changing" (Ou pelo menos foi isso o que ele nos disse).
Graças, em parte, ao Script Center da TechNet (microsoft.com/technet/scriptcenter), os administradores do sistema descobriram aos poucos o VBScript e começaram a escrever seus próprios utilitários que, embora não sejam tão completos e abrangentes quanto os programas de computador típicos, mesmo assim desempenham tarefas de gerenciamento bastante úteis. Ao escrever esses utilitários, os administradores de sistema tinham que contar com habilidades muito semelhantes às usadas pelos desenvolvedores.
E ainda não chegamos à metade da história. O advento do Windows PowerShell™ (microsoft.com/technet/scriptcenter/hubs/msh.mspx) significa que o Microsoft® .NET Framework deixa de ser o limite para administradores de sistema e redatores de scripts. O Windows Vista® apresentou ao mundo os gadgets (microsoft.com/technet/scriptcenter/topics/vista/gadgets-pt1.mspx), o que coloca administradores de sistema – ou, pelo menos, os que escrevem scripts – em pé de igualdade com os desenvolvedores. E agora – que rufem os tambores, por favor – há o Microsoft Silverlight, o "plug-in entre navegadores e plataformas que oferece a próxima geração de experiências em mídia baseadas no .NET Framework e aplicativos com interatividade avançada para a Web".
Parece impressionante, não? Mas, você pergunta, o que isso tem a ver com redatores de script para administração de sistemas como você? Sinceramente, não temos certeza. No entanto, o Silverlight simplifica muito a criação de interfaces de usuário legais e de apresentações multimídia. E como o material de marketing invariavelmente se refere ao Silverlight como uma forma de criar aplicativos Web, aqui está um fato pouco conhecido: o Silverlight parece funcionar igualmente bem em aplicativos HTML ou HTAs (microsoft.com/technet/scriptcenter/hubs/htas.mspx), um meio tão amado pelos redatores de scripts. Portanto, talvez possa valer a pena dar uma chance ao Silverlight.

Antes de continuarmos...
Devemos ressaltar que não abordaremos os muitos recursos e usos em potencial do Silverlight atualmente; a nossa meta principal é mostrar trechos de código o suficiente para que você experimente a tecnologia. Se você quiser instalar o Silverlight (ele é gratuito, aliás), visite a home page do Silverlight em microsoft.com/silverlight. Também é possível encontrar SDKs, projetos de exemplo e muitas outras coisas bastante úteis em silverlight.net/GetStarted.
Por enquanto, iremos supor que você já tenha instalado o Silverlight. Além disso, iremos pressupor que você já tenha acessado a seção Downloads de Código do site da TechNet Magazine (technetmagazine.com/code07.aspx) e baixado os arquivos descritos na Figura 1.
Figure 1 Componentes de projeto do Silverlight (Close Figure 1)

Arquivo | Descrição
CreateSilverlight.js | Este é um script JScript (em sua versão inicial, o Silverlight só dá suporte a scripts JScript) usado para especificar as configurações iniciais do Silverlight, inclusive o arquivo XAML para configurar a interface do usuário e os objetos gráficos.
SampleProject.js | Este é apenas um arquivo em branco no qual é possível agregar funções JScript.
Silverlight.js | O arquivo é usado para inicializar o controle Silverlight.
SampleProject.html | É onde ocorre toda a diversão. SampleProject.html é apenas um arquivo HTML que inclui códigos para a leitura em três arquivos .js. Ele também inclui um código para criar instâncias do controle Silverlight.
SampleProject.xaml | E para que serve isso? Para saber, você precisará voltar ao texto principal desta coluna.
Você não necessariamente precisa de SampleProject.js, pelo menos não para acompanhar a coluna deste mês. O Silverlight permite que você anexe scripts a objetos e eventos no projeto; esses scripts podem ser codificados no arquivo HTML ou (como nesse caso) lidos de um arquivo de "inclusão" externo como esse. Além disso, iremos transformar SampleProject.html em um HTA: basta renomeá-lo para SampleProject.hta. Fácil, certo?
Não se esqueça de salvar todos esses arquivos em uma pasta. E prepare-se para um pouco de diversão.

O arquivo XAML
Como você deve ter adivinhado, toda a empolgação na Ei, Equipe de Scripts! deste mês está relacionada ao arquivo XAML. (Por acaso, XAML pronuncia-se "zamel", o que rima com camel, ou camelo. Ou mammal, mamífero. Ou mesmo enamel, esmalte.) XAML é a abreviação de Extensible Application Markup Language. Dentre outras coisas, XAML oferece uma forma de criar interfaces de usuário com uma linguagem semelhante a XML. Isso facilita para que alguém – especialmente um administrador do sistema – crie interfaces de usuário? Você está prestes a descobrir.
Para começar essa jornada, abra o Bloco de notas e abra o arquivo SampleProject.xaml. Caso você veja algum código existente, substitua-o pelo seguinte:
<Canvas
 xmlns="http://schemas.microsoft.com/
    client/2007"
 xmlns:x="http://schemas.microsoft.com/
    winfx/2006/xaml">
</Canvas>
Observação: SampleProject.hta já está pré-configurado para carregar informações de SampleProject.xaml. Para usar um arquivo XAML diferente, você precisa editar o arquivo CreateSilverlight.js.
Depois de colá-lo no código, salve o arquivo e clique duas vezes em SampleProject.hta. E o que você verá? É isso mesmo: uma grande e inútil caixa cinza.
Mas espere, não vá ainda! É exatamente isso o que você deve ver.
Não há muito o que ver simplesmente porque não fizemos nada ainda: tudo o que fizemos até agora foi adicionar uma tela ao arquivo XAML. Mas essa é uma etapa importante. Afinal, caso queira tentar pintar um quadro a óleo, a primeira coisa de que você precisa é encontrar uma tela. Acontece a mesma coisa com o Silverlight: para que possamos começar a adicionar elementos ao nosso projeto, precisamos primeiro de uma tela para "pintar". E agora temos uma.
E por que, curiosamente, obtivemos uma caixa cinza com 300 pixels de largura por 300 pixels de altura? É simples: essas são as especificações encontradas, por padrão, no arquivo CreateSilverlight.js. Caso você não goste desses valores padrão, basta abrir CreateSilverlight.js e ajustar as configurações conforme o necessário. Você prefere uma tela com 800 pixels de largura por 300 pixels de altura? (Dentre os exemplos que usamos, qual você prefere). Em seguida, basta verificar se há estas três linhas em CreateSilverlight.js:
width:'800', // Width of rectangular region of
             // control in pixels.
height:'300', // Height of rectangular region
              // of control in pixels.
background:'white', // Background color of
                    // control.
Observação: Uma boa questão: no arquivo .js original, o plano de fundo está definido como #D6D6D6. Agora nós o definimos como branco. Na verdade, em um arquivo XAML, é possível usar valores RGB para representar cores ou usar nomes para representá-las. (Consulte msdn2.microsoft.com/bb188314.aspx para obter uma lista completa dos valores e dos nomes das cores). Como grande parte da Equipe de Scripts gosta de se referir às cores pelos valores RGB ("Minha casa? É FFFFFACD com corte em FFCD5C5C"), optamos por usar nomes de cores aqui.
Dica especial: você não está limitado a usar cores sólidas em um plano de fundo de tela. Cole o código da Figura 2 no arquivo XAML e veja o que acontece.
Figure 2 Cores legais (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
Você tentou? Muito legal, não?
É claro que uma tela totalmente preta não é muito interessante. Por isso, vamos avançar e adicionar um objeto à tela. Embora o Silverlight permita que você adicione todos os tipos de objetos (inclusive elipses, retângulos, linhas e polígonos), adicionaremos um bom bloco de texto da forma tradicional à nossa tela. Como? Inserindo as seguintes marcas entre as marcas <Canvas> e </Canvas> do nosso arquivo XAML:
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">
</TextBlock>
Como é possível ver, XAML não é, de fato, muito difícil. Começamos usando a marca <TextBlock>, verificando se incluímos os vários parâmetros TextBlock (como, por exemplo, Name e FontSize) na marca. Em seguida, indicamos que passamos pelo nosso TextBlock usando a marca </TextBlock>. O que há de legal nisso? Isso é bastante semelhante à forma como você adiciona qualquer objeto a um arquivo XML. Deseja adicionar um retângulo de 300 pixels de largura por 100 pixels de altura? OK:
<Rectangle
 Height="300"
 Width="100"
 Fill="Blue">
</Rectangle>
A propósito, ao adicionar uma forma (como, por exemplo, um retângulo) à tela, verifique se você especificou uma cor de preenchimento e/ou uma cor de traço. Se você não fizer isso, o Silverlight adicionará um retângulo transparente à tela. O retângulo estará lá, na verdade, mas você não conseguirá vê-lo a menos que tenha visão de raios-X como a do Super-homem.
Falando em cores de preenchimento e de traço, é por isso que você colore alguns objetos do Silverlight. Para os demais objetos, você precisa usar um pincel como, por exemplo, o LinearGradientBrush que mostramos (mas não abordamos) em nossa dica especial. Caso prefira pintar objetos com uma cor sólida, você pode usar apropriadamente SolidColorBrush. Por exemplo, observe a marcação XAML na Figura 3 que "pinta" o nosso texto (tecnicamente, ela pinta a propriedade Foreground de TextBlock) de vermelho.
Figure 3 Texto de pintura (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
Para obter um efeito ainda melhor, tente usar a propriedade ImageBrush, que preenche o texto com uma imagem:
<TextBlock.Foreground>
 <ImageBrush Name="test_brush" ImageSource="Sunset.jpg"/>
</TextBlock.Foreground>
Eis aqui uma outra dica: se tentar usar a propriedade ImageBrush, você certamente desejará aumentar o valor de FontSize porque quanto maior o texto, melhor o efeito.
Faça uma tentativa e veja o que acontece. Você ficará bastante impressionado.

Mas espere: você ainda não viu nada.
Temos de abordar com você: até agora mantive as coisas legais conosco. É legal que seja possível exibir texto no Silverlight; é ainda mais legal que você pode desenhar retângulos, elipses e polígonos. Mas tudo isso não significa nada em comparação com as animações que podem ser adicionadas a um projeto do Silverlight.
Novamente, tudo o que podemos fazer neste artigo é apresentá-lo a algumas das formas com as quais é possível criar a animação do Silverlight; nós apenas não temos espaço para ir além disso (Não nos culpe; continuamos sugerindo que a TechNet Magazine se torne a Ei, Equipe de Scripts! Magazine, mas aparentemente os nossos emails ainda não passaram por isso).
Sem mais a acrescentar, aqui está um efeito legal que faz com que haja fade in no nosso texto (mas certamente). Adicione o código à Figura 4 entre as marcas <TextBlock> e </TextBlock> do arquivo XAML.
Figure 4 Truques de TextBlock (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Com certeza, parece que há muito o que fazer aqui; felizmente, grande parte dela é apenas uma marcação padronizada. Para começar, não basta adicionar uma animação a um arquivo XAML; você precisa indicar quando ela deve ser executada. Isso exige que nós especifiquemos um conjunto de disparadores para TextBlock. Nesse caso, iremos criar um disparador que iniciará a animação sempre que TextBlock for carregado:
<EventTrigger RoutedEvent="TextBlock.Loaded">
No Silverlight, as animações devem acontecer em um storyboard (um termo emprestado da indústria dos filmes). É por isso que temos as marcas <BeginStoryboard> e <Storyboard>.
Para que haja o fade in do nosso texto, precisamos modificar a propriedade Opacity. Aumentaremos gradualmente o valor de 0,0 (transparente) para 1,0 (cor sólida). Como Opacity é uma propriedade Double (uma propriedade baseada em um valor numérico de precisão dupla), usamos uma animação DoubleAnimation. E como usamos uma animação DoubleAnimation? Por que, indicando o objeto que queremos animar (nesse caso, Test, o nome que demos a TextBlock); especificando a propriedade de destino (Opacity) e especificando o intervalo de animação (entre 0,0 e 1,0 de opacidade) e a duração de toda a animação (5 segundos). Em outras palavras:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
Observação: não se esqueça de usar a sintaxe 0:0:5 (horas, minutos, segundos) para indicar 5 segundos. Usar o valor 5 sozinho não gera erro, mas fará com que a animação demore 5 dias para ser concluída.
Você fez isso? Agora experimente isto: na marca DoubleAnimation, defina a propriedade AutoReverse como True:
AutoReverse="True"
Haverá fade in e fade out na animação.
Defina a propriedade RepeatBehavior como Forever, e continuará havendo fade in e fade out no texto, bem, para sempre:
RepeatBehavior="Forever"
Para sempre é muito? Em seguida, defina RepeatBehavior como, digamos, 3x, para que a animação seja executada 3 vezes e saia em seguida.
RepeatBehavior="3x"
Isso é bem legal, caso nos propusermos a isso. No entanto, e se você não gostar que haja fade in e fade out no texto; e se você quiser que o texto mude de cor gradualmente? Bem, aí você deverá usar uma animação ColorAnimation:
<ColorAnimation
 Storyboard.TargetName="test_brush"
 Storyboard.TargetProperty="Color"
 From="Red" To="Blue" Duration="0:0:5" />
Observação: apenas não se esqueça de começar com o texto vermelho caso você tenha escolhido essa cor. Lembre-se de que nós já mostramos como pintar o texto de vermelho.
Foi legal, não foi? E mesmo assim, você parece um pouco desapontado. Ah, é por isso: ColorAnimation foi legal, mas, na verdade, você estava esperando que as coisas saíssem voando pela tela. Ei, não fique triste; que tipo de software seria o Silverlight se não deixasse as coisas voarem pela tela? Experimente isto:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Left)"
 To="150"
 Duration="0:0:5" />
Como pode ver, estamos fazendo com que o TextBlock mova-se lentamente de sua posição inicial para um destaque 150 pixels à esquerda da borda da tela (Canvas.Left). Se quisermos mover TextBlock para cima e para baixo, basta usarmos a propriedade Canvas.Top:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Top)"
 To="150"
 Duration="0:0:5" />
Poderíamos – que os nossos corações palpitantes se tranqüilizem – combinar essas animações e fazer com que TextBlock se movesse de um lado para outro e de cima para baixo? Não faço a menor idéia. Mas eis uma dica: cole as combinações no arquivo XAML (um após o outro) e veja o que acontece.
Observação: está bem, mentimos — sabíamos desde o início que você poderia combinar essas animações. Na verdade, você poderia colocar várias animações em um único projeto do Silverlight. É um pouco confuso – você talvez tenha que incluir marcações adicionais para garantir que uma animação acabe antes do início da próxima. Mas isso também lhe permite fazer algumas animações bem legais apenas digitando algumas marcas como XML.

Desculpe, pessoal, mas o show acabou
Sim, já sabemos. Também detestamos ir embora, especialmente agora que acabamos de entrar na parte realmente boa. Mas não se preocupe; isso não precisa ser um adeus. Se você quiser saber mais sobre o Silverlight, nos escreva pelo email scripter@microsoft.com. Se houver interesse o suficiente, bem, nós veremos o que podemos fazer nas colunas futuras. Além disso, não deixe de visitar o Script Center da TechNet (microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx); postaremos links para exemplos de XAML (eXAMLs?) completos para você. Até lá, como disseram Karl Marx e Frederick Engels ao final do seu manifesto, Carta do Comitê de Correspondência Comunista de Bruxelas para G. A. Kottgen, "Boa noite, e vá com cuidado para casa".

A Equipe de Scripts da Microsoft 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: O BitLocker e a complexidade da confian&#231;a
Security Watch
O BitLocker e a complexidade da confiança
Justin Troutman

Windows Vista. Eu jamais escrevi essas duas palavras em um artigo, e é por isso que escrever esta coluna me faz sentir como uma criança de cinco anos com um cheque em branco entrando em uma loja de brinquedos. Há tantos recursos para abordar, tanto espaço que vale a pena explorar e tantos caminhos a serem tomados em uma abordagem.
Há pouco tempo, eu estava lendo o blog do guru da segurança Bruce Schneier e me deparei com uma entrada sobre algo que era totalmente novo para mim naquele momento – BitLocker™. Depreendi rapidamente que ele tinha o objetivo de fornecer funcionalidade criptográfica no Windows Vista® – tive a sensação imediata de "Ah não! O Windows Vista está criptografando? Isso não deve ser nada bom. E, mesmo que faça um trabalho decente, deve haver uma porta dos fundos em algum lugar".
Há alguns argumentos históricos (válidos ou não) relacionados aos motivos pelos quais alguém pode hesitar em confiar nos recursos de segurança integrados do Windows®. Mas não é por isso que estou escrevendo esta coluna. Na verdade, eu gostaria de relatar um caso detalhando por que eu acredito haver boas razões para dar uma chance ao BitLocker. Eu também quero apostar algumas moedas no tipo de filosofia que garante a vitalidade do software e do hardware de criptografia.
Mas não se confunda: não estou propondo que o BitLocker seja a solução completa para a segurança como um todo – o BitLocker é apenas mais uma das muitas peças que formam o quebra-cabeça da segurança. A sua meta é oferecer resiliência em determinados modelos de ameaça.
Em especial, o BitLocker volta suas atenções para o laptop perdido (ou roubado). Os trabalhadores móveis estão sempre transportando todos os tipos de informações confidenciais por todos os lugares – trens e aviões, restaurantes e hotéis, em casa e filiais. E eles estão levando essas informações em laptops e em outros dispositivos móveis que normalmente não têm nenhuma segurança real, o que deixa os dados que eles contêm extremamente vulneráveis. E o que acontece com esses dados quando um dos usuários deixa um laptop em algum lugar?
Não é possível eliminar a sordidez da natureza humana. Felizmente, você pode limitar o estrago que isso poderia causar. O custo para que uma empresa substitua um laptop é mínimo se comparado ao custo de lidar com dados confidenciais que tenham sido comprometidos. É essa a segurança que o BitLocker pretende oferecer.

Atravessando os créditos
Estou abordando o BitLocker aqui de uma perspectiva interessante. Veja, eu não tentei nada ainda. Eu sei o que você deve estar pensando: como um cara que sequer usou o BitLocker pode ter uma opinião a respeito e encontrar alguma coisa útil para escrever um artigo? Tenha paciência comigo. O que eu realmente quero abordar é a criptografia vista de um nível mais alto e as filosofias de design essenciais para que haja uma solução bem-sucedida.
Tudo isso começou com o que li no blog de Bruce Schneier. Digamos que você queira ver um novo filme nos cinemas. Com base no trailer e nos atores principais do elenco, você fez algumas suposições sobre a obra. Para falar a verdade, um bom elenco não significa um bom filme. Mas o elenco pode dizer muito a respeito do filme e o que você pode esperar dele. As estrelas são Chris Rock e Ben Stiller? Ou o filme é com Kate Winslet e Johnny Depp?
Da mesma forma, quando vi que um guru da segurança respeitado internacionalmente estava abordando o BitLocker em seu blog, eu fiz algumas suposições. Primeiro, eu pensei que essa nova tecnologia devia ser boa o bastante para merecer uma menção honrosa ou tão ruim que merecia receber destaque publicamente. E, para a minha surpresa, o veredicto final de Bruce Schneier era positivo.
Uma frase em especial me chamou a atenção em seu texto: "Não há nenhuma porta aberta para a polícia". A frase é de forte impacto. Ela foi dita com muita confiança e incluía um link para o blog da equipe da Microsoft® System Integrity. Segui o link e encontrei uma postagem de Niels Ferguson, desenvolvedor especializado em segurança na Microsoft, denunciando a existência de rumores de que a Microsoft tinha intencionalmente incluído portas abertas no BitLocker para fins legais. Ferguson dizia que portas abertas são inaceitáveis e que ele não participaria de nenhuma parte de um projeto que desse suporte a elas (Ele também explicou que, mesmo que a Microsoft fosse forçada a incluir uma porta aberta por lei, a empresa anunciaria a porta publicamente ou retiraria integralmente o recurso).
O nome na postagem – Niels Ferguson – explica a confiança de Schneier e também a minha. Ferguson é alguém que sabe o que está falando, e ele tem um histórico que garante que você pode confiar no que ele diz. Bruce Schneier e Niels Ferguson são co-autores de Practical Cryptography (Criptografia Prática), um livro de grande influência sobre a aplicação da boa criptografia, com uma abordagem simples, correta e segura) e co-designers da codificação de bloco, Twofish – uma rede Feistel de 128 bits que ganhou sua estrutura de análise criptográfica como finalista do processo de seleção AES (Advanced Encryption Standard).
É claro que ter um criptógrafo experiente em um projeto não é uma garantia de segurança do produto final. Às vezes, mesmo os mestres dessa arte podem cometer um ou dois erros. Mas independentemente de como o BitLocker evoluirá com o tempo, é possível pelo menos ter a certeza de que estratégias de design consistentes fizeram parte de sua criação.
Falando em erros, há tentativas legítimas feitas por desenvolvedores sem a mínima noção criptográfica e tentativas de má-fé feitas por aqueles mais preocupados apenas com o lançamento de um produto. Ambos os esforços, independentemente de suas intenções, são falhas de segurança na criação. No entanto, nenhuma parece ser o caso em relação ao BitLocker. Contar com pelo menos um criptógrafo competente envolvido e amplos recursos que apóiam essa iniciativa é um bom sinal.

Uma palavra sobre segurança
Não faz muito tempo que Phil Zimmerman, criador da criptografia PGP, compartilhou algumas regras gerais comigo. Se, em algum dia, fosse publicado o "Credo da segurança para desenvolvedores", suas orientações certamente figurariam no topo da lista. Embora suas opiniões não sejam específicas sobre o BitLocker, as filosofias de design que elas promovem podem ser aplicadas a praticamente qualquer solução criptográfica. Você talvez as ache óbvias e excessivamente zelosas. Mas, dado o estado atual da segurança, vale a pena explicá-las detalhadamente.
Ao projetar uma infra-estrutura criptográfica, o desenvolvedor deve ser simples, correto e seguro. Embora sejam inevitáveis, os erros não devem ser aceitos como algo natural e simplesmente ignorados. O desenvolvedor deve ser um entusiasta implacável de nada menos do que o mais meticuloso perfeccionismo. Como diz Zimmerman: "crie o projeto como se cometer um erro fosse custar a vida de alguém". Acha isso um exagero? Durante a Conferência Anual de Aplicativos de Segurança para Computador em 2005, o criptógrafo da NSA Brian Snow (já aposentado) disse: "eu queria funções e garantias em um dispositivo de segurança. Nós não fizemos o teste beta no cliente. Se o meu produto falhasse, alguém poderia morrer". Portanto, lembre-se: erros podem custar muito mais do que dinheiro.
Os usuários querem garantia. Obter – e manter – a confiança dos usuários é essencial. Zimmerman deixa isso bem claro quando diz: "Ganhe a confiança dos usuários. Uma vez colocado esse fardo em seus ombros, você jamais pode se desfazer dele". Ao fazer isso, a empresa preserva a garantia do usuário e sua própria reputação de segurança. Uma vez perdidas, elas podem ser irrecuperáveis.
Essas são as perspectivas que eu espero que a Microsoft tenha mantido em mente ao projetar o BitLocker (ou qualquer um dos demais produtos da empresa em relação a isso). Dito isso, quero explicar por que estou otimista que a Microsoft tenha efetivamente feito isso direito e ofereceu uma parte da tecnologia de criptografia que deve ser levada a sério.

Um pobre homem e seu elefante
Fundamentalmente, o BitLocker é a forma como o Windows Vista (mais especificamente, as edições Enterprise e Ultimate) criptografa todos os dados de volume do sistema. Isso pode parecer um aplicativo bem simples, mas considere as restrições. Como o BitLocker criptografa dados por nível de setor e o texto cifrado não pode exceder o tamanho do texto não criptografado, não há espaço para mais nada – como, por exemplo, nonce (um número ou cadeia de caracteres usada apenas uma vez na autenticação), IV (vetor de inicialização) ou MAC (Message Authentication Code). Eu presumo que essas restrições e as condições que elas impõem sejam semelhantes, embora também saiba que a autenticação de mensagens seria abordada de alguma forma.
O BitLocker conta com o que normalmente chamamos de autenticação do pobre homem. O comprometimento não é tão conservador quanto você normalmente gostaria que fosse, uma vez que ele pressupõe que o texto cifrado manipulado não resulte em um texto não criptografado significativo. Em outras palavras, caso seja manipulado, o texto cifrado deve, por exemplo, fazer com que o sistema falhe e não permita que um adversário realize alguma função.
A equipe da Microsoft responsável pelo BitLocker sabia que um bloco cifrado totalmente novo exigiria mais tempo para ser analisado do que o aceitável, mas os projetos existentes ainda não foram bem analisados o suficiente ou não eram suficientes o bastante. Portanto, para a criptografia, a Microsoft optou pelo AES no modo CBC (Cipher Block Chaining), ao qual eu irei me referir como AES-CBC. Isso é invisível sob o modelo de ataque de texto não criptografado escolhido (abreviado como IND-CPA), embora não mantenha a integridade. E como não há espaço para MAC, e CBC é um modo de confidencialidade, não há nenhuma preservação da integridade. Essa é a deixa para o elefante.
O novo componente Elefante tem dois difusores, criados para processar autenticações melhores do pobre homem do que AES-CBC simples (no entanto, eu devo fazer uma observação de que há uma opção para executar AES-CBC sem Elefante para os que precisam obedecer políticas rígidas de conformidade em relação aos padrões). Embora nem sempre seja ideal, a autenticação do pobre homem é a solução mais apropriada dadas essas restrições, e Elefante tem o objetivo de conseguir o melhor dessa situação. Como tudo isso funciona exatamente?
A Figura 1 ilustra o fluxo da compreensão. Quando ocorre a criptografia, o texto não criptografado é combinado, por meio de XOR, a uma chave de setor. Em seguida, o texto passa por dois difusores sem chave. Lá, o texto é criptografado usando AES-CBC. A chave de setor e AES-CBC exigem o material da chave e, por isso, são criptografados – de forma independente. Esse método simplifica a formalização de uma prova para reduzir a segurança de AES-CBC e da construção de Elefante do AES-CBC. Elefante é um novo primitivo, e novos primitivos podem ser encarados com relutância até serem analisados rigorosamente. Mas essa abordagem equilibra a escala, uma vez que o BitLocker pode mostrar que AES-CBC com Elefante não é mais de ser atacado do que o AES-CBC sozinho.
Figura 1 Autenticação do pobre homem com Elefante
Figura 1 Autenticação do pobre homem com Elefante
A chave de setor e os componentes de AES-CBC recebem 256 bits do material da chave, o que cria uma chave com 512 bits. Por padrão, porém, esses componentes usam apenas 128 bits do material de chave cada, o que significa que parte do material de chave não é usada. A razão disso é simplesmente porque é mais fácil ignorar os bits desnecessários do que alterar a infra-estrutura de gerenciamento da chave, já que as chaves podem variar de tamanho.
O tamanho do bloco pode ser uma combinação com dois, dentro da faixa entre 512 e 8192 bytes. Para garantir que todas as alterações feitas no texto cifrado resultem na modificação aleatória de todo o texto não criptografado de um setor, o bloco cifrado foi projetado para se comportar com um tamanho de bloco variável. Além disso, caso ele se comporte como um bloco cifrado ajustável (conforme descrição de Liskov, Rivest e Wagner), com o algoritmo mudando um pouco de setor para setor, um adversário não consegue mover um texto cifrado de um setor para outro.

Só o tempo dirá
Especular sobre a segurança criptográfica do BitLocker deixa de lado o aspecto mais importante. Para o BitLocker, ser seguro não é necessariamente suficiente para que ele faça seu trabalho. Isso porque ele não é uma solução em si – é apenas mais um dos muitos suplementos do Windows Vista. A Microsoft diz que o BitLocker está totalmente integrado ao Windows Vista. Mas, se há essa total integração com o sistema operacional, não é plausível que a falha de outro componente pudesse, por sua vez, causar uma falha ou comprometer o BitLocker?
Particularmente, eu acredito na modularidade e na falha isolada. A plena integração sem modularidade leva à complexidade. Tudo bem, talvez esse não seja o caso entre o Windows Vista e o BitLocker, mas apenas o tempo – e uma ampla análise – dirão se isso está certo.
E o que eu acho do BitLocker? Tiro o meu chapéu para a equipe da Microsoft System Integrity pela confiança depositada em criptógrafos confiáveis e verdadeiros, que fizeram as coisas como deveriam. É claro que esse recurso foi projetado para criptografia, e não para uma campanha de marketing. Então a minha resposta para essa pergunta é que o BitLocker deve ser levado a sério. Observe que isso deixa de lado o veredicto se a segurança é consistente. Mais uma vez, só o tempo e a avaliação do mundo real dirão. Muitos primitivos criptográficos e protocolos foram quebrados. Mas, na pior das hipóteses, a equipe da Microsoft System Integrity nos ofereceu informações e plataformas a partir das quais podemos criar soluções ainda melhores.

Justin Troutman é criptógrafo experiente e aluno universitário de matemática. Sua atenção está voltada principalmente para a criptografia simétrica. Ele também é fundador da Extorque, empresa especializada em pesquisa e consultoria em criptografia.


 Os arquivos da &#225;rea de trabalho: Guia avan&#231;ado para usu&#225;rios do WIM e do ImageX
Os arquivos da área de trabalho
Guia avançado para usuários do WIM e do ImageX
Wes Miller
Esta coluna se baseia em uma versão de pré-lançamento do WAIK (Kit de Instalação Automatizada do Windows) e do Windows Server 2008. Todas as informações aqui contidas estão sujeitas a alterações.

Em muitas das minhas colunas anteriores, abordei o ImageX e o formato WIM (Windows Imaging). Há alguns meses, na Tech•Ed, ouvi alguns comentários e dúvidas dos profissionais de TI que começavam a usar o WDS (Serviços de Implantação do Windows), o ImageX e o WAIK (Kit de Instalação Automatizada do Windows). Percebi que havia
necessidade de mais orientação para os usuários. Então, na coluna deste mês, eu gostaria de me concentrar no ImageX e no formato WIM, e em como obter o máximo deles. Juntos, o ImageX e o WIM permitem implantar facilmente o Windows Vista® e o Windows Server® 2008, e também o Windows® XP, o Windows Server 2003 e o Windows 2000.

Alterações no WAIK
Com a chegada da próxima versão do Windows Server 2008, você deve estar imaginando o que isso significa para o WAIK. A Microsoft planeja lançar uma versão atualizada do WAIK no mesmo período de lançamento do Windows Server 2008. Não há alterações significativas no formato WIM (a ferramenta ImageX e o formato permanecem inalterados); também não há mudanças no WDS para Windows Server 2003. Ao contrário dos rumores, o multicast não estará disponível no WDS para Windows Server 2003 — somente os servidores WDS executando Windows Server 2008 contarão com o novo recurso de implantação multicast para WDS.
O Windows PE 2.0 e a Instalação do Windows passarão por uma revisão para dar suporte aos seguintes recursos:
  • Implantação do Windows Server 2008 e do Windows Vista.
  • Implantação multicast via WDS a partir de um servidor WDS do Windows Server 2008.
  • Implantação de versões x64 e x86 do Windows Vista e do Windows Server 2008 a partir do Windows PE x86.
Em primeiro lugar, isso significa que o Windows PE 2.0 será capaz de implantar o Windows Server 2008 tão prontamente quanto implanta o Windows Vista, pois as mesmas ferramentas e processos funcionam para os dois. Em segundo lugar, quando seus servidores WDS estiverem executando o Windows Server 2008, você poderá utilizar a implantação multicast via WDS. Por fim, você poderá usar um disco Windows PE 2.0 x86 e, a partir dele, implantar uma imagem x86 ou x64 do Windows.
Mencionei esse último aspecto na Tech•Ed, na minha sessão sobre o Windows x64. Infelizmente, houve alguma confusão quanto a isso em blogs e na comunidade técnica do Windows. Isso não significa que a Microsoft distribuirá o Windows x64 e x86 em todos os DVDs do Windows Vista e do Windows Server 2008. Também não significa que você deve combinar imagens do Windows x64 e do Windows x86 em um único arquivo WIM (embora seja possível). Isso não gera a economia do armazenamento de instância única, embora permita transportar um só arquivo WIM.
Na verdade, significa que os clientes corporativos e os OEMs que dedicaram anos ao desenvolvimento de processos de implantação baseados em x86 (além de ferramentas e scripts personalizados) agora poderão implantar o Windows x86 ou x64 a partir do WIM usando a instalação de 32 bits — algo que os clientes corporativos vêm solicitando desde o lançamento do Windows x64, em 2005.

O ImageX no dia-a-dia
Usando /mount, /mountrw e /delete
Eis aqui algumas dicas importantes para usar as opções /mount, /mountrw e /delete com o ImageX:
  • Monte um volume com /mountrw se pretende editá-lo.
  • Você deve montar um WIM em um diretório vazio, eliminando a confusão com os arquivos possivelmente armazenados em um diretório já existente, e também para impedir que o ImageX emita uma mensagem de aviso desnecessária.
  • Não se esqueça de aplicar /unmount /commit à sua imagem de leitura/gravação se quiser salvar as alterações feitas. Muitas vezes, já fiz alterações e me esqueci de confirmá-las (e assim as perdi).
  • Excluir arquivos com /mountrw e excluir imagens de volume com /delete não serve para recuperar espaço. Na verdade, isso pode até mesmo consumir mais espaço. Para obter mais detalhes, consulte a seção desta coluna sobre /export.
  • Você só pode montar um único arquivo WIM uma vez para acesso de leitura/gravação. Dois usuários não podem editar o mesmo WIM de uma só vez e não é possível editar duas imagens de volume ao mesmo tempo.
  • Até mesmo no modo somente leitura (/mount), você deve limitar o número de imagens de volume montadas simultaneamente, pois o driver tem uma dependência em relação à quantidade de memória de pool não paginado do Windows disponível no seu sistema para cada imagem montada. Isso resulta em um limite que pode variar por sistema (ou por arquitetura de sistema). Não recomendo tentar montar simultaneamente mais do que cinco imagens.
  • Fazer edições significativas com /mountrw quase não demandará tempo no momento das alterações, mas poderá fazer com que /commit demande um tempo considerável, pois precisará compactar e armazenar todos os novos dados de arquivo.
  • Use /delete e /mountrw com cautela. Quando as alterações forem confirmadas, não poderão mais ser desfeitas.
  • Não é possível executar /delete com apenas uma imagem de volume em um arquivo WIM (em vez disso, exclua o arquivo WIM inteiro ou acrescente outra imagem de volume).
  • Para obter rapidamente uma árvore de diretórios com o conteúdo de uma imagem de volume, em vez de /mount, use este comando:
ImageX /dir <path_to_wim_file> <image index>
  • Se estiver editando dois arquivos WIM ao mesmo tempo, procure não aplicar /unmount a eles ao mesmo tempo; estabeleça uma seqüência para seus eventos de montagem/desmontagem, de forma que um não bloqueie o outro.

O ImageX foi criado especificamente para espelhar a forma como OEMs e clientes corporativos afirmam usar as ferramentas. A Figura 1 mostra o processo.
Figura 1 Usando o ImageX
Figura 1 Usando o ImageX
Convém destacar que a Etapa 5 é crítica pois, na realidade, uma imagem passa por alterações constantes. Assim, era preciso que a captura e a modificação da imagem fossem feitas com o máximo possível de rapidez e facilidade.
Por isso, é possível acrescentar uma imagem adicional (usando a opção /append) a uma imagem já criada. Inicialmente, a equipe de desenvolvimento imaginou que seria útil poder acrescentar mais um SKU (versão do Windows) à imagem anterior. No entanto, quanto mais eu trabalhava com clientes corporativos no estágio inicial do desenvolvimento do Windows Vista, mais ouvia falar que ele era usado para implantar X rapidamente, depois recapturar X1, onde havia sido feita uma das modificações da Etapa 2. Isso permitia recapturar a imagem com rapidez, pois apenas um número restrito de arquivos havia sido modificado.
Quando a equipe compreendeu isso, percebeu que talvez não fizesse sentido manter a imagem original em todas as situações. Mais adiante, nesta coluna, abordarei a opção /export, adicionada especificamente devido a esse cenário e ao que será apresentado em seguida.

Alterações constantes
Logo de início, a equipe de desenvolvimento decidiu que os arquivos WIM deveriam ser editáveis. Como já havia sido decidido que um formato de imagem baseado em setores não funcionaria (consulte a coluna de dezembro de 2006 em technetmagazine.com/issues/2006/12/DesktopFiles para ler uma explicação), era preciso criar uma solução capaz de montar facilmente os arquivos de forma nativa, como parte do sistema de arquivos do Windows, e de fazer alterações nas imagens de volume montadas no arquivo WIM. Isso representava mais algumas "partes móveis", como gosto de chamá-las. É relativamente fácil montar uma imagem baseada em setores. Contudo, montar um formato de arquivamento proprietário como o WIM exigiria algumas ferramentas bastante específicas.
O formato precisava de acesso a partir do prompt de comando, dispensando as extensões do Shell do Windows normalmente usadas para manipular arquivos ZIP e CAB de forma nativa. Infelizmente, esses manipuladores somente permitem ao Windows Explorer o acesso abstrato a um objeto.
Como resultado, a solução WIM envolve um driver (wimfltr.sys) e o ImageX, que funciona como método para carregar efetivamente o driver e lida com a interface de montagem do WIM. O driver serve para adicionar uma abstração ao sistema de arquivos do Windows, conforme mostrado na Figura 2. Ao executar um comando desse tipo, você solicita que o ImageX carregue o driver wimfltr.sys, de forma que o driver sobreponha a primeira imagem de volume (aquela presente nos comandos usados aqui) à montagem de diretório vazia, como você pode ver a seguir:
Figura 2 Montando uma imagem de volume WIM
Figura 2 Montando uma imagem de volume WIM
ImageX /mount iso\sources\boot.wim 1 mount
ImageX /mountrw iso\sources\boot.wim 1 mount
Esse é o comportamento padrão no WAIK. Assim, ao explorar ou gerar uma listagem de diretório no diretório de montagem, você vê a raiz da Imagem de volume 1 em boot.wim. É claro que usar /mountrw ou /mount determinará se o diretório será somente leitura ou leitura/gravação (consulte a barra lateral "Usando /mount, /mountrw e /delete" para obter mais detalhes).
O recurso /mountrw foi criado, a princípio, para adicionar facilmente drivers e outros arquivos ou conteúdos habilitados para xcopy, configurar arquivos de resposta ou modificar o registro offline de um arquivo WIM montado para alterá-lo conforme a necessidade (veja a Figura 3). Não foi criado para adicionar ou remover aplicativos inteiros (uma vez que aplicativos instalados com o MSI não podem ser instalados offline).
Figura 3 Modificando um arquivo WIM montado
Figura 3 Modificando um arquivo WIM montado
É fundamental entender que, ao fazer alterações no arquivo WIM montado, você não está alterando diretamente o verdadeiro arquivo WIM (pelo menos, não de imediato). Em vez disso, está alterando um cache do arquivo WIM que é, efetivamente, uma mesclagem da sobreposição e das alterações feitas por você. Como destaco na barra lateral, isso já me causou problemas. Quando terminar, não se esqueça de usar as opções /unmount e /commit, pois somente assim suas alterações serão confirmadas no arquivo WIM. Caso contrário, serão completamente perdidas.
Quando você salva suas alterações confirmando-as, está solicitando que o driver faça as alterações no arquivo WIM propriamente dito. O driver acrescenta os dados de arquivo adicionais (observe que, se você fez muitas alterações, isso significa que /commit poderá demorar um tempo considerável, pois somente com essa opção os dados de arquivo serão adicionados ao WIM).
Além disso, ao contrário de um formato de imagem baseado em setores, você pode ter alterado um ou mais arquivos na imagem de volume. Assim, não são mais arquivos de instância única (a não ser que o mesmo arquivo já tenha sido armazenado uma vez), o que resultará na perda dos dados de arquivo originais. O WIM, ao contrário de um volume NTFS ou FAT, não marca um arquivo como excluído. Deixa de fazer referência a ele, mas não o apaga. Então, se você fizer edições freqüentes com /mountrw, usar /append para adicionar muitas imagens ou usar /delete para excluir uma imagem de volume, isso somente fará com que o arquivo WIM perca as referências aos dados de arquivo. Os dados de arquivo relacionados não serão totalmente descartados.
Por isso, a equipe de desenvolvimento criou a opção /export, também conhecida, de certa forma, como "desfragmentador do WIM".

Exportação
Observações importantes sobre /export
Quando a opção /export é usada para criar um novo arquivo WIM, é possível especificar qual o tipo de compactação a ser usado, em vez de aceitar o tipo de compactação padrão usado no momento. Se você alterar o tipo de compactação atual, a exportação poderá levar um tempo considerável.
Quando usada, na verdade, como /append (para adicionar uma imagem de volume a um arquivo WIM já existente), a opção /export não permite modificar o atributo /compression do arquivo WIM.
Você poderá especificar a opção /boot se estiver exportando uma imagem de volume totalmente nova do Windows PE 2.0.

A opção /export foi criada em resposta aos dois cenários mencionados anteriormente, e também a alguns outros cenários mais complexos descobertos pela equipe. Em poucas palavras, /export permite exportar uma imagem de volume já existente (ou duas, ou três). Isso significa que é possível, usando os arquivos WIM X e X1 mencionados anteriormente, criar um novo WIM apenas com X, apenas com X1 ou com X1 e Y1, exportado de outro arquivo WIM.
Imagine um cenário onde você faça modificações em X e use /append para adicionar as alterações como X1. Você decide excluir X, pois essa imagem foi substituída por uma nova para o trimestre. Você pode usar a opção /delete e o ImageX perderá as referências à imagem X. Mas, se quiser economizar espaço eliminando todas as informações relacionadas a X, você precisará executar este comando:
ImageX /export source.wim 2 destination.wim "New image for Q4CY07"
Isso exportará a segunda imagem de volume para um novo arquivo WIM com o novo nome, eliminando completamente as informações anteriores da Imagem de volume 1. Também é possível exportar a partir de imagens WIM distribuídas, se você quiser remontá-las em um só arquivo WIM (assunto que abordarei mais adiante nesta coluna). As imagens distribuídas não podem ser editadas com /mountrw — um motivo pelo qual talvez você queira remontá-las. É importante observar que não existe comando /import para o ImageX, pois /export é capaz de criar novos arquivos WIM ou de fazer acréscimos aos já existentes. Consulte a barra lateral "Observações importantes sobre /export" para obter mais informações sobre o assunto.
Isso também é fundamental se você vai executar peimg /prep: embora esse comando prepare sua imagem do Windows PE para ser usada, não apaga nada no WIM. O ideal, como parte do seu processo de liberação do Windows PE, é que você prepare a imagem e a exporte para um novo arquivo boot.wim. Observe que o processo de inicialização somente procura pelo arquivo WIM em \sources\boot.wim. Por isso, verifique se ele foi nomeado corretamente e se está marcado como uma imagem de volume de inicialização.
Já mencionei que provavelmente você vai querer otimizar suas imagens executando /export nelas, quando for descomissionar imagens de volume antigas ou combinar várias. Você também vai querer fazer isso se tiver feito várias edições com /mountrw ou /delete. Caso contrário, seu arquivo WIM continuará a crescer com o passar do tempo (por motivos misteriosos que você não conseguirá diagnosticar). Se estiver usando regularmente /mountrw ou /delete, avalie a possibilidade de acrescentar /export ao seu fluxo de trabalho para garantir que as imagens sejam otimizadas ao máximo.

Distribuição
Outro problema que se apresentou, logo de início, foi a provável necessidade de que os arquivos WIM se ajustassem a várias mídias de CD ou DVD. Previmos que o Windows seria fornecido em mais de um CD (e possivelmente em DVD, como ocorreu) e, por isso, incorporamos o suporte à distribuição no WIM e no ImageX.
Como já mencionei, uma imagem distribuída criada com /split é basicamente somente leitura. Não é possível usar /capture para capturá-la diretamente em uma nova imagem distribuída, nem montá-la com o ImageX ou adicioná-la com /append. Por isso, recomendo que você só divida seu arquivo WIM quando tiver terminado o fluxo de trabalho padrão e estiver pronto para a liberação. Ou seja, faça todas as suas edições no arquivo WIM normal e considere a divisão como parte do processo de liberação para o cenário de implantação.
No que se refere à aplicação, as imagens distribuídas podem representar um desafio. Recomendo usar o ImageX em vez da instalação quando for trabalhar com imagens distribuídas. Recomendo também aplicar as imagens via rede (para obter um desempenho ideal sem ter de gerar uma imagem do disco a partir do qual está fazendo a aplicação) ou então copiá-las diretamente para a unidade e depois aplicá-las (mas observe que você ficará limitado ao disco, que estará lendo e gravando em si mesmo no momento da aplicação).

Em busca de validação
Quando você usa o ImageX, move uma grande quantidade de dados — e dados muito importantes. Uma pergunta que ouvi muitas vezes na Tech•Ed deste ano foi: "Como posso garantir que minhas imagens são válidas?". Bem, isso não é assim tão fácil, mas também não é tão difícil.
O fator mais importante a respeito do WIM que você precisa entender é que, assim como a maioria dos formatos de arquivamento, ele pode ser corrompido. Em geral, esse tipo de dano ocorre quando um arquivo WIM é transmitido via rede. Desde o início, com o Windows Vista, percebemos problemas específicos com placas de rede específicas — se elas descartavam pacotes, o arquivo WIM era corrompido, e nem sempre de uma forma fácil de diagnosticar. Essa situação, na verdade, refletia outra ocorrida anos antes, quando o arquivo driver.cab aumentou de tamanho. Isso produziu danos aleatórios semelhantes. Em geral, se você obtiver relatórios de imagens defeituosas ou falhas na instalação, convém verificar que tipos de NICs estão em uso nos sistemas que geraram esses relatórios. Isso vale para o uso apenas do ImageX ou executando o WDS.
Então, como é possível saber se uma imagem está ou não em bom estado? Em primeiro lugar, você pode usar a opção /check. Isso dispensa outras verificações de integridade no arquivo WIM e verifica, antes da aplicação, se o WIM não foi corrompido. Execute /check também no momento da aplicação, para validar a imagem (embora leve mais tempo).
Além disso, se você está tendo problemas — ou simplesmente quer ser meticuloso — pode executar um utilitário de hash nos arquivos antes da captura e após a aplicação. Também é possível fazer a verificação após a captura, montando a imagem e refazendo o hash — o que não é ruim como método para garantir a captura correta de uma imagem.
Você vai querer ter certeza de que suas imagens estão sendo capturadas corretamente desde o início. A opção /check e o formato em si foram projetados como pontos de verificação, e não como ferramentas de recuperação para reparar uma imagem capturada de forma incorreta.

Inicialização e sinalizadores
Já mencionei que é possível usar /boot para capturar uma imagem de volume WIM do Windows PE e inicializá-la. Você deve encarar isso simplesmente como um setor de inicialização em uma imagem de volume específica. Ele só pode existir em uma imagem de volume por WIM e só é válido para o Windows PE 2.0. Observe que você não pode inicializar o Windows PE 1.x via WIM, pois isso simplesmente não é possível.
Talvez você encontre referências a sinalizadores nas imagens de volume do Windows. Os sinalizadores são usados somente pela Instalação do Windows. Um sinalizador de 2 em uma imagem de volume significa que essa imagem contém o Windows PE e a instalação. Um sinalizador de 9 significa que contém apenas o Windows PE. Qualquer outro sinalizador ou a ausência dele significa que a imagem não pode e não será usada pela instalação. Observe que você pode definir sinalizadores em uma imagem depois que ela for capturada, usando o ImageX para modificá-la. Recomendo usar o WAIK (e, como opção, o Business Desktop Deployment Solution Accelerator) para criar sua imagem de inicialização do Windows PE via WIM, pois os sinalizadores serão definidos corretamente logo de início.

Uma observação para os usuários do HTA
Recentemente, ouvi vários relatos de usuários sobre problemas na execução de arquivos HTA no Windows PE 2.0. Infelizmente, parece haver um problema com os arquivos HTA contendo qualquer script significativo. Veja, na Figura 4, a captura de tela do exemplo de arquivo que criei, e observe o erro de script retornado. Esse problema foi relatado por vários clientes e eu mesmo o experimentei.
Figura 4 Erro de script do HTA
Figura 4 Erro de script do HTA
Felizmente, a correção é relativamente simples. Ao preparar sua imagem, adicione suporte a XML e também a HTA. A dependência ausente no componente de HTA parece estar incluída no módulo suplementar de XML, solucionando o problema.
Gostaria de agradecer a Bruce Green, desenvolvedor do ImageX, e a Minxiao Zhou e Raja Ganjikunta, da equipe de teste de implantação do Windows, pelo auxílio na preparação desta coluna.

Wes Miller é gerente de desenvolvimento da Pluck (www.pluck.com) em Austin, no Texas. Ele já trabalhou na Winternals Software, em Austin, e na Microsoft, como gerente de programas e gerente de produtos do Windows. Ele pode ser contatado pelo email technet@getwired.com.


 Anota&#231;&#245;es de campo: Recicle seu PC
Anotações de campo
Recicle seu PC
Jim Lynch

O programa Community MAR Microsoft Authorized Refurbisher (MAR) (microsoft.com/mar) é um projeto extraordinário e relativamente desconhecido de iniciativa da Microsoft Unlimited Potential, na qual a Microsoft apóia vários projetos para melhorar a educação, criar empresas e trabalho, além de gerar oportunidades econômicas sustentáveis para muitas comunidades necessitadas. Inaugurado no Reino Unido, em 2000, o programa Community MAR agora conta com mais de 800 PCs recondicionados em 50 países de todo o mundo.
Um dos aspectos mais interessantes do programa Community MAR é que ele é capaz de fornecer licenças para o Windows® 2000 e o Windows XP por apenas US$ 5. Os MARs fornecem essas licenças – mais de 200 mil por ano – em PCs recondicionados para organizações sem fins lucrativos, escolas, bibliotecas, faculdades e, nos EUA, programas de acesso à tecnologia para pessoas necessitadas e de baixa renda. Dessa forma, os Community MARs atingem aqueles que estão alijados do mundo digital, oferecendo acesso a oportunidades educacionais e de emprego.
Na tentativa de atingir crianças necessitadas, os Community MARs estão espalhados por todo o mundo. Por exemplo, a Operation Homelink fornece computadores a famílias de militares de baixa renda dos EUA; a Computer Aid International, do Reino Unido, é a maior organização não-governamental a fornecer computadores para a África, e a rede de recondicionadores Computers for Schools Canada fornece uma parte significativa dos computadores enviados para as escolas canadenses.
O valor da reutilização
A EPA (Environmental Protection Agency) dos EUA, em cooperação com a Universidade do Tennessee, demonstrou recentemente o valor da reutilização de componentes eletrônicos em termos de energia, de materiais e das emissões tóxicas de CO2. De acordo com a Electronics Environmental Benefits Calculator (eerc.ra.utk.edu/ccpct/eebc/eebc.html), a reutilização de um único computador com um monitor CRT poupa:
  • 13,60 kg de resíduos perigosos
  • 34,92 kg de resíduos sólidos
  • 34,92 kg de materiais
  • 66,67 l. (17,5 galões) de água não poluída
  • 32 toneladas de ar não poluídas
  • 604 kg de CO2 não emitidos
  • 7.719 quilowatts de energia

Na verdade, o programa Community MAR surgiu por volta do ano 2000 para ajudar a aumentar o fluxo de equipamentos de trabalho destinados a escolas e instituições de caridade do Reino Unido que, tradicionalmente, tem acesso limitado à tecnologia. O programa foi expandido até os EUA e a Austrália em 2003 e se tornou mundial em 2005. Agora ele está disponível a todos os tipos de recondicionadores (comerciais, não comerciais, governamentais e vinculados a escolas). Enquanto isso, ele também criou um setor vibrante de recondicionamento e reutilização de computadores.
Um dos benefícios menos óbvios do programa Community MAR é o ambiental. Ampliar a vida útil de equipamentos eletrônicos é a forma mais eficiente de reciclagem, por manter a função de um dispositivo no máximo e gerar os melhores resultados econômicos, ambientais e sociais. A reciclagem ao final da vida útil é, obviamente, boa e necessária, embora perca entre 10% e 30% dos materiais e da energia em um determinado item qualquer.
Não surpreende que a fabricação de computadores tenha um custo ambiental elevado. De acordo com o cientista especializado em meio ambiente, Eric D. Williams, da Universidade do Estado do Arizona, produzir um computador desktop de 24 quilos em média e um monitor exige 240 quilos de combustíveis fósseis, 22,67 quilos de produtos químicos e 1.510 litros de água. Ampliar a vida útil em dois ou três anos economiza de 5 a 20 vezes mais energia do que a reciclagem ao final da vida durante o ciclo de vida do computador (consulte a barra lateral "O valor da reutilização" para conhecer mais números surpreendentes).
De maneira geral, por meio desse programa inovador, a Microsoft ajuda a criar oportunidades capazes de transformar comunidades levando os benefícios da tecnologia até as pessoas necessitadas. Um benefício agregado surpreendente é que o programa Community MAR despertou a consciência pública e o apoio à reutilização dos computadores.

Jim Lynch é diretor do programa de reciclagem e reutilização de computador da TechSoup.org, uma empresa sem fins lucrativos com sede em San Francisco cuja missão é fornecer hardware de baixo custo, software e experiência a instituições de caridade de todo o mundo.


 Segredos do Windows: Chamando o Dr. Watson
Segredos do Windows
Chamando o Dr. Watson
Raymond Chen

Você talvez já tenha percebido que, caso peça ao Dr. Watson (drwtsn32.exe) para verificar um despejo de memória do processo Winlogon, o Windows® é desligado assim que é concluído. Algumas pessoas se perguntam: "por que conectar um depurador ao Winlogon desliga todo o sistema?".
Mas não é isso o que está acontecendo. Executar o Dr. Watson em um processo não é a mesma coisa que conectar um depurador a um processo. A conexão de um depurador envolve algo como ntsd – e isso não funciona, pressupondo que você tenha os privilégios necessários. Na verdade, é dessa forma que a equipe do Windows depura os problemas usando o Winlogon. Portanto, a resposta literal para essa pergunta é: "conectar um depurador ao Winlogon não desliga o sistema".
Mas o Dr. Watson é um praticante da medicina, e um generalista, primeiramente verificando um despejo de memória de um processo problemático e finalizando o processo em seguida. Como o Dr. Watson não tenta efetivamente corrigir o problema, se ele permitisse a continuidade da execução, esse processo não falharia novamente. E o doutor seria chamado de volta, criando um loop infinito. De certa forma, o Dr. Watson é um depurador que, na verdade, não realiza nenhuma depuração. O bom doutor apenas aparece, toma notas importantes e finaliza o processo. E é só isso – finalizar o Winlogon após o despejo de memória – que causa a falha no sistema.
Se você finalizar Winlogon, o sistema será reiniciado
Se você finalizar Winlogon, o sistema será reiniciado
O Winlogon é o que se chama de "processo de sistema crítico", e a eliminação de um processo crítico força a reinicialização do sistema. Por que o sistema considera o Winlogon crítico para seu funcionamento? Para os iniciantes, o Winlogon é responsável pelo processamento da seqüência segura – Ctrl+Alt+Del. Caso o Winlogon seja eliminado, a seqüência segura pára de funcionar. Isso é ruim por si só. O que piora as coisas é que, com a extinção do responsável da seqüência segura, outro programa só pode esperar que o usuário pressione Ctrl+Alt+Del e exibir uma caixa de diálogo de senha falsa em resposta. Não seria uma seqüência segura muito boa se ela pudesse ser falsificada! Como medida de precaução, o Windows se desliga antes que a situação inapropriada piore.
Agora, se você executar o Gerenciador de Tarefas, realçar um processo de sistema crítico como Winlogon, clicar em Finalizar Processo e confirmar, você acabou de finalizar Winlogon e o sistema será reiniciado (pressupondo, obviamente, que você esteja executando como um administrador privilegiado e que, por isso, tenha privilégios suficientes para finalizar o processo).
Em versões anteriores do Windows, o Gerenciador de Tarefas tentava impedir que você finalizasse esses processos de sistema crítico, embora seu algoritmo para decidir quais processos eram críticos não fosse muito inteligente. Se fosse suficientemente esperto, você poderia falsificar o Gerenciador de Tarefas e criar um programa que não pudesse ser finalizado. É claro que não era bem esse o caso. Ainda assim você poderia finalizar o programa – só teria que usar um programa que não fosse o Gerenciador de Tarefas para isso (por exemplo, você poderia tentar usar o programa taskkill).
Para evitar que seja falsificado, o Gerenciador de Tarefas simplesmente pára para impedir que você finalize processos de sistema críticos. Afinal, caso não faça nada, você não consegue fazer nada de errado. Isso significa que o Gerenciador de Tarefas não está mais protegendo você ao finalizar um processo. Ele não segurará mais a sua mão quando você tentar finalizar algo que deveria deixar quieto. Se optar por finalizar um processo de sistema crítico, você estará prestes a enfrentar as conseqüências.

Raymond Chen, The Old New Thing, e o livro homônimo (Addison-Wesley, 2007), tratam da história do Windows e da programação Win32. Ele deixa o trabalho de operacionalização de mecanismos para os outros.