 TechNet Magazine March 2008

TechNet Magazine March 2008

Cobertura especial: Windows Server 2008: Por dentro das alterações no kernel do Windows Server 2008

Mergulhe em um tour detalhado pelas principais alterações no kernel do Windows Server 2008 que melhoram a confiabilidade, o desempenho e a escalabilidade. Descubra como o Windows Server 2008 faz melhor uso de pools de threads, simplifica a recuperação de falhas de hardware, aprimora a virtualização com o Hyper-V e muito mais.

Mark Russinovich Cobertura especial: Windows Server 2008: Novidades no ADDS (Serviços de Domínio Active Directory)

O Windows Server 2008 introduz algumas melhorias substanciais nos Serviços de Domínio Active Directory. Examine de perto como os controladores de domínio somente leitura e o Windows Server Core aumentam a segurança do ambiente, como o novo Gerenciador de Servidores e o backup remodelado simplificam o gerenciamento e como as novas ferramentas de auditoria ajudam a garantir a conformidade.

Gil Kirkpatrick Cobertura especial: Windows Server 2008: Introdução ao IIS 7.0

O IIS 7.0 é fornecido com tantos novos recursos que é impossível incluir todos em um único artigo. A nova versão se baseia no design sólido e focado em segurança que já existia no IIS 6.0, fornecendo aprimoramentos que aumentam muito a gerenciabilidade e a extensibilidade da plataforma. Obtenha uma visão geral de algumas das alterações mais importantes no IIS 7.0.

Isaac Roybal Cobertura especial: Windows Server 2008: Acesso à rede orientado a diretivas com o Windows Server 2008

Como permitir o acesso à rede a quem dele precisa sem sacrificar a segurança? Veja de que modo as novas tecnologias do Windows Server 2008, como o Firewall do Windows com Segurança Avançada e Proteção de Acesso à Rede, permitem implementar uma abordagem baseada em diretivas para ajudá-lo a alcançar seu objetivo.

Ian Hameroff and Amith Krishnan Cobertura especial: Windows Server 2008: Configurando funções com o Gerenciador do Servidor

Um servidor DNS não precisa ser um servidor de impressão. Uma abordagem que o Windows Server 2008 adota para aumentar a segurança e a gerenciabilidade é simplificar as funções de servidor para que você possa instalar apenas as ferramentas e os serviços de que necessita – nada mais. Veja aqui uma introdução ao uso do Gerenciador do Servidor para configurar funções e simplificar implantações.

Byron Hynes Cobertura especial: Windows Server 2008: Implantando o Windows Server 2008 com o System Center

Os administradores de servidor costumavam instalar o Windows Server manualmente usando o CD ou DVD e depois passar várias horas configurando o servidor. Com o lançamento do System Center Configuration Manager 2007 e do novo Microsoft Deployment Toolkit, eles passam a poder usar as mesmas ferramentas que os administradores de desktop vêm utilizando há anos para automatizar implantações.

Tim Mintner Cobertura especial: Windows Server 2008: Auditoria e conformidade no Windows Server 2008

Os departamentos de TI passaram a ser responsáveis pela auditoria de alterações, que é fundamental na compreensão e no gerenciamento de sistemas e dados em um ambiente distribuído. Este artigo aborda desafios comuns, o panorama de conformidade e regulamentação, algumas noções básicas de auditoria e como criar uma estratégia de auditoria abrangente.

Rob Campbell and Joel Yoker Do editor: Que venha o Windows Server 2008

Joshua Hoffman Cartas: A palavra está com os leitores

Caixa de ferramentas: Novos produtos para profissionais de TI

Greg Steen Utilitário em destaque: Certificação do logotipo Windows Server

Para ajudar os ISVs e clientes a avaliar a compatibilidade de aplicativos, a Microsoft criou o programa "Works with Windows Server 2008". Veja quais são as ferramentas gratuitas de teste de suporte disponibilizadas por meio do programa que podem ajudá-lo a garantir que os aplicativos forneçam uma experiência previsível.

Venkat Krishnamachari The Cable Guy: Migrando sua intranet para IPv6 com o ISATAP

Preparando-se para migrar para IPv6? O Cable Guy explica como você pode usar uma tecnologia de transição de IPv6 para obter conectividade IPv6 e migrar para uma intranet com suporte a IPv6.

Joseph Davies Windows PowerShell: Relatório de andamento

Para seus usuários que têm problemas de falta de atenção – e mesmo para os que não têm –, é uma boa idéia fornecer comentários de status nos seus scripts. A seguir, apresento tudo que você precisa saber para fornecer status no Windows PowerShell.

Don Jones Ei, Equipe de Scripts!: Nossos jogos do shell favoritos

A Equipe de Scripts demonstra como você pode alterar a data da última modificação de um arquivo com script e objeto Shell.

The Microsoft Scripting Guys Security Watch: Usando o ACS no Windows Server 2008

Você já ouviu falar sobre o Gerenciador de Servidores, a nova ferramenta do Windows Server 2008. Porém, o ACS (Assistente de Configuração de Segurança) continua disponível também. Descubra por que você ainda vai querer usar o ACS.

Jesper M. Johansson Os arquivos da área de trabalho: Nem tanto nem tão pouco

Clientes finos vêm e vão, mas sempre parece haver algum cenário que pode se beneficiar deles. Atualmente, eles são usados em quiosques e em ambientes nos quais a navegação na Web é tudo de que se necessita. Veja como você pode remodelar o antigo hardware com um aplicativo cliente para fins de economia.

Wes Miller Anotações de campo: Preparação para o IT 2.0

Veja a importância do aprendizado de experiências anteriores para solucionar os desafios que o futuro reserva para o setor de TI.

Romi Mahajan Segredos do Windows: Como os betas se tornam RCs

Raymond Chen aborda a intrigante história de bastidores da mudança nas convenções de nomenclatura para versões de pré-lançamento. Além disso, ele faz um apelo para que as empresas levem mais a sério os testes beta.

Raymond Chen


 Cobertura especial: Windows Server 2008: Por dentro das altera&#231;&#245;es no kernel do Windows Server 2008
Cobertura especial: Windows Server 2008 Mark Russinovich

Por dentro das alterações no kernel do Windows Server 2008
Visão geral:
  • Gerenciamento de memória e o SMB 2.0
  • Auto-recuperação do NTFS, Arquitetura de Erro de Hardware do Windows e o verificador de driver
  • Escalabilidade com portas de conclusão de E/S, pools de threads e NUMA
  • Virtualização com o Hyper-V

O Windows Server 2008 é a versão mais recente da plataforma de servidores da Microsoft e inclui alterações no nível do sistema que abrangem toda e qualquer área funcional do sistema operacional, de gerenciamento de memória
a agendamento de threads, de sistema de redes a segurança, só para citar alguns.
Como o Windows Server® 2008 compartilha o kernel com o Windows Vista® SP1, ele possui muitos dos aprimoramentos que abordei em meus artigos anteriores da TechNet Magazine: "Dentro do kernel do Windows Vista", partes 1 a 3 (fevereiro, março e abril de 2007) e "Por dentro do UAC (Controle de Conta de Usuário) do Windows Vista" (junho de 2007). Apenas uma minoria dos recursos descritos nesses artigos são exclusivamente focados no cliente e não estão incluídos no Windows Server 2008, como SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot e o MMCSS (Serviço Agendador de Classes de Multimídia).
Em vez de repetir a cobertura das importantes alterações no kernel introduzidas no Windows Vista que também estão no Windows Server 2008 (como priorização de E/S, a nova arquitetura de inicialização, BitLockerTM, integridade do código e níveis de integridade obrigatórios), vou me concentrar nas principais alterações que não abordei nesses artigos, como as relacionadas a confiabilidade, desempenho e escalabilidade, além da nova tecnologia de virtualização de computadores com hipervisor, o Hyper-VTM.
Além disso, assim como nos anteriores, o escopo deste artigo está restrito ao kernel do sistema operacional, Ntoskrnl.exe, e aos componentes do sistema estreitamente relacionados a ele. Ele não aborda alterações na instalação (Serviço Baseado em Componente e WIM – Windows® Imaging Format), no gerenciamento (aprimoramentos na Diretiva de Grupo e no Active Directory®), no monitoramento e diagnóstico geral (Infra-estrutura de Diagnóstico do Windows), no sistema de rede básico (implementação de TCP/IP e o novo firewall), no Núcleo do Servidor ou nas Funções do Servidor, por exemplo.
Trabalhando em sistemas multiprocessadores
Uma das alterações de baixo nível no sistema é que o Windows Server 2008 só inclui uma versão do kernel projetada para trabalhar em sistemas multiprocessadores. Antigamente, o Windows usava uma versão específica para uniprocessadores em computadores com uma única CPU porque essa versão podia alcançar um desempenho ligeiramente melhor omitindo o código de sincronização necessário apenas em ambientes multiprocessadores. Como o hardware ficou mais rápido, o benefício das otimizações em termos de desempenho se tornou insignificante, e a maioria dos sistemas de servidor atuais inclui mais de um processador, tornando a versão com uniprocessador desnecessária.
A Figura 1 mostra as variantes do kernel do Windows Server 2008, em que a versão usada em um sistema dependerá dos seguintes fatos: se esta é a versão de depuração (verificada) ou comercial do sistema operacional, se a instalação é de 32 ou 64 bits (Itanium, Intel 64 ou AMD64) e, caso seja uma instalação de 32 bits, se o sistema tem mais de 4 GB de memória física ou é compatível com Prevenção de Execução de Dados (DEP). Espera-se que o Windows Server 2008 seja o último sistema operacional Windows Server a oferecer uma versão de 32 bits.
Figure 1 Variantes do kernel do Windows Server 2008 (Close Figure 1)

Kernel | 32 bits | 64 bits
Multiprocessador | Sim | Sim
Multiprocessador verificado | Sim | Sim
PAE (Extensões do Endereço Físico) do multiprocessador | Sim | Não
PAE do multiprocessador verificada | Sim | Não
Cada versão do Windows Server busca melhorar o desempenho dos principais cenários de servidor, como serviço de arquivos, E/S de rede e gerenciamento de memória. Além disso, o Windows Server 2008 tem várias alterações e recursos recentes que permitem que o Windows tire proveito das novas arquiteturas de hardware, se adapte a redes de alta latência e remova gargalos que restringiam o desempenho em suas versões anteriores. Esta seção analisa os aprimoramentos no gerenciador de memória, o sistema de E/S e a introdução de um novo sistema de arquivos de rede, o SMB 2.0.

Gerenciamento de memória
Experimento: ver grandes E/Ss de disco
Você pode usar uma ferramenta de monitoramento do sistema de arquivos como o Sysinternals Process Monitor da TechNet (technet.microsoft.com/sysinternals/bb896645.aspx) para procurar grandes operações de E/S de arquivos em um sistema Windows Server 2008.
Há várias formas de gerar grandes E/Ss. Se você tiver um segundo sistema com o Windows Vista Service Pack 1 ou o Windows Server 2008, poderá executar o Process Monitor no servidor e monitorar cópias de arquivos no segundo sistema. Normalmente, também é possível gerar grandes E/Ss de arquivo de paginação por meio da execução de um programa que demande muita memória e faça com que o gerenciador de memória grave páginas no arquivo de paginação.
A Figura A mostra o Process Monitor após a execução de um programa desse tipo em um sistema Windows XP, com a opção Enable Advanced Output (Habilitar Saída Avançada) marcada no menu Options (Opções) do Process Monitor e um filtro definido para só mostrar gravações no arquivo de paginação, pagefile.sys. A coluna Detalhe mostra que o tamanho das gravações é de 64 KB.
Figura A
Quando você executar as mesmas etapas no Windows Server 2008, provavelmente verá algo semelhante ao exibido na Figura B, que mostra a maioria das gravações com cerca de 1 MB de tamanho.
Figura B

O gerenciador de memória inclui várias melhorias de desempenho no Windows Server 2008. Por exemplo, ele emite E/Ss de disco maiores e em menor quantidade do que no Windows Server 2003 ao buscar dados no arquivo de paginação ou executar E/Ss read-ahead em arquivos mapeados. As E/Ss de arquivo maiores são facilitadas por alterações no sistema de E/S que remove o limite de tamanho de 64 KB presente desde a primeira versão do Windows NT®.
Também é importante observar que as leituras de dados para read-ahead (leituras especulativas) a partir de arquivos mapeados pelo Gerenciador de Cache normalmente têm o dobro do tamanho no Windows Server 2008 em relação ao Windows Server 2003 e vão direto para a lista de espera (o cache de dados e o código do sistema). Esse comportamento ocorre em lugar da solicitação para que o Gerenciador de Cache mapeie a memória virtual e leia os dados no conjunto de trabalho do Sistema (memória atribuída ao Sistema pelo gerenciador de memória), o que pode fazer com que outros dados ou códigos em uso sejam removidos desnecessariamente do conjunto de trabalho.
O gerenciador de memória também executa E/Ss maiores durante a gravação de dados no arquivo de paginação. Enquanto o Windows Server 2003 costumava executar gravações até menores do que 64 KB, o gerenciador de memória no Windows Server 2008 normalmente emite gravações de 1 MB.
Além de melhorar o desempenho diminuindo o número de gravações no arquivo de paginação, as gravações maiores também minimizam a fragmentação dentro desse arquivo. Por sua vez, isso provoca uma redução no número de leituras e buscas em disco necessárias para reler várias páginas, já que, na maioria das vezes, elas não estão adjacentes.
O gerenciador de memória também tenta gravar outras páginas modificadas que estejam próximas à que está sendo gravada no espaço de endereço do processo proprietário. O destino é a área do arquivo de paginação onde outras páginas vizinhas já residem. Isso minimiza a fragmentação e pode melhorar o desempenho porque as páginas que possam vir a ser gravadas no arquivo de paginação já foram gravadas. Além disso, reduz o número de leituras de paginação necessárias para obter um intervalo de páginas de processo adjacentes. Veja a barra lateral "Experimento: ver grandes E/Ss de disco" para obter mais informações sobre o uso de grandes E/Ss no Gerenciador de Memória.

SMB 2.0
O protocolo de sistema de arquivos remoto SMB, também conhecido como CIFS (Common Internet File System), tem sido a base do serviço de arquivos do Windows desde que essa funcionalidade foi introduzida no Windows. Nos últimos anos, as limitações de design do SMB restringiram o desempenho desse serviço e a capacidade de aproveitar os novos recursos do sistema de arquivos local. Por exemplo, o tamanho máximo de buffer que pode ser transmitido em uma única mensagem é cerca de 60 KB, e o SMB 1.0 não reconhecia links simbólicos do lado do cliente NTFS adicionados no Windows Vista e no Windows Server 2008.
O Windows Vista e o Windows Server 2008 introduziram o SMB 2.0, que é um novo protocolo de serviço de arquivos remoto utilizado pelo Windows quando há suporte tanto no cliente como no servidor. Além de processar corretamente os links simbólicos do lado do cliente e outros aprimoramentos no NTFS, o SMB 2.0 usa o envio em lote para diminuir o número de mensagens trocadas entre um cliente e um servidor. O envio em lote pode melhorar a taxa de transferência em redes de alta latência como WANs (redes de longa distância) porque permite que mais dados estejam em trânsito ao mesmo tempo.
Enquanto o SMB 1.0 emitia E/Ss referentes a um único arquivo seqüencialmente, o SMB 2.0 implementa pipelining de E/S, permitindo a emissão de várias E/Ss simultâneas para o mesmo arquivo. Ele mede a quantidade de memória de servidor usada por um cliente para que as E/Ss pendentes determinem o detalhamento do pipeline.
Devido a melhorias no mecanismo de cópia de arquivos e às alterações no gerenciador de memória de E/S do Windows, no sistema de E/S e no ajuste automático da janela de recebimento do TCP/IP, o SMB 2.0 permite aprimoramentos significativos na taxa de transferência e redução no tempo de cópia de arquivos para grandes transferências. Como os dois sistemas operacionais implementam o SMB 2.0, a implantação de servidores de arquivos do Windows Server 2008 com clientes Windows Vista possibilita o uso do SMB 2.0 e a realização desses benefícios no desempenho.

Confiabilidade com a auto-recuperação do NTFS
Confiabilidade é um atributo de servidor fundamental, e o Windows Server 2008 oferece vários aprimoramentos que ajudam os administradores a manter o servidor funcionando sem problemas, como o reparo de consistência do NTFS online, uma nova infra-estrutura de relatório de erros de hardware e extensões para o Verificador de Driver.
Com os dispositivos de armazenamento atuais de vários terabytes, colocar um volume offline para fazer uma verificação de consistência pode resultar em uma interrupção de muitas horas no serviço. Reconhecendo que muitas corrupções de disco estão localizadas em um único arquivo ou em uma parte dos metadados, o Windows Server 2008 implementa um novo recurso de auto-recuperação do NTFS para reparar danos enquanto um volume permanece online.
Quando o NTFS detecta a corrupção, ele impede o acesso ao(s) arquivo(s) danificado(s) e cria um thread de trabalho do sistema que executa correções parecidas com Chkdsk nas estruturas de dados corrompidas, permitindo acessar os arquivos reparados quando terminar. O acesso a outros arquivos continua normal durante essa operação, minimizando interrupções no serviço.

Infra-estrutura WHEA
A infra-estrutura WHEA (Arquitetura de Erro de Hardware do Windows) incluída no Windows Server 2008 promete simplificar o gerenciamento de falhas de hardware e permitir respostas pró-ativas a erros não-fatais. As garantias do tempo de atividade nos servidores costumam ser rígidas, por isso é fundamental identificar e responder a erros em tempo hábil nesse tipo de sistema.
A análise de panes enviada à Microsoft via OCA (Análise Online de Pane do Windows) mostra que, em termos gerais, 10% das panes no sistema operacional ocorrem em resposta a uma falha de hardware, mas tem sido difícil ou impossível determinar a causa principal delas, pois o hardware não fornece informações de erro suficientes para captura em uma pane. Além disso, antes do Windows Server 2008, o Windows não fornecia suporte interno para monitorar a integridade de dispositivos nem implementava correção ou notificação de falha iminente. O motivo é que os dispositivos de hardware não usam um formato de erro comum nem fornecem suporte a software de gerenciamento de erros.
A WHEA oferece um mecanismo unificado para descoberta e relatório de origens de erro referentes a dispositivos de plataforma, inclusive processadores, memória, caches e barramentos como PCI e PCI Express. Ela faz isso implementando a arquitetura mostrada na Figura 2, na qual o núcleo é uma API do kernel chamada pelas origens de erro para relatar erros. A API requer que todos os erros sejam formatados de modo comum e registra os erros em log usando eventos ETW (Rastreamento de Eventos para Windows). Os erros fatais são registrados em log após uma reinicialização.
Figura 2 Infra-estrutura de relatório de erros WHEA
Figura 2 Infra-estrutura de relatório de erros WHEA
O ETW foi introduzido no Windows 2000, e o uso da WHEA do ETW torna fácil para fabricantes de hardware e fornecedores de software desenvolverem aplicativos para o gerenciamento de diagnósticos de dispositivos que consumam eventos WHEA. Se um evento for grave o bastante para acarretar uma pane no sistema, a WHEA garantirá que o registro do erro fatal seja armazenado no arquivo de despejo de memória para que os administradores possam determinar a causa principal da pane.
Outra peça-chave da WHEA é o PSHED (Driver de Erro de Hardware Específico da Plataforma), localizado em %Systemroot%\System32\Pshed.dll. O kernel se vincula ao PSHED e faz a interface com a plataforma e o hardware do firmware, servindo basicamente como camada de conversão entre as notificações de erro e a API de relatório de erros da WHEA. A Microsoft fornece um PSHED para cada arquitetura de plataforma (x86, x64, Itanium), e o PSHED expõe um modelo de plug-in para que fabricantes e fornecedores de hardware possam substituir os comportamentos padrão pelos especificados em suas plataformas.
Finalmente, os componentes do sistema que fazem interface com outras origens de erro – como drivers de dispositivo, a HAL (Camada de Abstração de Hardware) e o kernel – podem implementar LLHELs (Manipuladores de Erros de Hardware de Baixo Nível) que inicialmente manipulam uma condição de erro. O trabalho de um LLHEL é extrair informações de erro do dispositivo, notificar o PSHED para permitir que ele colete outras informações de erro da plataforma e depois chamar a API de relatório de erros da WHEA do kernel.

Verificador de Driver
O Verificador de Driver, uma ferramenta eficiente para rastrear drivers de dispositivo com bugs e hardwares com falhas, foi incluída em cada cópia do Windows desde o Windows 2000. Geralmente, os administradores configuram o Verificador de Driver (%Systemroot%\System32\Verifier.exe) para monitorar atentamente o comportamento dos drivers de dispositivo suspeitos de provocar panes no sistema. O Verificador de Driver captura operações de driver ilegais para que um arquivo de despejo de memória aponte diretamente para a parte culpada.
Uma desvantagem das implementações anteriores do Verificador de Driver é que a maioria das alterações na configuração requerem reinicialização do sistema, algo que está longe de ser o desejado em um servidor de produção. A implementação do Verificador de Driver do Windows Server 2008 aprimora o processo ao eliminar o requisito de reinício para as verificações mais úteis, possibilitando que o problema de um servidor seja solucionado sem que seja necessário reiniciá-lo.
Além disso, o Verificador de Driver apresenta três novas verificações, que podem ser vistas na Figura 3. As verificações de segurança garantem que os drivers de dispositivo definam permissões seguras nos objetos usados para fazer a interface com aplicativos. Forçar solicitações de E/S pendentes testa a resiliência de um driver para operações de E/S assíncronas concluídas imediatamente, e não após um atraso. E Verificações diversas procura drivers que estejam liberando incorretamente recursos em uso, usando incorretamente APIs de registro da WMI (Instrumentação de Gerenciamento do Windows) e vazando identificadores de recurso.
Figura 3 Verificador de Driver com opções do Windows Server 2008 marcadas
Figura 3 Verificador de Driver com opções do Windows Server 2008 marcadas

Escalabilidade
A escalabilidade refere-se à capacidade de um aplicativo ou sistema operacional utilizar com eficácia vários processadores e grandes quantidades de memória. Cada versão do Windows melhora a escalabilidade minimizando ou eliminando o uso de bloqueios que reduzam o paralelismo em multiprocessadores, e o Windows Server 2008 não é exceção a essa tendência.
Uma melhoria relativamente pequena mas significativa está no código que executa a expiração de timer, o qual não adquire mais o bloqueio de distribuidor, que é um bloqueio de agendador do sistema inteiro usado por todas as operações de sincronização de nível baixo. A redução resultante na sobrecarga de sincronização da CPU permite que os sistemas do Terminal Server do Windows Server 2008 ofereçam suporte a, aproximadamente, 30% mais usuários simultâneos do que o Windows Server 2003.
Outros aprimoramentos de escalabilidade no Windows Server 2008 incluem aperfeiçoamentos na porta de conclusão, uma nova implementação de pool de threads, uso mais eficaz de hardware NUMA (Acesso Não-uniforme à Memória) e particionamento dinâmico do sistema.

Melhoria na manipulação de portas de conclusão de E/S
A maioria dos aplicativos de servidor do Windows escaláveis (como o IIS, o SQL Server® e o Exchange Server) se baseia em uma API de sincronização do Windows chamada porta de conclusão para minimizar a alternância entre vários threads de execução ao executar operações de E/S. Eles fazem isso primeiro associando notificações de novas chegadas de solicitações, como conexões do cliente servidor Web, a uma porta de conclusão e indicando um determinado pool de threads para esperar as notificações. Quando chega uma solicitação, o Windows agenda um thread, que normalmente executa então outras operações de E/S, como ler uma página da Web no disco e enviá-la ao cliente para concluir a solicitação.
Para que o mesmo thread possa voltar a esperar mais solicitações do cliente o mais rápido possível, o thread emite E/Ss de modo assíncrono e associa conclusões de E/S à porta de conclusão. Em seguida, ele volta a esperar na porta de conclusão, que agendará o thread quando uma nova solicitação chegar ou uma das E/Ss for concluída. Dessa forma, o mesmo thread permanece ativo em uma CPU, processando alternadamente solicitações do cliente e esperando na porta de conclusão.
Uma desvantagem da implementação de portas de conclusão nas versões anteriores do Windows é que, quando uma E/S era concluída, o sistema de E/S fazia com que o thread que emitiu a E/S executasse imediatamente uma parte do processamento de conclusão, não importa o que ele estivesse fazendo. Se outros threads estivessem ativos, isso costumava fazer com que o agendador admitisse preempção de um thread ativo e alternasse o contexto para o emissor.
O Windows Server 2008 evita essas alternâncias de contexto delegando o processamento de conclusão ao próximo thread a esperar na porta de conclusão à qual a E/S está associada. Assim, mesmo no caso de um thread diferente ser o próximo a esperar na porta de conclusão, ele realizará o processamento de conclusão antes de executar outro código, e o agendador não precisará alternar para o thread emissor. Essa redução nas alternâncias de contexto pode melhorar consideravelmente a escalabilidade de aplicativos de servidor muito carregados.

Pools de thread mais eficientes
A gravação de aplicativos que aproveitam várias CPUs pode ser difícil, por isso o Windows XP introduziu pools de threads de trabalho, uma API associada e de infra-estrutura que abstrai os detalhes da execução de pequenas unidades de trabalho através de CPUs. Um aplicativo especifica os itens de trabalho para a API do pool de threads, que os executa em um dos diversos threads criados e gerenciados para cada CPU no sistema.
O objetivo do pool de threads é reduzir as alternâncias de contexto usando os mesmos threads para executar vários itens de trabalho sucessivamente. Quando isso não é possível porque um dos threads está ocupado realizando outro trabalho, ele executa o item de trabalho usando um thread diferente em outra CPU.
A implementação do pool de threads do Windows Server 2008 faz melhor uso das CPUs indiretamente – porque se beneficia dos aprimoramentos na porta de conclusão – e diretamente, por meio da otimização do gerenciamento de threads para que os threads de trabalho venham e voltem dinamicamente quando necessário para manipular a carga de trabalho de um aplicativo. Além disso, o núcleo da infra-estrutura foi movido para o modo de kernel, diminuindo o número de chamadas do sistema feitas por aplicativos que usam a API. Finalmente, a nova API facilita a execução pelos aplicativos de certas operações, como a anulação de unidades de trabalho em fila durante o encerramento do aplicativo.

Otimizações NUMA
O Windows Server 2003 introduziu otimizações para computadores NUMA no gerenciador de memória e no agendador de threads, mas o Windows Server 2008 adiciona otimizações NUMA no gerenciador de E/S e estende as otimizações NUMA do gerenciador de memória.
Os sistemas NUMA normalmente são sistemas multiprocessadores em que a memória tem latência diferente, dependendo de qual processador a acessa (consulte a Figura 4). A memória é dividida em nós, nos quais as latências entre CPUs e nós podem variar e cada CPU é considerada parte de um nó ao qual tem o acesso mais rápido.
Figura 4 Exemplo de sistema NUMA
Figura 4 Exemplo de sistema NUMA
Os sistemas NUMA, especialmente aqueles com mais de oito CPUs, costumam ser mais econômicos e apresentar melhor desempenho do que os sistemas de acesso uniforme à memória. Embora um sistema desse tipo deva disponibilizar memória igualmente para todas as CPUs, um sistema NUMA pode implementar tanto interconexões de alta velocidade para memória conectada diretamente a uma CPU como conexões de alta latência mais baratas para CPUs e memória que estejam mais separadas.
Para dimensionar um sistema NUMA com eficiência, um aplicativo ou sistema operacional deve reconhecer a topologia de nós para que a computação seja executada próximo à memória que contém o código e os dados da computação. Por exemplo, o agendador do Windows atribui a cada thread um processador supostamente ideal, que é a CPU na qual o agendador tenta sempre executar o thread. Isso torna mais provável que os dados colocados pelo thread no cache da CPU estejam disponíveis para o thread toda vez que for executado.
No Windows Server 2003, o agendador expande esse conceito considerando o nó que contém o processador ideal como sendo o nó ideal do thread e tenta agendar o thread em outra CPU no nó ideal quando o processador ideal está ocupado executando um thread diferente. O gerenciador de memória do Windows Server 2003 também passa a reconhecer NUMA e, quando possível, direciona as alocações de memória de um thread para a memória do nó em que o thread está sendo executado.
No Windows Server 2008, o gerenciador de memória divide os buffers de memória não paginada do kernel (memória usada pelo kernel e pelos drivers de dispositivo para armazenar dados certamente permanecerão na RAM) pelos nós para que as alocações venham da memória no nó em que a alocação se originou. Caso a alocação requeira uma nova página da tabela de paginação para satisfazê-la, as PTEs (entradas da tabela de paginação do sistema) são alocadas a partir do nó do qual a alocação se originou, e não de qualquer nó, como ocorre no Windows Server 2003.
No Windows Server 2003, quando um thread fazia uma alocação de memória, o gerenciador de memória preferia o nó em que o thread estava sendo executado no momento da alocação. Se o thread estivesse momentaneamente agendado em um nó não-ideal, qualquer alocação executada durante esse tempo viria desse nó. Dessa forma, quando o thread viesse a ser executado no nó ideal, não estaria tão perto quanto poderia dos dados ou do código armazenados na memória alocada.
Para resolver isso, o gerenciador de memória do Windows Server 2008 dá preferência ao nó ideal de um thread para todas as alocações desse thread, mesmo quando o thread está sendo executado perto de um nó diferente. O gerenciador de memória também compreende automaticamente as latências entre processadores e nós. Portanto, se o nó ideal não tem memória disponível, seu próximo passo é verificar o nó mais perto do nó ideal. Além disso, o gerenciador de memória migra páginas em sua lista de espera para o nó ideal de um thread quando esse thread faz referência a código ou dados.
Os aplicativos que queiram controlar a localização de suas alocações podem usar as novas APIs de memória NUMA, que permitem especificar um nó preferencial para alocações de memória, além de exibições e objetos de mapeamento de arquivos. Para uma alocação relacionada a um mapeamento de arquivos, o gerenciador de memória verifica se a operação de mapeamento ou o objeto de mapeamento de arquivos especifica um nó. Caso nenhum dos dois tenha, ele vai para o nó ideal do thread.
Antes do Windows Server 2008, a DPC (chamada de procedimento deferida) associada e de interrupção relativa a uma E/S de rede ou de armazenamento podia ser executada em qualquer CPU, inclusive nas de um nó diferente daquele no qual a E/S foi iniciada. Com isso, era possível que os dados lidos ou gravados na operação de E/S ficassem na memória de um nó diferente daquele no qual os dados foram acessados.
Para evitar isso, o sistema de E/S do Windows Server 2008 direciona a execução de DPCs para uma CPU no nó que iniciou a E/S, e os sistemas que possuem dispositivos com suporte ao barramento PCI MSI-X (uma extensão do Message Signaled Interrupt padrão) podem localizar também a conclusão de E/S usando drivers de dispositivo que aproveitam APIs do Windows Server 2008 para direcionar uma interrupção de E/S para o processador que iniciou a E/S.

Particionamento dinâmico
Uma das maneiras de um sistema ser mais escalonável é dar suporte à adição dinâmica de recursos de hardware como CPUs e memória. Esse mesmo suporte também poderá tornar o sistema mais disponível quando esses recursos puderem ser substituídos sem que seja necessário reinicializá-lo.
O Windows Server 2003 possuía inclusão de memória a quente, permitindo que os servidores com suporte à memória dinâmica usassem a RAM quando adicionada por um administrador. O Windows Server 2008 estende o suporte à memória dinâmica possibilitando a substituição da memória.
A RAM que se torna mais dependente de correções de ECC (código de correção de erros) está arriscada a falhar totalmente, pois, em um servidor com suporte para substituição a quente, o Windows Server 2008 pode migrar dados imperceptivelmente de bancos de memória com falha e para substitutos. Para fazer isso, primeiro ele migra dados que estão sob controle do sistema operacional, depois encerra dispositivos de hardware movendo-os para um estado de baixa energia, migra o resto dos dados da memória e reinicializa os dispositivos para continuar a operação normal.
O Windows Server 2008 também oferece suporte à inclusão e à substituição a quente de processadores. Para uma substituição a quente, o hardware deve aceitar o conceito de CPUs sobressalentes, que podem ser colocadas online ou adicionadas dinamicamente quando uma CPU existente gerar indicações de falha, algo disponível atualmente apenas em sistemas de alta tecnologia. O agendador do Windows Server 2008 diminui a atividade na CPU em falha e migra o trabalho para a substituta. Depois disso, a CPU em falha pode ser removida e substituída por uma sobressalente.
O suporte do Windows Server 2008 à adição de processadores a quente permite que um administrador atualize os recursos de processamento de um servidor sem tempo de inatividade. Entretanto, o agendador e os sistemas de E/S só disponibilizarão uma nova CPU para aplicativos e drivers de dispositivo que solicitem notificação da chegada da CPU através de novas APIs porque alguns aplicativos pressupõem que o número de CPUs é fixo para uma sessão de inicialização. Por exemplo, um aplicativo pode alocar uma matriz de filas de trabalho correspondentes a cada CPU, na qual um thread usa a fila associada à CPU em que está sendo executado. Se o agendador colocar um dos threads do aplicativo em uma nova CPU, ele faria referência a uma fila não existente, o que pode corromper os dados do aplicativo e até danificar o aplicativo.
A capacidade de adicionar CPU é uma característica de aplicativos da Microsoft baseados em servidor como o SQL Server e o Exchange Server, assim como de vários processos básicos do Windows, inclusive o processo do Sistema, o Gerenciador de Sessão (%SystemRoot%\System32\Smss.exe,) e os processos de Host de Serviços Genérico (%Systemroot%\System32\Svchost.exe). Outros processos também podem solicitar notificação da chegada de nova CPU usando uma API do Windows. Quando uma nova CPU chega, o Windows notifica os drivers de dispositivo sobre a chegada iminente, inicia a CPU e notifica os aplicativos e os drivers de dispositivo gravados a fim de que aloquem estruturas de dados para rastrear atividades na nova CPU, se necessário.

Virtualização de computadores
Antes do Windows Server 2008, os produtos de virtualização da Microsoft, como o Virtual Server 2005, foram implementados com o uso de virtualização hospedada, como mostra a Figura 5. Na virtualização hospedada, as máquinas virtuais são implementadas por um VMM (Monitor de Máquina Virtual) que é executado junto com um sistema operacional host, normalmente como um driver de dispositivo. O VMM se baseia nos drivers de dispositivo e no gerenciamento de recursos do sistema operacional host e, quando esse sistema agenda sua execução, ele fraciona o tempo da CPU entre máquinas virtuais (VMs) ativas.
Figura 5 Virtualização de computadores hospedados
Figura 5 Virtualização de computadores hospedados
O Hyper-V, apelidado de "Viridian", é implementado pela virtualização com o hipervisor. O hipervisor tem controle total sobre os recursos de hardware, e até o sistema operacional Windows Server 2008 que inicializa o sistema operacional – e através do qual você controla VMs – está basicamente sendo executado em uma máquina virtual, como mostra a Figura 6.
Figura 6 Arquitetura do Hyper-V
Figura 6 Arquitetura do Hyper-V
O hipervisor pode particionar o sistema em várias VMs e trata a instância de inicialização do Windows Server 2008 como a partição mestre (ou raiz), permitindo que ela direcione o acesso a dispositivos de hardware como o disco, adaptadores de rede e processador gráfico. O hipervisor espera que a raiz realize o gerenciamento de energia e responda a eventos de hardware Plug and Play. Ele intercepta a E/S de dispositivo de hardware iniciada em uma partição filho e a roteia para a raiz, que usa os drivers de dispositivo padrão do Windows Server 2008 para obter acesso ao hardware. Dessa forma, os servidores que executam o Hyper-V podem aproveitar o suporte do Windows para dispositivos de hardware.
Quando você configura o Windows Server 2008 com a função de servidor Hyper-V, o Windows define a configuração hypervisorimagelaunchtypeboot do BCD (Banco de Dados de Configuração de Inicialização) como automática e configura o driver de dispositivo Hvboot.sys para antecipar o processo de inicialização. Se a opção estiver configurada, Hvboot.sys irá preparar o sistema para virtualização e depois carregar %Systemroot%\System32\Hvax64.exe ou %Systemroot%\System32\Hvix64.exe na memória, dependendo se o sistema implementa extensões de virtualização de CPU AMD-V ou Intel VT, respectivamente.
Depois de carregado, o hipervisor usa as extensões de virtualização para inserir a si próprio no Windows Server 2008. Aplicativos de modo de usuário usam o nível de privilégio Ring 3 do processador x64, enquanto código de modo de kernel é executado em Ring 0. Assim, o hipervisor opera no nível de privilégio conceitual Ring menos 1, já que pode controlar o ambiente de execução de código executado em Ring 0.
Quando você usa o console de gerenciamento do Hyper-V para criar ou iniciar uma partição filho, ele se comunica com o hipervisor por meio do driver %Systemroot%\System32\Drivers\Winhv.sys, que utiliza a API Hypercall publicamente documentada para direcionar o hipervisor e criar uma nova partição com características de execução e tamanho de memória física especificados. O Serviço VM (%Systemroot%\System32\Vmms.exe) dentro da raiz é o que cria um Processo de Trabalho VM (%Systemroot%\System32\Vmwp.exe) para cada partição filho gerenciar o estado do filho.
Uma forma pela qual o Windows melhora o desempenho de sistemas operacionais VM secundários é que tanto o Windows Server 2008 como o Windows Vista implementam esclarecimentos, que são seqüências de código ativadas apenas quando o sistema operacional está sendo executado em um hipervisor que implementa a API Hypercall da Microsoft. Ao solicitar serviços do hipervisor diretamente, a VM filho evita a sobrecarga no código de virtualização que resultaria caso o hipervisor tivesse de adivinhar a intenção do sistema operacional secundário.
Por exemplo, um sistema operacional convidado que não implemente esclarecimentos para spinlocks (os quais executam sincronização de multiprocessador de baixo nível) simplesmente transferiria um loop estreito à espera da liberação de um spinlock por outro processador virtual. A transferência poderia obstruir uma das CPUs de hardware até que o hipervisor agendasse o segundo processador virtual. Nos sistemas operacionais esclarecidos, o código de spinlock notifica o hipervisor através de uma Hypercall quando normalmente seria transferido, para que o hipervisor possa agendar imediatamente outro processador virtual e reduzir o desperdício no uso da CPU.
Outra maneira de o Windows Server 2008 melhorar o desempenho de VMs é acelerar o acesso de VMs a dispositivos. O desempenho é aprimorado por meio da instalação de uma coleção de componentes, coletivamente chamados de "componentes de integração de VM", no sistema operacional secundário.
Se você executar uma VM sem instalar os componentes de integração, o sistema operacional secundário configurará drivers de dispositivo de hardware para os dispositivos emulados apresentados pelo hipervisor. O hipervisor deve intervir quando um driver de dispositivo tenta tocar em um recurso de hardware para informar a partição Raiz, que executa a E/S de dispositivo usando drivers de dispositivo do Windows em nome do sistema operacional de VM secundário. Como uma única operação de E/S de nível alto (a leitura de um disco, por exemplo) pode envolver muitos acessos distintos a hardware, ela pode causar muitas transições (chamadas de interceptações) no hipervisor e na partição raiz.
O Windows Server 2008 minimiza as interceptações com três componentes: o Driver de Barramento de Máquina Virtual (%Systemroot%\System32\Drivers\Vmbus.sys), Clientes de Serviço Virtual (VSCs) e Provedores de Serviço Virtual (VSPs). Quando você instala componentes de integração em uma VM com um sistema operacional compatível, os VSCs assumem a função de drivers de dispositivo e usam os serviços do driver Vmbus.sys na VM filho para enviar solicitações de E/S de nível alto ao Driver de Barramento de Máquina Virtual na partição Raiz através da Hypercall e dos serviços de compartilhamento de memória do hipervisor. Na partição raiz, Vmbus.sys encaminha a solicitação ao VSP correspondente, que inicia então as solicitações padrão de E/S do Windows através dos drivers de dispositivo da raiz.
Como você pode ver, o Windows Server 2008 desempenha um papel fundamental na estratégia de virtualização de computadores da Microsoft com sua introdução à virtualização baseada no hipervisor Hyper-V. Procure mais informações sobre esses e outros recursos na próxima edição do meu livro, Microsoft Windows Internals, cuja publicação está prevista ainda para este ano.

Mark Russinovich é um colega da área técnica da Microsoft na divisão de plataforma e serviços. Ele é co-autor do livro Microsoft Windows Internals (Microsoft Press, 2004) e palestrante assíduo em conferências de desenvolvedores e de TI, como o Microsoft TechEd e a Conferência para Desenvolvedores Profissionais,. Mark ingressou na Microsoft com a recente aquisição da empresa de que foi co-fundador, a Winternals Software. Ele também criou a Sysinternals, através da qual publicou muitos utilitários populares, como Process Explorer, Filemon e Regmon.
© 2007 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..


 Cobertura especial: Windows Server 2008: Novidades no ADDS (Servi&#231;os de Dom&#237;nio Active Directory)
Cobertura especial: Windows Server 2008 Gil Kirkpatrick

Novidades no ADDS (Serviços de Domínio Active Directory)
Visão geral:
  • Usando o novo Gerenciador de Servidores com o ADDS
  • Executando serviços de domínio no Server Core
  • Controladores de domínio somente leitura
  • Alterações em senhas, fazendo backup e auditando

Com o Windows 2000, a Microsoft apresentou ao mundo o Active Directory. A próxima versão principal, o Windows Server 2003, trouxe aprimoramentos consideráveis no Active Directory, mas nenhuma
alteração muito surpreendente. Atualmente, o Active Directory® é um serviço de diretório robusto e muito amadurecido. Mesmo assim, a equipe do Active Directory contribuiu com avanços substanciais na versão mais recente para aumentar a segurança e a gerenciabilidade desse serviço de rede básico.
Em torno da virada do século, o Active Directory era aquilo que autenticava um usuário no logon, aplicava diretivas de grupo ao usuário e seu computador e o ajudava a localizar a impressa que ele estava procurando. Alguns anos mais tarde, a Microsoft lançou uma variante autônoma chamada ADAM (Modo de Aplicativo do Active Directory).
Em 2006, tudo isso mudou. O Active Directory não era mais uma tecnologia específica. Passou a ser o nome da marca que identifica uma coleção de serviços para controle de acesso e identidades do Windows® prontos para usar. A Figura 1 apresenta um rápido resumo do que constitui a marca Active Directory.
Figure 1 Componentes do Active Directory (Close Figure 1)

Tecnologia atual do Active Directory | Anteriormente chamado | Descrição
Serviços de Domínio Active Directory (ADDS) | Active Directory | O que costumávamos chamar de Active Directory. Fornece autenticação Kerberos e baseada em NTLM para usuários e computadores do domínio e gerencia unidades organizacionais, grupos, diretivas de grupo e muito mais.
Active Directory Lightweight Directory Services (ADLDS) | Modo de Aplicativo do Active Directory (ADAM) | Um servidor LDAP de alto desempenho baseado no mesmo código-fonte usado pelo ADDS.
Serviços de Certificados do Active Directory (ADCS) | Serviços de Certificados | Fornece autenticação forte usando certificados X.509.
Active Directory Rights Management Services (ADRMS) | Rights Management Services | Protege ativos digitais (como documentos e emails) contra uso não autorizado criando contêineres e arquivos protegidos por direitos.
Serviços de Federação do Active Directory (ADFS) | Serviços de Federação do Active Directory | Fornece logon único na Web e federação de identidade para serviços Web compatíveis com WS-*.
Assim, para usar a terminologia correta, este artigo é sobre os Serviços de Domínio. Para ser honesto, porém, ainda é o mesmo Active Directory que você aprendeu a amar desde 2000.

Gerenciador de Servidores no Windows Server 2008
Os dois primeiros aprimoramentos do Active Directory que discutirei aqui não são realmente alterações no ADDS (Serviços de Domínio Active Directory). São alterações no Windows que modificarão o modo como você gerencia o Active Directory. O primeiro – o novo Gerenciador de Servidores – pode ser notado logo na primeira inicialização do servidor Windows Server® 2008. O segundo é a instalação do Server Core, que comentarei daqui a pouco.
É provável que o Gerenciador de Servidores lhe pareça familiar por causa do Assistente para Configurar o Servidor no Windows Server 2003, que surge por padrão depois que você instala o Windows Server 2003. Essa versão, contudo, não é muito útil para a administração do dia-a-dia, e todo o mundo que eu conheço marca a caixa "Não exibir esta página ao fazer logon".
O Gerenciador de Servidores no Windows Server 2008, por outro lado, é bem útil (consulte o artigo de Byron Hynes nesta edição da TechNet Magazine para obter uma visão geral desse recurso). Em primeiro lugar, como você pode ver na Figura 2, o Gerenciador de Servidores agora é um snap-in do MMC (Console de Gerenciamento Microsoft®), e não mais um Aplicativo HTML (HTA). Isso significa que ele tem uma interface do usuário cheia de recursos, familiar e fácil de personalizar. Pronto para ser usado, o Gerenciador de Servidores permite gerenciar a instalação de funções de servidor (serviços essenciais como DNS, ADDS e IIS) e recursos (componentes de software, como o Microsoft .NET Framework, a criptografia de unidade de disco BitLockerTM e o Windows PowerShellTM). Além da capacidade de adicionar e remover software, o Gerenciador de Servidores também oferece um ponto de contato único para executar ferramentas de diagnóstico (como Visualizar Eventos e PerfMon) e utilitários de configuração do sistema (como o Gerenciador de Dispositivos e o snap-in Firewall do Windows). Se você adicionar os snap-ins do MMC para Active Directory (por exemplo, Usuários e Computadores, Domínios e Relações de Confiança, e Sites e Serviços), terá uma interface bem bonita para executar o gerenciamento diário do seu controlador de domínio do Windows Server 2008.
Figura 2 Gerenciador de Servidores no Windows Server 2008
Figura 2 Gerenciador de Servidores no Windows Server 2008

Windows Server 2008 Server Core
O Windows Server Core é uma nova opção de instalação do Windows que fornece uma versão reduzida do Windows contendo apenas os componentes necessários para executar certas funções de servidor importantes, como os Serviços de Domínio Active Directory. A Figura 3 lista as funções com suporte no Server Core. Embora uma instalação Server Core possua uma interface gráfica do usuário, ela não executa o shell de desktop do Windows, e quase todas as ferramentas gráficas para gerenciar e configurar o Windows estão ausentes (consulte a Figura 4). Em lugar delas, você recebe uma janela de comando e fica com a sensação de que não sabe o que fazer a seguir. Como faço para alterar o nome do computador? Como configuro um endereço IP estático?
Figura 4 Não há muito a ver na interface do usuário do Server Core
Figura 4 Não há muito a ver na interface do usuário do Server Core
Os primeiros minutos na frente de uma instalação Server Core podem ser perturbadores. Mas depois de algum tempo familiarizando-se novamente com WMIC, NETSH e NETDOM, você estará apto a realizar todas as tarefas de instalação e configuração, sem dificuldade. E ainda tem o Regedit e o Bloco de Notas para satisfazer suas necessidades de ferramenta gráfica.
A principal vantagem do Server Core é que é removida uma boa parte do código obtido com a instalação típica do Windows, que talvez não seja necessária para as principais funções de servidor. Isso reduz a possível superfície de ataque de malware (o que é bom) e diminui a quantidade de aplicação de patch e de reinicialização que você terá de executar em seus controladores de domínio (o que é melhor ainda). Você tem também menos requisitos de disco rígido e uma capacidade de disco muito menor, o que normalmente não é grande coisa, mas pode ser útil em ambientes de servidor virtualizados.
A ausência de utilitários gráficos dificulta o gerenciamento do ADDS? De forma alguma. É possível realizar quase todas as tarefas de gerenciamento remotamente por meio da execução dos utilitários na estação de trabalho e da conexão ao controlador de domínio pela rede. Minha expectativa é que a grande maioria de controladores de domínio virá a ser executada em instalações Server Core.

Alterações no DCPROMO
A primeira alteração que você observará no ADDS em si é o novo DCPROMO. Ele funciona exatamente como o DCPROMO no Windows Server 2003, mas foi completamente reescrito para facilitar o uso. Por exemplo, você não precisa inserir suas credenciais de administrador de domínio; o DCPROMO pode usar as credenciais do seu login atual para promover o servidor. Também não é necessário digitar DCPROMO /ADV para obter as opções do DCPROMO no modo avançado. Agora existe uma caixa de seleção na primeira caixa de diálogo do DCPROMO para habilitar essas opções. O modo avançado também permite selecionar o controlador de domínio a partir do qual será feita a replicação. Isso significa que é possível manter a carga de replicação do DCPROMO fora dos controladores de domínio de produção.
Quando você promove um controlador de domínio em um novo domínio ou floresta, o DCPROMO lhe dá a opção de definir o nível funcional do domínio ou da floresta, para que você não precise fazê-lo mais tarde. Você também pode especificar o site do Active Directory no qual deseja colocar o controlador de domínio durante o processo de promoção, o que é muito útil no cenário de DCPROMO autônomo. O DCPROMO até sugerirá o melhor site para o controlador de domínio com base no respectivo endereço IP.
O novo DCPROMO também reúne todas as opções de configuração em uma única página, fornecendo um lugar em que você poderá decidir se o novo controlador de domínio será um catálogo global (GC), um servidor DNS ou um controlador de domínio somente leitura. Não é preciso ir para um local obscuro no snap-in Sites e Serviços do Active Directory para marcar o controlador de domínio como GC.
Mas talvez o recurso mais interessante no novo DCPROMO seja a capacidade de salvar todas as configurações em um arquivo de resposta um pouco antes do processo de promoção ter início. Isso é muito mais simples – e menos sujeito a erros – do que emendar o arquivo de resposta à mão. Você poderá então usá-lo para executar DCPROMOs autônomos em outros servidores. E, para os fanáticos por script, agora todas as opções do DCPROMOs podem ser acessadas a partir da linha de comando.

Controladores de domínio somente leitura
Nos primórdios do Active Directory, as empresas costumavam implantar controladores de domínio em cada site no qual os usuários pudessem fazer login. Isso era comum nos bancos, por exemplo, onde cada agência tinha um controlador de domínio. A lógica era que os usuários na agência poderiam fazer logon e acessar recursos de rede locais mesmo se a WAN falhasse.
Na época, a necessidade de segurança física dos controladores de domínio não era bem compreendida. Já vi controladores de domínio enfiados debaixo de mesas, onde poderiam facilmente ser acessados pelas pessoas que passavam. Só alguns anos mais tarde é que os arquitetos do Active Directory tiveram compreensão total do risco à segurança que era um controlador de domínio e as organizações de TI começaram a consolidar seus controladores de domínio em data centers mais centralizados. Os usuários das filiais passaram fazer a autenticação pela WAN, mas a segurança adicional compensava.
O Active Directory no Windows Server 2008 muda a equação no tocante à implantação de filiais introduzindo controladores de domínio somente leitura (RODCs), que representam a maior alteração nos Serviços de Domínio do Windows Server 2008.
O foco da equipe do Active Directory quando desenvolveu o RODC eram os requisitos do cenário de filiais, por isso adotou a meta de "o que acontece na filial, fica na filial". A questão é que, se você implanta um controlador de domínio em uma filial fisicamente insegura, não há nada que possa fazer para impedir que ele (e os computadores que confiam nele) seja comprometido, mas pode evitar que esse comprometimento se espalhe da filial para o resto do domínio.
Observe que, mesmo que constituam uma enorme alteração na infra-estrutura do ADDS, os RODCs são bem simples de implementar. É preciso que o seu domínio esteja no nível funcional de floresta do Windows Server 2003 e deve haver pelo menos um controlador de domínio do Windows Server 2008 no domínio. Mais do que ser simplesmente uma solução para filiais, os RODCs fazem sentido em ambientes voltados para a Internet e em situações nas quais o controlador de domínio é colocado no perímetro da rede.

Controlador de domínio ausente sem permissão
Existem várias classes de ameaças a considerar em uma filial. A primeira é o cenário "controlador de domínio roubado", em que alguém some com o controlador de domínio ou seu respectivo disco. Mais do que a interrupção do serviço local, o risco é que o invasor acabe obtendo acesso a todos os nomes de usuário e senhas no domínio e, a partir daí, eleve seus privilégios para obter acesso a recursos protegidos ou provocar uma negação de serviço. Para resolver essa ameaça, os RODCs, por padrão, não armazenam os hashes de senha na DIT (árvore de informações de diretórios) do RODC. Assim, para autenticar um usuário no domínio, quando ele se autentica pela primeira vez em um determinado RODC, este passa a solicitação para um controlador de domínio completo (FDC) no domínio. O FDC processa a solicitação e, se bem-sucedida, o RODC emite uma solicitação de replicação para o hash de senha.
Um RODC comprometido poderia solicitar hashes de senha para contas confidenciais. Para impedir isso, o administrador de domínio pode configurar uma diretiva de replicação de senha para cada RODC. Essa diretiva é formada por dois atributos no objeto de computador do RODC. O atributo msDS-RevealOnDemandGroup contém os nomes distintos de contas de grupos, usuários ou computadores cujas senhas podem ser armazenadas em cache no RODC (normalmente, são usuários e computadores do mesmo site que o RODC). O msDS-NeverRevealGroup contém os nomes distintos de contas de grupos, usuários ou computadores cujas senhas não podem ser armazenadas em cache no RODC (por exemplo, a conta do administrador de domínio nunca deve ter seus hashes de senha armazenados em cache em um RODC). Quando o RODC solicita o hash de senha de uma determinada conta, o FDC avalia a solicitação em relação à diretiva de replicação de senha para determinar se o hash de senha deve ser replicado para o RODC. Quando um controlador de domínio é roubado, isso limita a vulnerabilidade àquelas senhas que tinham sido armazenadas em cache no RODC roubado na época em que ele foi removido da rede, o que elimina a possibilidade de uma senha importante ser comprometida.
O objeto de computador do RODC contém dois outros atributos para ajudá-lo a determinar exatamente quais contas devem ter suas senhas armazenadas em cache. O atributo msDS-AuthenticatedAtDC lista as contas que foram autenticadas no RODC, enquanto o atributo msDS-RevealedList nomeia as contas cujas senhas estão armazenadas atualmente no RODC.
Os hashes de senha de usuários e computadores não são os únicos segredos armazenados em um controlador de domínio. A conta KrbTGT contém as chaves para o serviço Centro de Distribuição de Chaves Kerberos (KDC) executado em cada controlador de domínio. Em um cenário típico, cada KDC no domínio compartilha a mesma conta KrbTGT e é possível que um invasor possa recuperar essas chaves de um controlador de domínio roubado a fim de usá-las para atacar o resto do domínio. No entanto, cada RODC tem suas próprias chaves e conta KrbTGT, eliminando essa possibilidade.
Também não é incomum os aplicativos armazenarem senhas ou outros segredos na DIT. Se um invasor fosse roubar um controlador de domínio, possivelmente roubaria essas senhas de aplicativo e as usaria para obter acesso aos aplicativos. Para diminuir esse risco, os Serviços de Domínio do Windows Server 2008 permitem que os administradores definam o conjunto de atributos filtrados para o RODC (RO-FAS). Os atributos que fazem parte do RO-FAS nunca são replicados para RODCs e, portanto, não podem ser recuperados de um controlador de domínio comprometido. Você designa atributos ao RO-FAS definindo o bit 9 (0x0200) do atributo searchFlags do objeto attributeSchema correspondente no esquema.

Bárbaros no recinto
Outra classe de ameaça a controladores de domínio de filiais é o caso de um administrador de servidor local que eleva seu privilégio aproveitando os privilégios do controlador de domínio para obter acesso a outros recursos do domínio ou engendrar um ataque de negação de serviço. Mais uma vez, se o administrador local tiver acesso físico ao controlador de domínio, pouco poderá ser feito para impedir o comprometimento. Mas é possível impedir o invasor de usar o controlador de domínio de filiais para comprometer outros no domínio.
Os controladores de domínio completo no domínio não confiam nos RODCs como controladores de domínio. Do ponto de vista de relações de confiança, os FDCs tratam os RODCs como servidores membros no domínio. Um RODC não é membro dos grupos Controladores de Domínio de Empresa ou Controladores de Domínio. A conta do RODC tem capacidade muito limitada para atualizar algo no diretório. Por isso, mesmo que um invasor a comprometa, não obterá praticamente nenhum privilégio.
Os RODCs nem mesmo aparecem na topologia de replicação normal do controlador de domínio. Como os RODCs parecem servidores membros normais e não controladores de domínio, o KCC (Knowledge Consistency Checker), que é o processo em cada controlador de domínio responsável por calcular a topologia de replicação do controlador de domínio, não criará objetos de conexão a partir dos RODCs. Nenhum controlador de domínio ou RODC tentará replicar de um RODC. Por outro lado, o RODC criará um objeto de conexão representando um acordo de replicação de entrada a partir de um controlador de domínio completo, mas esse objeto de conexão só existe na réplica do RODC; nenhum outro controlador de domínio tem uma cópia desse objeto de conexão. Do ponto de vista de replicação, os RODCs são como motéis cheios de baratas para os objetos de diretório. Os objetos se replicam internamente, mas não externamente.

Separação de funções administrativas nos RODCs
É muito comum o controlador de domínio de uma filial ser gerenciado por um administrador de servidor local que faz tudo, desde executar backups no controlador de domínio até limpar teclados. Mas é um risco à segurança conceder a um administrador de site remoto os direitos necessários para fazer manutenção geral em um controlador de domínio, pois ele pode elevar seus privilégios no domínio. Os RODCs fornecem dois tipos de separação de funções administrativas para minimizar essa ameaça.
Com a primeira forma de separação de funções, o administrador de domínio pode promover o RODC normalmente usando o DCPROMO ou pode utilizar um processo em duas etapas no qual o processo de promoção real é delegado de modo seguro ao administrador de site da filial, sem conceder direitos de administração de domínio. O administrador de domínio cria previamente a conta de computador do RODC no domínio usando o snap-in do MMC Usuários e Computadores do Active Directory, como mostra a Figura 5.
Figura 5 Criando previamente a conta de computador do RODC
Figura 5 Criando previamente a conta de computador do RODC
Se você selecionar "Pré-criar conta do Controlador de Domínio Somente Leitura", será executada uma versão abreviada do DCPROMO que realiza todas as tarefas que requerem acesso administrativo ao domínio. Por exemplo, criação da conta de computador, atribuição do RODC a um site, especificação das funções do controlador de domínio, especificação da diretiva de replicação de senha e definição do usuário ou grupo que precisará dos direitos para concluir a operação do DCPROMO no RODC. O grupo ou administrador delegado é armazenado no atributo managedBy do objeto de computador do RODC.
O administrador delegado pode então executar o DCPROMO no próprio servidor. O DCPROMO detectará a conta pré-criada e transformará o servidor em um RODC. A execução do DCPROMO dessa maneira não requer credenciais de administrador de domínio.
A segunda forma de os RODCs fornecerem separação de funções administrativas é criando funções administrativas locais no próprio RODC. Essas funções parecem grupos locais de computador (são armazenadas no Registro do RODC) e só podem ser avaliadas no RODC. Mas, em vez de usar o snap-in do MMC Gerenciamento do Computador para gerenciá-las, o administrador gerencia as funções locais do RODC usando o NTDSUTIL. A Figura 6 lista as funções administrativas locais em um RODC. Essas funções correspondem uma a uma aos grupos internos no Windows.
Figure 6 Funções administrativas do RODC local (Close Figure 6)

Operadores de Conta
Administradores
Operadores de Backup
Acesso DCOM de Serviços de Certificados
Operadores Criptográficos
Distributed COM - Usuários
Leitores de Log de Eventos
Convidados
IIS_IUSRS
Construtores de Confiança de Floresta de Entrada
Operadores de Configuração de Rede
Usuários do Log de Desempenho
Usuários do Monitor de Desempenho
Acesso Compatível com Versões Anteriores ao Windows 2000
Operadores de Impressão
Usuários da Área de Trabalho Remota
Replicadores
Operadores de Servidor
Usuários de Licença do Terminal Server
Usuários
Grupo de Acesso de Autorização do Windows

Singularidades do RODC
Os RODCs podem exibir alguns comportamentos inesperados, já que são somente leitura e nenhum outro controlador de domínio se replicará a partir deles. Por exemplo, objetos persistentes – ou seja, aqueles que tenham sido excluídos de todos os locais exceto de um determinado controlador de domínio porque este não podia ser replicado por mais tempo do que o tempo de vida de desativação da floresta – normalmente são detectados pelos parceiros de replicação externos do controlador de domínio. Mas como os RODCs não têm nenhum parceiro de replicação interno, não há detecção de objetos persistentes para eles.
Os RODCs não atenderão a operações de atualização do LDAP (adição, modificação, exclusão e movimentação). Em vez disso, eles retornam um erro com uma referência LDAP para um controlador de domínio gravável que possa atender à operação. Se o aplicativo que emitiu a atualização do LDAP não processar corretamente a operação de referência, poderá falhar.
Finalmente, se um usuário de outro domínio na floresta tentar autenticar em um RODC, este deverá ser capaz de acessar um FDC em seu próprio domínio a fim de obter a senha de confiança para passar corretamente a solicitação de autenticação para o controlador de domínio no domínio do usuário. Se a conexão de rede entre o RODC e o FDC em seu domínio estiver indisponível, ocorrerá falha na autenticação.

Diretivas de senha refinadas
A capacidade de definir mais de uma diretiva de senha no domínio era provavelmente o recurso mais solicitado para o ADDS do Windows Server 2008. Como você já deve saber, no Active Directory do Windows 2000 e do Windows Server 2003, cada domínio oferece suporte a apenas uma única diretiva de senha, que é aplicada a todas as entidades de segurança no domínio. Se você precisa de uma diretiva de senha separada para um grupo específico de usuários, tem de criar um domínio separado. Mas agora um novo recurso no ADDS do Windows Server 2008, chamado Diretivas Refinadas de Senha, permite definir várias diretivas de senha em um domínio.
A nova estratégia usa grupos para aplicar diretivas de senha refinadas a usuários. Primeiro você define a diretiva de senha refinada criando um novo objeto msDS-PasswordSettings no contêiner CN=Password Settings Container, CN=System, DC=<domínio>. O objeto msDS-PasswordSettings (PSO l, para abreviar) contém atributos que correspondem à configuração de diretiva de senha na Diretiva de Grupo (consulte a Figura 7).
Figure 7 Atributos no objeto mSDS-PasswordSettings (Close Figure 7)

Atributo | Descrição
mSDS-PasswordReversibleEncryptionEnabled | Booleano indicando se as senhas são criptografadas com o uso de criptografia reversível.
mSDS-PasswordHistoryLength | Número de entradas mantidas no histórico de senhas.
mSDS-PasswordComplexityEnabled | Booleano indicando se as restrições de complexidade de senha estão habilitadas.
mSDS-MinimumPasswordLength | Inteiro definindo o comprimento mínimo de senha.
mSDS-MinimumPasswordAge | INTEGER8 indicando o tempo de vida mínimo da senha antes de poder ser alterada.
mSDS-MaximumPasswordAge | INTEGER8 indicando o tempo de vida máximo da senha antes de precisar ser alterada.
mSDS-LockoutThreshold | Inteiro indicando o número de logons com falha antes do bloqueio.
mSDS-LockoutObservationWindow | INTEGER8 indicando o número de nanossegundos dentro dos quais foi preciso que logons com falha consecutivos ocorressem para disparar o bloqueio.
mSDS-LockoutDuration | INTEGER8 indicando o número de nanossegundos em que a conta foi bloqueada.
Você atribui então a diretiva de senha a usuários ou grupos adicionando seus nomes ao atributo do PSO com valores múltiplos chamado mDS-PSOAppliesTo. Depois que você aceita a idéia de não aplicar diretivas de senha a unidades organizacionais, é bem simples. Mas há uma complexidade a mais.
Normalmente, os usuários são membros de muitos grupos. O que acontece se houver várias diretivas de senha conflitantes associadas a um usuário por causa dessas associações de grupo? Nesse caso, o ADDS usa a avaliação de precedência para determinar qual diretiva de senha deverá ser aplicada. Funciona assim:
  1. Se a diretiva de senha estiver vinculada diretamente a um objeto de usuário (e não através de uma associação de grupo), será aplicada.
  2. Caso haja várias diretivas de senha vinculadas diretamente ao usuário, a diretiva com o menor valor de precedência (conforme determinado pelo valor do atributo do PSO msDS-PasswordSettingsPrecendence) será aplicada.
  3. Se houver vários PSOs com a mesma precedência, aquele com o menor valor objectGUID será aplicado.
  4. Caso nenhum PSO esteja vinculado ao usuário, o ADDS avaliará os PSOs vinculados aos grupos do usuário. Se houver mais de um PSO, o PSO com o menor valor no atributo msDS-PasswordSettingsPrecedence será aplicado.
  5. Caso haja mais de um PSO com o mesmo valor de precedência, aquele com o menor valor objectGUID será aplicado.
  6. Se nenhum PSO estiver associado ao usuário, a diretiva de senha de domínio será usada.
Os objetos de usuário têm um novo atributo chamado msDS-ResultantPSO para ajudar a classificar exatamente qual PSO se aplica a um usuário. Esse atributo contém o nome distinto do PSO que governa a senha desse usuário.
As diretivas de senha refinadas dão mais flexibilidade do que o necessário, mas você deve gerenciar essas diretivas com cuidado e mantê-las simples. Não existe nenhum utilitário pronto para usar que defina diretivas de senha refinadas; você precisará usar ADSIEdit ou localizar um utilitário de terceiros.

Serviço Active Directory reinicializável
Sempre que você desativa o controlador de domínio para fazer manutenção da DIT, provoca alguma interrupção nos níveis de serviço de rede. Os controladores de domínio do Windows Server 2008 têm um novo recurso que permite parar o serviço de diretório sem desligar completamente o controlador de domínio.
O comando NET STOP NTDS pára o ADDS em um controlador de domínio do Windows Server 2008. Quando você faz isso, o processo do serviço LSASS no controlador de domínio continua em execução, mas descarrega todas as DLLs relacionadas ao ADDS e o serviço de diretório fica indisponível. O LSASS então se comporta basicamente como faria em um servidor membro, encaminhando as solicitações de autenticação de domínio para um controlador de domínio. Como as DLLs que processam o ADDS estão descarregadas, você pode aplicar patches relacionados ao ADDS ou executar uma desfragmentação offline da DIT. Iniciar o ADDS é tão simples como NET START NTDS. No entanto, a restauração da DIT a partir de um backup de estado do sistema ainda exige que você reinicialize no modo de reparo do serviço de diretório.
É importante compreender que o serviço de diretório não é um serviço do Windows real. Ele continua sendo um componente integrante do LSASS, que não pode ser parado sem que o computador seja desligado. Mas a capacidade de iniciar e parar o diretório de serviço no Windows Server 2008 é uma opção conveniente.

Backup e recuperação
O mecanismo inteiro de backup e restauração foi remodelado no Windows Server 2008. Não entrarei em detalhes aqui, mas o novo Backup do Windows Server tem alguma alterações que afetam o ADDS.
O Backup do Windows Server é uma solução de backup baseada em volume, o que significa que faz backup de volumes de disco inteiros de cada vez. Porém, ele só faz backup em dispositivos de disco (ou semelhantes), ou seja, não aceita backup em fita.
Existe uma opção de backup de estado do sistema para o utilitário de backup da linha de comando WBADMIN. Usando o comando WBADMIN START SYSTEMSTATEBACKUP, agora você pode criar uma imagem de backup que contém todos os arquivos do sistema necessários para restaurar o Active Directory em um controlador de domínio. No entanto, embora haja um potencial para até cinco volumes no conjunto de backup, os volumes nesse conjunto conterão apenas os arquivos necessários para uma restauração de estado do sistema. Por mais incômodo que isso seja, desde a versão RC0 do Windows Server 2008, não é possível executar um backup de estado do sistema em um compartilhamento de rede. É preciso ter um volume de disco local disponível para armazenar imagens do backup de estado do sistema e esse volume não deve fazer parte do conjunto de volumes desse backup. Talvez seja necessário adicionar um novo volume de disco a cada controlador de domínio em que você executar backups de estado do sistema.
Executar uma restauração de estado do sistema é simples. Basta inicializar o controlador de domínio no Modo de Restauração dos Serviços de Diretório e executar o comando WBADMIN START SYSTEMSTATERECOVERY. O resultado é uma DIT restaurada de forma não autoritativa, na qual é possível restaurar objetos específicos de modo autoritativo usando NTDSUTIL, exatamente como você fez no Windows Server 2003.
Um aspecto do Backup do Windows Server merece ser mencionado: ele armazena imagens de backup no formato VHD (Virtual Hard Disk). Esse é o mesmo formato que o Microsoft Virtual Server 2005 usa para armazenar suas imagens de disco virtual. Isso significa que você pode pegar uma imagem de backup criada com o Backup do Windows Server e montá-la como unidade de disco em uma máquina virtual que esteja executando o Microsoft Virtual Server. Depois é só navegar até o conteúdo do backup como se fosse uma unidade de disco normal!
Outra alteração em relação ao backup do ADDS é a capacidade de usar o Serviço de Cópias de Sombra de Volume para criar instantâneos pontuais do Active Directory. Quando você cria um instantâneo usando NTDSUTIL, o Serviço de Cópias de Sombra de Volume salva a imagem anterior de cada bloco de disco da DIT antes que ela seja substituída por uma operação de atualização. Combinando as imagens anteriores salvas com a versão atual da DIT, o Serviço de Cópias de Sombra de Volume pode construir um instantâneo completo da DIT com muito pouca sobrecarga. Um instantâneo típico leva apenas alguns segundos para ser criado, seja qual for o tamanho da DIT.
Por si só, essa é uma capacidade interessante, mas não tão útil assim. Entretanto, no Windows Server 2008, o ADDS inclui um utilitário de linha de comando chamado DSAMAIN que monta a imagem do instantâneo no modo somente leitura. Isso fornece um servidor LDAP autônomo, muito parecido com uma instância do ADLDS que inclui o conteúdo do seu diretório na época do instantâneo. Você pode procurar o diretório usando o utilitário LDP ou outras ferramentas LDAP e recuperar versões de objetos de diretório a partir de um ponto anterior no tempo.

Replicação do SYSVOL com DFS-R
O Windows Server 2003 R2 apresentou um DFS (serviço de arquivos distribuído) remodelado que incorporou um mecanismo de replicação de arquivos novo em folha chamado DFS-R. Ele usa compactação diferencial remota, o que reduz consideravelmente o tráfego de replicação de arquivos determinando quais blocos de um arquivo de destino precisam ser replicados para colocá-lo em sincronia com o arquivo de origem. No entanto, o Windows Server 2003 R2 ainda usa o Serviço de Replicação de Arquivos (e não o DFS-R) para replicar o SYSVOL entre controladores de domínio. Por causa disso, a replicação do SYSVOL continuou a ser uma fonte de problemas para os administradores do Active Directory.
Durante a execução em seu nível funcional de domínio, o Windows Server 2008 pode replicar o SYSVOL com o uso do DFS-R, aumentando a velocidade e a robustez da replicação do SYSVOL. E isso torna razoável colocar arquivos grandes no SYSVOL para disponibilizá-los em todos os controladores de domínio. Para usar o DFS-R para o SYSVOL, você deve primeiro migrar os dados antigos do SYSVOL para o DFS-R usando o utilitário DFSRMIG. Esse processo consiste em quatro etapas:
  • Criar objetos do Active Directory necessários para o DFS-R.
  • Criar a nova estrutura de arquivos do SYSVOL em cada controlador de domínio.
  • Alternar todos os controladores de domínio para usar o novo SYSVOL.
  • Remover o SYSVOL antigo.
Dependendo do tamanho do SYSVOL e do número de controladores de domínio que você tem, esse processo pode demorar um pouco, mas o desempenho e a confiabilidade aprimorados fazem o esforço valer a pena.

Aprimoramentos de auditoria
O sistema de auditoria no Active Directory para Windows Server 2003 é, ao mesmo tempo, uma benção e uma maldição. Por um lado, ele fornece uma solução bem abrangente, flexível e segura para rastrear alterações no diretório. Mas alguns podem argumentar que ele possui diversos problemas de usabilidade significativos.
A habilitação da auditoria de alterações de diretório em um controlador de domínio do Windows Server 2003 é uma questão de tudo ou nada. E o volume do tráfego de auditoria em um controlador de domínio de empresa ocupado pode tornar a auditoria impraticável. A configuração do sistema de auditoria para produzir as mensagens realmente necessárias perdendo tempo com descritores de segurança individuais é monótona e sujeita a erros. As próprias mensagens de auditoria geralmente são cifradas e, em muitos casos, não contêm as informações de que você precisa, como os valores antes e depois de atributos alterados. Além disso, coletar, correlacionar e arquivar as mensagens de vários controladores de domínio não é viável com o uso de ferramentas nativas do Windows.
O sistema de auditoria dos serviços de diretório no Windows Server 2008 resolve alguns desses problemas. Primeiro, existem quatro novas subcategorias de auditoria para auditar serviços de diretório: Acesso DS, Alterações DS, Replicação DS e Replicação Detalhada DS. Assim, se você quer apenas auditar alterações no diretório, não precisa examinar todos os eventos de replicação e leitura. Porém, se você deseja incluir exclusões de objeto em seu log de auditoria, deve habilitar Acesso DS. Isso gera mensagens para todos os acessos de objeto DS, basicamente fazendo com que você volte a gerar mensagens em excesso. E ainda depende de você configurar ou não os descritores de segurança para gerar as mensagens de auditoria que deseja para os objetos com os quais se importa.
As mensagens de auditoria foram substancialmente limpas para que fiquem legíveis e contenham os dados necessários. Em especial, as alterações no diretório geram entradas de log de auditoria que contêm os valores novos e antigos de atributos alterados. Esse é um aprimoramento enorme. A única desvantagem aqui é que os valores novos e antigos aparecem em entradas separadas do log de auditoria, por isso você tem de correlacioná-las para compreender realmente a alteração que foi feita. Muitos dos produtos da coleção complementar de logs de auditoria, como os Serviços de Coleta de Auditoria da Microsoft, oferecem suporte a esse tipo de correlação.

Aprimoramentos na interface do usuário
Os snap-ins do MMC Usuários e Computadores do Active Directory, Domínios e Relações de Confiança, e Sites e Serviços sempre foram adequados para gerenciar o Active Directory. No Windows Server 2008, foram removidas as ferramentas administrativas básicas e introduzidos alguns recursos novos interessantes. Se você habilitar Recursos Avançados, a caixa de diálogo Propriedades referente a cada objeto exibirá uma guia adicional intitulada Editor de Atributos. Essa é mesma guia usada pelo ADSIEdit, que permite inspecionar e editar todos os atributos do objeto. A guia em si agora oferece melhor decodificação de atributos codificados, como o userAccountControl. A Figura 8 mostra o quão integrado está o editor de atributos.
Figura 8 Editor de atributos em Usuários e Computadores do Active Directory
Figura 8 Editor de atributos em Usuários e Computadores do Active Directory

Conclusão
Além dos pontos principais que discutimos neste artigo, existem muitos outros aprimoramentos que você encontrará no ADDS do Windows Server 2008. Por exemplo, o KDC usa a criptografia AES de 256 bits (AES-256) se o domínio está no nível funcional de domínio do Windows Server 2008. Você pode habilitar a Prevenção Contra Exclusão Acidental de objetos marcando a caixa apropriada na guia Objeto referente a qualquer objeto DS. O Mecanismo de Armazenamento Extensível que fornece o serviço de gerenciamento de dados foi aperfeiçoado para usar correção de erro de bit único, reduzindo a probabilidade de um erro de hardware ou software no subsistema de disco corromper a DIT. O serviço DNS começa a processar solicitações antes de carregar completamente o banco de dados DNS. O módulo do localizador de controladores de domínio foi aprimorado para que, caso não consiga localizar um controlador de domínio no site desejado, tente localizá-lo no próximo site mais próximo em vez de simplesmente usar qualquer controlador de domínio que puder encontrar no domínio. E agora NTDSUTIL dá suporte a RODCs e a instantâneos do Serviço de Cópias de Sombra de Volume.
Sem dúvida, o Windows Server 2008 oferece um número substancial de aprimoramentos nos Serviços de Domínio Active Directory. Juntas, essas alterações melhoram consideravelmente a segurança e a gerenciabilidade do ADDS. O melhor, porém, é que a integração do Windows Server 2008 ao ambiente do Active Directory não envolve uma migração massiva; é um processo fácil e incremental.

Gil Kirkpatrick é o Diretor de Tecnologia (CTO) da NetPro e desenvolve softwares para Active Directory desde 1996. Junto com Guido Grillenmeier, da HP, ele apresenta os conhecidos workshops sobre recuperação de desastres do Active Directory. Gil também é o fundador da Directory Experts Conference (vá para www.dec2008.com).


 Cobertura especial: Windows Server 2008: Introdu&#231;&#227;o ao IIS 7.0
Cobertura especial: Windows Server 2008 Isaac Roybal

Introdução ao IIS 7.0
Visão geral:
  • Alterações na arquitetura do IIS 7.0
  • Gerenciando o IIS 7.0
  • Compatibilidade retroativa
  • Solução de problemas do IIS 7.0

Cada departamento de TI é diferente, cada uma tem seu conjunto exclusivo de necessidades e objetivos, especialmente no que diz respeito à hospedagem de sites da Web ou serviços. Os servidores da Web podem precisar de um pouco de cada para atender aos requisitos da organização e ainda há o desafio de
reproduzir essa fórmula em vários servidores e, ao mesmo tempo, gerenciar tudo com eficácia. Algumas das alterações mais importantes no IIS 7.0 têm como objetivo fazer exatamente isso ao criar um servidor Web ou farms da Web.
À medida que analisei a lista de todos os excelentes recursos no IIS 7.0, fiquei muito empolgado em compartilhar com você esses recursos. Quando descobri que não seria possível cobrir todos neste artigo, decidi me concentrar em alguns dos recursos mais significativos e nas alterações mais importantes do IIS 7.0. Para obter mais niformações, acesse o site da Web da comunidade do IIS em IIS.net.

Arquitetura nova
As principais alterações no IIS 7.0 estão relacionadas à arquitetura, ao processamento de solicitações e ao suporte à estrutura de aplicativos PHP e ao armazenamento de configuração. Com o IIS 6.0, os recursos eram propostos na base do tudo ou nada. Você precisava instalar todos os recursos e poderia personalizar somente o IIS usando ISAPI.
O IIS foi desenvolvido com base na premissa de que um administrador da Web deseja iniciar a partir de um conjunto básico de funcionalidades e, então, adicionar somente a funcionalidade adicional necessária desejada em seu ambiente. Você conhece o seu ambiente melhor do que ninguém, portanto o IIS 7.0 lhe oferece blocos de criação para que você crie seu próprio servidor Web personalizado. Ao fazer isso, você reduz a sua sobrecarga administrativa ao diminuir a superfície de ataque do seu servidor e eliminar a necessidade atualizar componentes não utilizados. O segredo para essa nova abordagem é a arquitetura modular do IIS 7.0.
O IIS 7.0 tem um novo design que permite que você escolha a funcionalidade, chamada de módulo, a ser instalada no servidor. Esses módulos conectam-se diretamente no pipeline de solicitação integrado. Esse novo design modular tem várias vantagens, incluindo a redução da superfície de ataque e do seu servidor Web.
O IIS tem atualmente 40 módulos padrão – por exemplo, autenticação básica, anônima e do Windows® agora são módulos individuais que podem ser adicionados independentemente ao pipeline de solicitações. Para um esclarecimento simples, os módulos são agrupados em oito subcategorias (consulte a Figura 1).
Figura 1 Os módulos do IIS 7.0 são classificados em oito áreas funcionais
Figura 1 Os módulos do IIS 7.0 são classificados em oito áreas funcionais
Isso significa qeu você precisa ter a capacidade de criar um servidor Web personalizado desenvolvido exatamente para o seu ambiente. Mas se você precisar de funcionalidades que os 40 módulos padrão não fornecem, talvez algum tipo de autenticação personalizada ou modificador de conteúdo? Sem problemas. Você pode escrever um módulo no código nativo ou gerenciado para atender a essa necessidade e conectá-lo diretamente no pipeline. Isso também permite que a Microsoft escreva e lance novos módulos individualmente, de modo que você não precise aguardar o próximo service pack ou lançamento de produto importante. O IIS 7.0 também permite que você substitua qualquer um dos 40 módulos padrão por seus próprios módulos personalizados. Para obter mais informações sobre como criar seu próprio módulo, consulte IIS.net.

Pipeline de solicitação integrado
Considere o pipeline de solicitação integrado como um conjunto essencial de etapas lineares que devem ocorrer sempre que uma página for veiculada (como visto na Figura 2). Geralmente, algum tipo de autenticação deverá ocorrer, seguida pela autorização para recuperar o conteúdo, determinação e execução do manipulador necessário para esse conteúdo, execução de qualquer registro de log necessário e, finalmente, o envio da resposta. O pipeline de solicitação integrado fornece ao IIS 7.0 a flexibilidade para executar diferentes estruturas de aplicativo ao mesmo tempo. Por exemplo, você pode executar a autenticação por Formulários sobre o conteúdo PHP com um módulo de registro em log personalizado, tudo junto no mesmo pipeline.
Figura 2 Pipeline integrado e módulos do IIS 7.0
Figura 2 Pipeline integrado e módulos do IIS 7.0
Cada site da Web no servidor tem um pipeline de solicitação integrado e pode ser executado em um dos dois modos, Integrado e Clássico. O Integrado, por padrão, permite que partes específicas de funcionalidade sejam conectadas ao pipeline, oferecendo a você um controle granular do processo de solicitação. Para compatibilidade, o modo Clássico reproduz a funcionalidade IIS 6.0/ISAPI por meio de um módulo ISAPI no pipeline. Isso é muito útil ao migrar seus aplicativos para o IIS 7.0.

Instalação padrão
Agora, vamos falar sobre a configuração do seu novo servidor Web modular. Se você procura uma instalação padrão do IIS 7.0, observará que somente 10 módulos (se você incluir o Serviço de ativação de processos do Windows) serão incluídos. A instalação do IIS 7.0 fornece a funcionalidade básica do IIS ao instalar a Função de Servidor Web, especificamente os módulos necessários para veicular conteúdo estático, como HTML simples ou ASP clássico. O que for instalado no servidor depois será uma decisão exclusivamente sua. Veja a funcionalidade incluída em uma instalação padrão:
  • Os recursos HTTP comuns, como Conteúdo estático, Documento padrão, Pesquisa no diretório e erros HTTP
  • Recursos de integridade e diagnóstico, como o Log HTTP e monitor de solicitação
  • Recursos de segurança, como Filtro de solicitações
  • Recursos de desempenho, como Compactação de conteúdo estático
  • Ferramentas de gerenciamento, inclusive o Console de gerenciamento do IIS
  • Serviço de Ativação de Processos do Windows
Como se pode ver, esse é um servidor mínimo que não inclui ASP.NET ou outra nova funcionalidade do IIS 7.0, como os recursos de diagnóstico e solução de problemas. É simples habilitar mais funcionalidades no servidor, como a capacidade de fornecer conteúdo dinâmico, como ASP.NET e FastCGI (PHP). Selecione o conjunto de módulos que gostaria de instalar a partir de “Adicionar Serviços de Função” da Função do Servidor Web no gerenciador de servidores no Windows Server® Manager.

Novo armazenamento de configuração
Outra importante alteração no IIS 7.0 que facilitará sua vida é o novo armazenamento de configuração. A metabase, agora um componente instalado opcionalmente para compatibilidade retroativa, foi substituída por um sistema de configuração XML. Já posso ouvir você dizendo "Mas a metabase era XML!". Sim, era. Mas era complicada e não era fácil de ler (pelo menos não por humanos). Ela foi substituída por um sistema XML mais flexível. Como o ASP.NET, o IIS 7.0 usa arquivos .config – claros, simples, portáteis e fáceis de ler.
Migrar para esse formato significa que o sistema de configuração agora é independente da máquina, diferentemente da metabase, que era ligada por chave a uma máquina somente. Como resultado, agora você pode portar o sistema de configuração em outros servidores com uma simples ação de arrastar e soltar ou xcopy e assim por diante.
Esse novo sistema de configuração também funciona para farms da Web utilizando um novo recurso no IIS 7.0 denominado Configuração Compartilhada. Como esse novo sistema de configuração é portátil, você pode compartilhar um arquivo .config mestre entre todos os nós no farm. A configuração compartilhada permite que você exporte a configuração de um bom servidor conhecido de pré-produção e, em seguida, a compartilhe no seu ambiente de produção ou "dinâmico".
Ao exportar o arquivo .config, você deve fornecê-lo com uma senha de chave de criptografia. Isso protege o arquivo .config de um servidor Web não autorizado que tente imitar o .config do seu servidor sem autorização.
É simples habilitar a configuração compartilhada. No nó do servidor do Gerenciador do IIS, selecione Configuração Compartilhada, que está localizada na seção Gerenciamento do painel de tarefas. Basta marcar “Habilitar configuração compartilhada”, fornecer o caminho físico da configuração que você irá compartilhar (geralmente será um compartilhamento UNC), inserir as credenciais necessárias para acessar o caminho físico e clicar em Aplicar. Quando o arquivo .config for localizado, será solicitada sua senha de criptografia. Assim que esse processo for concluído, reinicie o Gerenciador do IIS de modo que ele selecione o novo .config.
A estrutura do novo sistema de configuração é diferente da que você costumava usar; portanto, vejamos as noções básicas. Como mostra a Figura 3, a configuração do IIS 7.0 foi dividida em duas categorias: configurações abrangendo o servidor e configurações específicas do site. Todas as configurações abrangendo o servidor são armazenadas no applicationhost.config, que está localizado no %systemroot%\windows\system32\inetsrv\config. Isso inclui todos os módulos instalados, sites no servidor e assim por diante. As configurações específicas do site são armazenadas em arquivos web.config individuais.
Figura 3 Há um arquivo .config para as configurações abrangendo o servidor e um individual separado para cada site da Web nesse servidor
Figura 3 Há um arquivo .config para as configurações abrangendo o servidor e um individual separado para cada site da Web nesse servidor
Se você já usou o ASP.NET, provavelmente está familiarizado com arquivos web.config. O IIS 7.0 utiliza arquivos web.config para armazenar configurações específicas de sites da Web individuais, como configurações de aplicativo e documento padrão do site, bem como configurações ASP.NET. Isso significa que você terá um arquivo web.config para cada site no seu servidor.
O arquivo web.config de um site da web está localizado no caminho físico do site, como %systemroot%\inetpub\wwwroot, por exemplo. Esse projeto aproveita as mesmas vantagens de portabilidade salientadas anteriormente, mas no nível do site. Você pode desenvolver facilmente um site em um servidor de teste, por exemplo, e então simplesmente arrastar e saltar, ou xcopy, os arquivos web.config e do aplicativo do site em um servidor de produção.
Sempre que você portar ou compartilhar arquivos .config, verifique as informações específicas da máquina, como endereços IP e letras de unidades. O IIS 7.0 fornece uma solução para essa supervisão com suporte a variáveis de ambiente de SO (como %systemroot%). Além disso, certifique-se de que o mesmo conjunto de módulos esteja instalado nos servidores de teste e produção. Isso ajudará a evitar erros de aplicativos não esperados. Também podem ocorrer erros se o web.config fizer referência a um módulo que não está instalado ou se um módulo padrão entrar em conflito com um módulo personalizado.

Gerenciando o seu servidor web
Então, agora que você tem esse servidor Web excelente, novo, personalizável, flexível e portátil. Como você fará para gerenciá-lo? O gerenciamento tomou grande parte do planejamento e da criação do IIS 7.0 e há várias formas para gerenciar tarefas administrativas.
As preferências de gerenciamento geralmente se encaixam em, pelo menos, uma de três categorias: administração pela interface do usuário com o recurso de apontar e clicar, inserção de comandos na linha de comando e escrita de scripts para automatizar o máximo possível. Vamos iniciar com a interface do usuário.
No IIS 6.0, o snap-in do MMC Microsoft® (Console de Gerenciamento Microsoft) tinha duas exibições básicas e conhecidas: o modo de exibição de árvore e em guias. Para examinar uma configuração, clique com o botão direito do mouse, selecione Propriedades e, em seguida, você verá várias guias, sem mencionar os botões de opções e caixas de seleção.
Felizmente, a interface do usuário no IIS 7.0 foi totalmente renovada. Essa interface do usuário, nomeada Gerenciador do IIS, foi desenvolvida para permitir uma abordagem orientada por tarefas, como mostra a Figura 4. Há também um Gerenciador remoto para clientes de nível inferior, como o Windows XP e o Windows Server 2003. Você pode baixá-lo do site IIS.net/downloads.
Figura 4 Nova interface do usuário no IIS 7.0
Figura 4 Nova interface do usuário no IIS 7.0
A nova interface do usuário consiste no painel Conexões, à esquerda, no painel Ações, à direita, e no painel de tarefas ou espaço de trabalho no centro. A árvore do gerenciador de conexão, à esquerda, é semelhante ao modo de exibição de árvore do IIS 6.0 com nós pai e filho. A novidade no modo de exibição em árvore é como criar novas conexões, salvar as atuais ou excluir as existentes. O painel de tarefas é a maior melhoria na interface do usuário, com dois modos de exibição para trabalhar. O modo de exibição de recursos elimina todas as propriedades configuráveis do IIS do antigo modo de exibição de "guias" e as agrupa por área administrativa, como IIS, gerenciamento e segurança.
As propriedades do ASP.NET também foram integradas ao Gerenciador do IIS, eliminando a necessidade de usar um snap-in do MMC adicional. Cada propriedade configurável tem seu próprio ícone, facilitando sua localização. E, como o Gerenciador do IIS foi desenvolvido como um aplicativo do Windows Forms, você pode adicionar facilmente ícones de plug-in para quaisquer módulos personalizados ou funcionalidades que escrever.
O segundo modo de exibição do painel de tarefas é o modo de exibição de conteúdo, que é muito semelhante ao IIS 6.0, pois o que você vê está em um diretório de conteúdo do site e é possível realizar ações em relação a esse conteúdo. O que há de novo aqui é a capacidade de selecionar uma parte específica do conteúdo, digamos, uma página da Web específica e, então, alternar para o modo de exibição de recursos, a fim de chamar determinadas configurações no conteúdo selecionado, que lhe fornece controle granular no nível de página.

Outras formas de gerenciar
Para os que preferem a linha de comando, há uma nova ferramenta poderosa denominada APPCMD.exe, que permite que você realize tarefas simples como interromper um site ou fazer backup do arquivo .config atual, bem como tarefas mais complexas, como pesquisa do esquema de configurações. A sintaxe é muito simples:
APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>.
TolistallobjectsavailabletoAPPCMD,type:
APPCMD /?
Ou, se você quiser ver os comandos disponíveis para um determinado tipo de objeto, digite:
APPCMD (object-type) /?
Para todos os codificadores existentes, uma API de código gerenciado denominada Microsoft.Web.Administration e um novo provedor de WMI foram adicionados ao IIS 7.0. Esses dois métodos abrem várias opções para ferramentas de script, automação e escrita para o gerenciamento do IIS 7.0. Ambos podem ser usados com o Windows PowerShell® e o provedor de WMI também pode ser usado com VBScript e JScript®. Para obter mais informações, consulte blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

Gerenciamento remoto e administração delegada
O IIS 7.0 oferece novas formas de gerenciar remotamente seu servidor, sites, aplicativos Web e direitos de administração delegada com segurança para não administradores. Primeiro, vamos falar sobre os novos recursos de gerenciamento remoto e como eles podem facilitar a sua vida.
Anteriormente, havia dois modos de gerenciar remotamente um servidor IIS: usando o site da Web de gerenciamento remoto ou usando os serviços de terminal/desktop para acessar a interface do usuário. Mas se você estiver fora do seu firewall ou não estiver no local, essas opções não são muito úteis. O IIS 7.0 soluciona isso ao criar recursos de gerenciamento remoto diretamente na interface do usuário que funcionam por meio de HTTPS amigáveis a firewall.
O gerenciamento remoto no IIS 7.0 facilita a vida de várias formas. Primeiro, você obtém a mesma experiência de interface caso estivesse conectado localmente. Segundo, não há necessidade de abrir portas no seu firewall, pois a comunicação ocorre via HTTPS. Por fim, agora você pode gerenciar vários servidores de uma única interface do usuário. Não há necessidade de ter várias janelas de site da Web remoto ou Desktop remoto abertas ao mesmo tempo.
O serviço de gerenciamento remoto real no IIS 7.0 é essencialmente um aplicativo Web pequeno, que é executado como um serviço separado, em uma conta de serviço local Windows NT® nomeada NT Service\WMSVC. Esse design mantém a funcionalidade de gerenciamento remoto mesmo se o servidor IIS por si só não responder.
Como a maioria dos recursos no IIS 7.0, para fins de segurança, o gerenciamento remoto não é instalado por padrão. Para instalar os recursos de gerenciamento remoto, adicione serviços de função à função do Servidor Web no Windows Server 2008 Server Manager, que pode ser encontrado em Ferramentas de gerenciamento. Assim que esse recurso estiver instalado, você então poderá habilitar as conexões remotas e iniciar o serviço WMSVC, pois ele é interrompido por padrão.
A configuração de inicialização padrão do serviço WMSVC é manual. Se você quiser que o serviço inicie automaticamente depois de uma reinicialização, precisará alterar a configuração para automática. Você também pode fazer isso através da linha de comando ao digitar:
sc config WMSVC start=auto
Ao habilitar conexões remotas por meio do serviço de gerenciamento, você verá uma lista de configurações, como Credenciais de identidade, Conexões e Restrições de endereço IPV4. A única decisão fundamental nesse momento é determinar a qual conjunto de credenciais de identidade conceder permissão para conexão com o IIS 7.0: somente credenciais do Windows ou credenciais do Windows e do Gerenciador do IIS.
A primeira opção é bastante óbvia, indicando que você pode permitir somente contas de usuário do Windows, sejam locais ou de domínio. A segunda opção envolve usuários do Windows e um tipo de conta que é completamente novo no IIS 7.0 e não está associado a contas de usuários do Windows: Usuários de Gerenciador IIS. Com Usuários do Gerenciador do IIS, os administradores podem criar contas de usuário conhecidas somente no contexto do IIS 7.0 e não ter acesso ao SO. Por fim, por padrão, o IIS fornece um certificado auto-assinado para iniciar, mas recomenda-se que você adicione um certificado SSL assinado válido. Agora, basta aplicar a sua configuração e iniciar o serviço.
Para obter controle e segurança adicionais, os administradores de TI têm a capacidade de delegar com segurança tarefas de administração de sites individuais ou aplicativos Web a não administradores.
A Administração delegada é essencialmente administração remota, mas ela limita o escopo do acesso a sites individuais ou aplicativos Web. O recurso Usuários do Gerenciador do IIS é especialmente útil aqui. Você pode criar usuários do IIS para esses proprietários isolados e delegar permissão para administração de seu próprio site ou aplicativo. Eles não têm acesso a configurações amplas de servidor e são limitados a configurações somente para seu site específico ou aplicativo Web.
Você também pode especificar quais recursos e configurações os usuários podem alterar e até mesmo quais aparecem na interface do usuário. Por exemplo, se você não quiser que alguém altere o tipo de autenticação usado para o site, poderá definir esse recurso como somente leitura ou não herdado. Quando um recurso for somente leitura, os usuários ainda poderão acessar o recurso e determinar a configuração, mas não poderão fazer alterações; e com essa configuração não herdada, o ícone de recurso não será exibido no modo de exibição do Gerenciador do IIS do usuário delegado. Esse tipo de delegação de recurso permite que você forneça acesso extremamente controlado aos outros sem fornecer controle administrativo no servidor Web.

Avançando para o IIS 7.0
Ao desenvolver o IIS 7.0, a equipe quis garantir que a transição fosse o mais tranqüila possível ao permitir o uso de alguns dos seus investimentos existentes em ferramentas de gerenciamento e scripts para o IIS 6.0. A compatibilidade retroativa do IIS 7.0 foi muito bem pensada, de modo que funcionaria com os seus scripts do IIS 6.0. Há um conjunto completo de ferramentas – desde a compatibilidade de metabase do IIS 6.0 ao real console de gerenciamento do IIS 6.0 – que você pode instalar no nó de compatibilidade de gerenciamento do IIS 6.0 na configuração.
A infra-estrutura de compatibilidade de metabase do IIS 6.0 utiliza um componente denominado ADOMapper. Ele permite que você execute os seus scripts metabase ADSI ou ABO do IIS 6.0 em relação ao novo sistema de configuração, limitando-o somente ao que o IIS 6.0 poderia fazer. Assim, não é possível ler nem gravar novas propriedades do IIS 7.0, acessar novos dados do tempo de execução nem ler ou gravar propriedades ou arquivos web.config do ASP.NET.

Diagnóstico e solução de problemas
O diagnóstico e a solução de problemas sempre foram questões que exigiram tempo. Analisar logs e tentar reproduzir um problema em um grande farm da Web ou até mesmo em um único servidor pode ser difícil. O IIS 7.0 tem uma ferramenta denominada Failed Request Tracing (Rastreamento de Solicitação Falha), a fim de ajudar você a economizar tempo e dores de cabeça. Ela pode ser útil em muitas situações, como quando uma solicitação é retida e produz erros ou para investigar problemas de autenticação e autorização.
A Failed Request Tracing usa as regras de rastreamento como um critério para a pesquisa de erros. As regras de rastreamento podem ser criadas para verificar tipos de comportamento ou erros ao especificar o tipo de conteúdo que você deseja rastrear (como todo o conteúdo no servidor, somente conteúdo ASP.NET ou conteúdo personalizado como PHP) e em quais condições o rastreamento deve ser iniciado (como em determinado código de status retornado, tempo para veicular a página, gravidade do evento ou uma combinação).
Suponha, por exemplo, que usuários relatem que um site está demorando muito para carregar. Esse é um cenário complicado para reproduzir em qualquer caso, mas especialmente se você tiver centenas de hits por hora. Com a Failed Request Tracing, você simplesmente adiciona uma regra de rastreamento para iniciar o log quando uma página demorar mais do que a quantidade de tempo desejada para carregar – nesse caso, diria dois segundos – e aguardar para que o servidor reproduza o problema por si só (consulte a Figura 5).
Figura 5 Usanso a Failed Request Tracing para a solução de problemas
Figura 5 Usanso a Failed Request Tracing para a solução de problemas
A diferença entre Failed Request Tracing e log tradicional é que o primeiro somente inicia o log quando um critério de solicitação com falha específico for detectado. O arquivo de log por si só é um XML com uma folha de estilos XML que o torna claro e de fácil leitura. Como a maioria dos outros recursos do IIS 7.0, ele não é instalado por padrão e pode ser localizado na seção de diagnóstico e integridade da configuração. Você também deve habilitá-lo no Gerenciador do servidor do IIS.
O IIS 7.0 é um excelente avanço para todos os administradores. Sua nova arquitetura e recursos fornecem a agilidade e a flexibilidade necessárias para adaptação ao seu ambiente em constantes alterações. Com os recursos de gerenciamento, ferramentas de compatibilidade retroativa e recursos de solução de problemas, já está pronto para ser implantado hoje e funcionar com o seu ambiente existente.

Isaac Roybal é gerente de produtos do Windows Server na Microsoft. Suas responsabilidades cobrem tudo relacionado à Web com o Windows Server. Isaac trabalha com o Windows Server desde o Windows NT 3.51 e o IIS 4.0. Antes disso, ele foi gerente do programa de operações do grupo de operações e plataforma de Internet do Office. Ele possui certificação MCSE do Windows NT 4.0, Windows 2000 e Windows Server 2003.


 Cobertura especial: Windows Server 2008: Acesso &#224; rede orientado a diretivas com o Windows Server 2008
Cobertura especial: Windows Server 2008 Ian Hameroff and Amith Krishnan

Acesso à rede orientado a diretivas com o Windows Server 2008
Visão geral:
  • Equilíbrio entre o acesso e a segurança de rede
  • Uma abordagem orientada a diretivas para o acesso à rede
  • Novas tecnologias de segurança no Windows Server 2008

Já se escreveu muito sobre o desaparecimento dos perímetros de rede tradicional decorrentes de uma crescente força de trabalho móvel e da crescente diversidade de usuários e dispositivos que requerem
acesso aos recursos de TI de uma empresa. Para acelerar a produtividade, os usuários e os proprietários da linha de negócios também estão criando uma demanda por experiência de conexão que seja fluida e sem procedimentos entediantes. Somam-se a essa situação já complexa as cargas de conformidade normativa, o cenário de ameaças em constante evolução e os riscos associados à descentralização de dados.
Isso tende a fazer com que os administradores do Windows® fiquem estagnados no meio de um desafiador equilíbrio de segurança: como permitir o fácil acesso a recursos e, ao mesmo tempo, atender aos crescentes requisitos de segurança de rede e informações.
Embora não haja uma única solução para todos esses desafios, como os administradores do Windows, você tem várias ferramentas à sua disposição que podem ajudá-lo a aprimorar os controles de segurança – como os firewalls de borda – já existentes. Uma excelente forma de obter o equilíbrio apropriado entre o acesso e a segurança é mudar de modelos de conectividade tradicionais para um que busque definir o acesso à rede de modo mais lógico e centralizado em diretivas.

Uma abordagem orientada a diretivas para o acesso à rede
Recursos de rede
  • IPsec
  • Firewall do Windows com Segurança Avançada
  • Isolamento do servidor e do domínio
  • Proteção de acesso à rede (NAP) do Windows Server 2008

O acesso à rede orientado por diretivas tem como objetivo eliminar as limitações existentes encontradas quando se tentar basear a confiança principalmente em bordas de topologia de rede. Por exemplo, você pode realmente determinar se um dispositivo é confiável e tem autorização para se conectar aos servidores que executam seu aplicativo CRM (gerenciamento de relacionamento com o cliente) apenas porque está conectado em uma das suas portas de comutador Ethernet atrás do firewall corporativo?
Em vez disso, o novo modelo orienta decisões de acesso ao autenticar a postura de segurança do dispositivo e a identidade do usuário solicitando acesso, não importa de onde ele esteja se conectando. Assim que for autenticado, essa mesma estrutura poderá então ser usada para autorizar quais informações e recursos podem ser acessados.
Mudar de uma postura defensiva para uma que é mais focalizada no acesso envolve vários itens fundamentais, incluindo ter mecanismos que possam validar a identidade e a conformidade com a diretiva dos hosts conectados, emitir uma identidade de usuário confiável e controlar dinamicamente o acesso à rede com base nesses atributos. Para simplificar o gerenciamento dessas várias partes dinâmicas, um armazenamento de diretiva centralizado também é um importante componente.
A adoção de uma abordagem orientada por diretivas pode ajudá-lo a transformar vários controles de segurança de host e acesso à rede possivelmente distintos em uma solução mais abrangente. Isso, por sua vez, permite que você defina as regras básicas de acesso à rede em uma camada lógica acima da trama da conectividade, evoluindo, assim, as tradicionais práticas recomendadas de defesa em profundidade.
Por exemplo, quando um usuário conecta seu laptop à rede sem fio da organização, o dispositivo pode ser verificado quanto à conformidade com os mais recentes requisitos de configuração de segurança. Assim que for determinado que o laptop tem todas as atualizações atuais de antivírus e patches de segurança fundamentais, além de todos os seus controles de segurança de ponto de extremidade habilitados – como um firewall de host – o acesso à rede corporativa poderá ser concedido. Então, quando o usuário tentar acessar um aplicativo comercial, a combinação do estado de integridade do laptop e a identidade de rede do usuário poderá ser usada para determinar se ele é autorizado para conexão com os recursos que hospedam o aplicativo. Ao operar em sua camada lógica sobre a infra-estrutura de rede física, as diretivas podem ser continuamente impostas, mesmo se o usuário mudar de uma conexão sem fio para uma com fio ou até mesmo uma conexão de acesso remoto.
Quando implementado, o acesso à rede orientado por diretivas pode fornecer uma experiência de conexão perfeita para os usuários, sem sacrificar a segurança no processo. Para os administradores, os controles de acesso à rede de nível superior a partir de portas de comutador ou configurações de gateway de acesso remoto podem fornecer uma experiência de gerenciamento mais simples. Em ambos os casos, o resultado final é maior produtividade e uma aperfeiçoamento geral da integridade da rede da empresa, mesmo quando as redes possam ser um host para partes com diferentes direitos de acesso, como convidados (convidados ou não), fornecedores, parceiros e funcionários.
Como com qualquer projeto de segurança, a primeira etapa na implementação de acesso à rede orientado por diretivas significa desenvolver um conjunto holístico de diretivas operacionais. Isso geralmente inclui diretrizes para:
  • Conformidade de segurança de dispositivos – o que significa integridade do dispositivo?
  • Zoneamento lógico de rede – como você irá segmentar dispositivos sem integridade de zonas autorizadas?
  • Gerenciamento de risco de informações – como os dados confidenciais são classificados e protegidos?
Felizmente, uma variedade de recursos de desenvolvimento de diretivas está disponível no Microsoft® TechNet Security Center (microsoft.com/technet/security).
Assim que você tiver desenvolvido as diretivas de acesso, precisará selecionar as tecnologias que possam ser facilmente distribuídas e aplicá-las com eficácia. Para isso, você não precisará ir além do Windows Server® 2008. Isso porque o Windows Server 2008 não é apenas o Windows Server mais seguro até o momento; ele também oferece aos administradores uma plataforma de segurança robusta que pode ser fundamental para a solução de acesso à rede orientada por diretivas. Entre essa longa lista de recursos novos e aprimorados, o Windows Server 2008 fornece muitos dos componentes necessários para implementar acesso seguro baseado em diretivas na sua rede, ajudando a garantir que as informações confidenciais sejam protegidas.

Sistema de rede de última geração
No núcleo dos avanços em segurança de rede no Windows Server 2008 está a Pilha TCP/IP de última geração, a principal atualização para a funcionalidade do sistema de rede da plataforma e serviços relacionados. Além de fornecer desempenho de rede aprimorado e maior escalabilidade, o Windows Server 2008 aprimora a segurança através de uma série de recursos de rede integrados que fornecem uma base sólida na qual pode ser desenvolvida uma solução de acesso à rede orientada por diretivas.
Um dos recursos significativamente atualizados no Windows Server 2008 foi o Internet Protocol security (IPsec), para que pudesse exercer uma função fundamental em uma abordagem de acesso à rede orientada por diretivas. Agora, isso não sginifica usar o IPsec como um protocolo de criptografia e encapsulamento, mas sim, aproveitar seus recursos de autenticação de rede de host para host. Além disso, como o IPsec funciona na Camada 3, ele pode ser utilizado para impor diretivas de acesso à rede em uma variedade de tipos de rede.
Para ajudar a facilitar a implementação de controles de acesso à rede baseados em IPsec, o Windows Server 2008 introduz uma longa lista de melhorias e novos recursos visando à simplificação da criação, imposição e manutenção de diretivas. Por exemplo, o número e os tipos de métodos de autenticação IPsec disponíveis aumentaram. Isso foi realizado por meio da introdução do IP autenticado (AuthIP), uma extensão ao protocolo IKE. O AuthIP permite que você crie regras de segurança de conexão (outro nome para as diretivas IPsec no Windows Server 2008) que requerem que pontos de comunicação se autentiquem com êxito, não somente com as credenciais da máquina, mas, opcionalmente, com as credenciais do usuário ou de integridade. Essa flexibilidade adicional permite a criação de redes lógicas muito avançadas sem a necessidade de atualizar sua infra-estrutura de comutação e roteamento.

Firewall do Windows com Segurança Avançada
o novo Firewall do Windows com Segurança Avançada foi desenvolvido com base nos recursos IPsec já descritos. Ao combinar as regras de segurança de conexão IPsec com filtros de firewall em uma única diretiva, o novo Firewall do Windows acrescenta outra dimensão de acesso à rede orientada por diretivas: ações de autenticação de firewall mais inteligentes.
Como mostra a Figura 1, agora você tem três opções de escolha ao definir a ação específica que um filtro de firewall de entrada ou saída pode realizar: permitir, bloquear ou permitir somente se seguro. Quando a opção "Permitir a conexão se for segura" for selecionada como a ação, o Firewall do Windows aproveitará os recursos de autenticação de rede de host para host do IPsec, a fim de determinar se um host ou um usuário solicitando conexão deve ser aprovado com base na diretiva definida por você. A regra de firewall permite que você estipule quais usuários, computadores e grupos têm o direito de fazer a conexão. É válido salientar que isso acrescenta uma camada adicional de proteção, suplementando controles de acesso de nível de aplicativo e sistema operacional existentes.
Figura 1 Definindo regras de firewall de autenticação
Figura 1 Definindo regras de firewall de autenticação
Agora, você deve começar a visualizar como é possível reunir esses diferentes controles de segurança de rede por meio de uma diretiva centralizada para um modo mais eficaz e escalonável de gerenciar o acesso à rede.
Retornando ao exemplo de CRM: o administrador poderia criar uma regra de entrada para os servidores executando o aplicativo CRM da empresa (através das portas de serviço ou executável do programa) com a opção “Permitir a conexão se for segura” marcada. Na mesma diretiva de firewall, o administrador poderá especificar que somente membros do grupo “Usuários de aplicativo CRM” poderão se conectar a esse aplicativo de rede, como mostra a Figura 2. Se você utilizar esse mesmo conceito e dimensioná-lo para todas as comunicações de rede entre todos os computadores gerenciados na sua rede, você terá adicionado uma camada de isolamento do servidor e do domínio à sua estratégia de acesso à rede orientada por diretivas.
Figura 2 Os administradores podem especificar quem pode se conectar com base nessa diretiva
Figura 2 Os administradores podem especificar quem pode se conectar com base nessa diretiva

Isolamento do servidor e do domínio
Com a maioria das empresas têm tido um número crescente de convidados e outros dispositivos não gerenciados se conectando às suas redes, torna-se cada vez mais fundamental ter meios para separar e proteger seus hosts confiáveis. A boa notícia é que há muitas formas de isolar computadores gerenciados e confiáveis de outros na rede. No entanto, você deve saber que muitas dessas opções são caras (por exemplo, a execução de sistemas de cabeamento físico separados) e difíceis de realizar manutenção (como VLANs baseadas em comutação) à medida que as redes crescerem.
O isolamento do servidor e do domínio pode fornecer um meio mais econômico e gerenciável para segmentar o seu ambiente em redes seguras e isoladas logicamente. Como a Figura 3 mostra, essencialmente você usa as mesmas regras de segurança de conexão (ou seja, as diretivas IPsec) mencionadas anteriormente, mas as mapeia para todos os seus computadores gerenciados por meio da Diretiva de grupo do Active Directory®. Isso resulta em uma diretiva de acesso à rede que requer que todos os pontos autentiquem-se com êxito entre si antes de iniciarem a comunicação. Como esse isolamento ocorre na Camada 3, a imposição desses controles de acesso distribui hubs, comutadores e roteadores em limites físicos e geográficos.
Figura 3 Definindo requisitos de autenticação para correspondência às suas necessidades de acesso de rede
Figura 3 Definindo requisitos de autenticação para correspondência às suas necessidades de acesso de rede
Para criar uma rede isolada, os vários computadores na rede devem ser separados de acordo com o tipo de acesso desejado. As diretivas podem ser definidas de tal forma que esses computadores em uma rede isolada possam iniciar comunicações com todos os computadore na rede, incluindo os não localizados na rede isolada. Ao contrário, os computadores que não estiverem na rede isolada não poderão iniciar comunicações com os computadores na rede isolada. Na verdade, os computadores na rede isolada irão ignorar todas as solicitações para comunicação dos computadores fora dessa rede isolada.
Um associação de domínio e domínio do Active Directory são usados para aplicar a diretiva de rede. Os computadores membros do domínio aceitam somente comunicações autenticadas e protegidas de outros computadores membros do domínio. Como opção, também pode ser estabelecido que toda a comunicação no domínio isolado seja criptografada.
O isolamento do servidor e do domínio fornece significativas vantagens econômicas sem que precisem ser feitas grandes alterações na infra-estrutura de rede ou em aplicativos existentes. Essa solução cria umaa proteção habilitada por diretiva, que não apenas ajuda na defesa contra ataques caros à rede e acesso não autorizado a recursos da rede confiável, mas também não requer manutenção contínua com base nas alterações na topologia de rede.

Proteção de acesso à rede
Como descrito anteriormente, a solução de isolamento do servidor e do domínio garante a separação lógica de vários computadores e servidores na rede. Embora essa solução ajude a impedir o acesso não autorizado à rede, não há garantia de que um computador autorizado não será a causa de uma ameaça de segurança.
A NAP (Proteção de acesso à rede) é uma plataforma interna no Windows Server 2008 que ajuda a garantir que os computadores que irão se conectar ou comunicar em rede atendam aos requisitos de integridade do sistema (ou seja, conformidade com diretivas e segurança) definidos por você.
Até mesmo os usuários autorizados são freqüentemente responsáveis pela propagação de vírus e spyware na rede. Por exemplo, quando um usuário sair de férias, seu computador poderá não seguir a conformidade com os requisitos de segurança definidos pelo administrador. Isso poderia ter repercussões potencialmente sérias se um patch ou assinatura obrigatória for lançado durante a ausência ao computador.
Mas está muito além da largura de banda disponível do administrador controlar cada usuário que se conecta à rede. O que é necessário é uma ferramenta automatizada que verifique a conformidade de integridade de cada computador se conectando à rede, solucionando qualquer um que não esteja em conformidade, tudo com base em uma diretiva central. O NAP faz isso apenas acrescentando outra camada à sua solução de acesso à rede orientada por diretivas.
O agente NAP – incorporado no SO do computador cliente (como no Windows Vista®) ou instalável separadamente (para versões anteriores do Windows, bem como sistemas operacionais não Windows) – relata qualquer problema de conformidade ao NPS, que é o mecanismo de diretiva interno no Windows Server 2008. É no NPS que você define as diretivas de conformidade às quais cada dispositivo deve aderir.
Embora seja necessário restringir os dispositivos que falharem nas verificações de conformidade, é importante garantir que eles tenham a opção de ficar em quarentena e serem solucionados. A NAP fornece a opção de solucionar automaticamente o dispositivo em casos em que o firewall ou solução antivírus for ativado ou solucionar manualmente o dispositivo ao colocá-lo na zona de quarentena. Aqui, o dispositivo tem acesso a um servidor de resolução com os mais recentes patches, atualizações e assinaturas. Assim que o usuário atualizar manualmente o dispositivo, ele terá acesso à rede, estando sujeito à aprovação da verificação de conformidade.
Com a onipresença, o acesso à rede se tornou muito mais simples. No entanto, isso criou uma carga a mais ao garantir que os dispositivos tenham integridade e estejam em conformidade, independentemente do mecanismo de acesso. Os computadores podem acessar a rede por meio de um comutador em conformidade com 802.1X ou ponto de acesso sem fio ou podem se conectar remotamente usando uma conexão de acesso remoto baseada em VPN ou Serviços de Terminal. A NAP não somente garante a conformidade para computadores que se conectam por meio desses diferentes mecanismos, mas também fornece imposição no servidor DHCP, comutador 802.1X, gateway de Serviço de Terminal ou ponto de acesso sem fio em conformidade com 802.1X.
Na Figura 4, a rede já foi isolada usando a solução de isolamento do servidor e do domínio. O uso da NAP com essa rede isolada fornece vantagens adicionais para garantir a conformidade de integridade a computadores conectando-se na rede. O cliente, na inicialização, envia sua declaração de integridade (SoH) à HRA, que é um servidor de certificado. A HRA envia a SoH ao NPS para validação da diretiva. Se a SoH for válida, a HRA emitirá ao cliente NAP um certificado de integridade e o cliente poderá iniciar a comunicação segura baseada em IPsec com recursos seguros. Se a SoH não for válida, a HRA informará ao cliente NAP como corrigir seu estado de integridade e não emitirá um certificado de integridade. O cliente NAP não poderá iniciar a comunicação com outros computadores que requeiram um certificado de integridade para a autenticação IPsec. No entanto, o cliente NAP poderá se comunicar com o servidor de resolução para ficar em conformidade.
Figura 4 Proteção de acesso à rede usando aplicação IPsec
Figura 4 Proteção de acesso à rede usando aplicação IPsec

Juntando tudo isso
Embora tenhamos apenas introduzido os novos recursos e funcionalidade no Windows Server 2008, é importante reconhecer como cada componente foi desenvolvido com base no anterior. O que transforma isso a partir da abordagem tradicional de defesa em profunidade é a estrutura de diretiva subjacente que o Windows Server 2008 oferece por meio, por exemplo, da Diretiva de grup do Active Directory.
Graças a essa experiência integrada, você terá uma base de trabalho sólida para definir e implantar uma solução de acesso à rede orientada por diretivas sem precisar se desfazer dos investimentos existentes. Ao migrar o acesso para uma decisão de camada centralizada em diretivas mais lógica, você terá a oportunidade de equilibrar o “Acesso fácil” versus “Maior segurança” a seu favor.
A Microsoft publicou importantes orientações sobre as áreas de tecnologia mencionadas neste artigo. Recomendamos primeiro que você leia estes artigos e guias passo a passo para obter experiência operacional com os vários recursos. (Os links na barra lateral “Recursos do sistema de rede” podem ajudá-lo a iniciar.) Em seguida, considere iniciar cada fase de modo que forneça uma base sólida para a próxima fase.
Por exemplo, crie um conjunto dessas regras de autenticação de firewall para seus aplicativos de missão crítica, como descrito na seção Firewall do Windows com Segurança Avançada. Assim que você estiver familiarizado com isso, poderá expandir as regras de segurança de conexão para isolar o seu domínio de rede e, em seguida, criar uma camada NAP para ele. As vantagens de implementar uma estratégia de acesso à rede orientada por diretivas pode ser muito significativa e ajudá-lo, inclusive, a acompanhar as constantes demandas nas redes corporativas.

Ian Hameroff é gerente de produto sênior no grupo de marketing de produtos de segurança e acesso na Microsoft. Ele é responsável pelo gerenciamento e marketing de produto das tecnologias de sistema de rede da plataforma Windows Server. Ian é responsável pela estratégia de lançamento no mercado do sistema de rede Windows Server e soluções com foco em iniciativas de segurança e rede, como isolamento do servidor e do domínio, sistema de rede escalável e adoção IPv6.
Amith Krishnan é gerente de produto sênior no grupo de marketing de produtos de segurança e acesso na Microsoft e é responsável pelo gerenciamento e marketing do sistema de rede Windows Server e iniciativas de segurança, como Proteção de acesso à rede e Segurança Sem Fio. Ele também desenvolve a estratégia de lançamento no mercado e incentiva o reconhecimento dessas soluções.


 Cobertura especial: Windows Server 2008: Configurando fun&#231;&#245;es com o Gerenciador do Servidor
Cobertura especial: Windows Server 2008 Byron Hynes

Configurando funções com o Gerenciador do Servidor
Visão geral:
  • A diferença entre funções e recursos
  • O que você pode fazer com o Gerenciador do Servidor
  • Trabalhando com assistentes
  • Gerenciando funções e recursos da linha de comando

Um dos temas que parece permear o Windows Server 2008 é que menos é mais. Eu não quero passar a idéia de eliminar desnecessariamente os recursos. Em vez disso, é a estratégia de simplicação e esclarecimento de funções e ferramentas para poder instalar exatamente o que você precisa – e nada mais. O Gerenciador do Servidor
é uma parte importante desse conceito no Windows Server® 2008.
Há dois aspectos nisso. O primeiro, é o conceito extremamente importante de funções e serviços de servidor, que são os blocos de criação do Windows Server 2008. O segundo, é a própria ferramenta Gerenciador do Servidor. Essa ferramenta não substitui apenas diversas ferramentas usadas no Windows Server 2003, mas também traz muito mais funcionalidade em um lugar para que administradores ocupados, como você, possam fazer muito mais de maneira mais rápida e fácil.

Funções e recursos
Se você tem lido sobre o Windows Server 2008, provavelmente já se deparou com alguns termos que nunca ouviu no contexto do Windows® antes, como “cargas de trabalho” e “funções”. Irei começar explicando o que esses termos significam para os profissionais do TI.
No começo do ciclo de desenvolvimento para o Windows Server 2008, nós gastamos muito tempo tentando descobrir exatamente como nossos usuários usam nossos produtos de servidor. (A propósito, esse esforço continua.) No geral, nós descobrimos que as pessoas implantam nossos servidores para fazer coisas específicas. Isso pode não parecer uma grande descoberta, mas abriu os olhos de alguns de nós para aprendermos que as pessoas não compram nossos servidores só para terem um. Mais importante, eles não implantam os servidores para executarem um grande número de tarefas. Em vez disso, eles querem que o servidor faça algo específico. Naturalmente, há exceções, mas, na maioria dos casos, um servidor é destinado para executar uma função específica.
Em resposta a essas revelações, agrupamos os “itens específicos” em classificações amplas, chamadas de cargas de trabalho. Por exemplo, existe uma carga de trabalho de banco de dados e uma carga de trabalho de servidor de aplicativo. Considerando que as cargas de trabalho são amplas e um pouco nebulosas de vez em quando, criamos subcategorias dentro das cargas de trabalho chamadas de funções. Uma função é algo único e muito específico que se espera que um servidor faça. Pense como você (e os usuários em sua organização) se refere aos servidores na sua rede. Se você for parecido com a maioria dos usuários, provavelmente pensa neles como o servidor de arquivo, o controlador de domínio, o servidor de impressão, o servidor da web e assim por diante. Como é assim que as pessoas tendem a pensar em relação aos servidores, o Windows Server 2008 usa a mesma abordagem para lidar com funções.
De forma ampla, há três principais categorias de funções no Windows Server 2008: o gerenciamento de identidades e acesso (aquelas funções conhecidas como parte do Active Directory®), Infra-estrutura (isso inclui servidores de arquivo, servidores de impressão, DNS, etc) e Aplicativo (como a função do Servidor da Web e os Serviços do Terminal).
Existirão cerca de 17 funções de servidor fornecidas com o Windows Server 2008 (isso inclui funções como Serviços de certificados do Active Directory, Serviços de acesso e diretiva de rede e Virtualização do Windows Server). E funções adicionais, como a função dos Serviços de mídia de streaming, provavelmente estarão disponíveis para download.
Cada função realmente merece seu próprio artigo. Algumas delas são discutidas mais minuciosamente nesta edição da TechNet Magazine, algumas já foram abordadas e outras ainda surgirão. Você deve explorar cada uma delas, começando com as informações disponíveis em technet2.microsoft.com/windowsserver2008/en/servermanager/default.mspx.
Quando você começar a implantação do Windows Server 2008, precisará escolher quais funções serão instaladas em cada servidor. Essa implantação com base em função é um conceito importante para o uso eficaz do Windows Server 2008 e é ágil na implantação de seus recursos.
A lista de funções não inclui itens como Criptografia de unidade de disco BitLockerTM e NLB (Balanceamento de carga da rede). Isso porque eles são recursos e, apesar de serem desejáveis, não são itens para os quais os usuários compram um sistema especificamente. As funções, por outro lado, representam tarefas para as quais os sistemas são comprados para executar. Por exemplo, os usuários não compram servidores para implementarem balanceamento de carga. Eles compram, no entanto, servidores para veicular um site da Web. E ainda que a NLB seja um aspecto essencial do servidor da Web, essa não é a finalidade para a qual o servidor existe.
Em vez de ter todos os recursos do servidor instalados e ativos, um administrador escolhe quais recursos necessitam ser instalados. (A lista de recursos incluídos com o Windows Server 2008 é mostrada na Figura 1.) Ao incluir apenas as funções e os recursos necessários, a estabilidade e a segurança são aprimoradas. Você não precisa se preocupar com recursos, pensando que eles serão consumidos por recursos ou funções não instalados. Além disso, não precisa se preocupar com os recursos de solução de problemas ou as funções de segurança não instalados.
Figure 1 Recursos incluídos no Windows Server 2008 (Close Figure 1)

Recursos do Microsoft .NET Framework 3.0
Criptografia de unidade de disco BitLocker
Extensões do servidor BITS
Kit de administração do Gerenciador de Conexão
Experiência Desktop
Gerenciamento de Diretiva de grupo
Cliente de Impressão na Internet
Internet Storage Name Server (iSNS)
Monitor de porta LPR
Fila de mensagens
E/S de caminho múltiplo
Protocolo PNRP
Quality Windows Audio Video Experience (qWave)
Assistência Remota
Ferramentas de administração de servidor remoto
Gerenciador de armazenamento removível
RPC sobre proxy HTTP
Serviços para NFS
Servidor de SMTP
Gerenciador de armazenamento para SANs
Serviços do TCP/IP simples
Serviços do SNMP
Subsistema para aplicativos baseados em UNIX
Cliente Telnet
Servidor Telnet
Cliente TFTP
Cluster de failover
Balanceamento de carga da rede
Backup do Windows Server
Gerenciador de Recursos de Sistema do Windows
Servidor do WINS (serviço de cadastramento na Internet do Windows)
Serviço de LAN sem fio
Banco de dados interno do Windows
Windows PowerShell
Windows Process Activation Service
O resumo desse conceito é a opção de instalação Server Core. O Server Core está além do escopo deste artigo, mas você pode ver a extensão lógica de selecionar funções e recursos não utilizados e nem mesmo copiá-los para o disco rígido ou torná-los disponíveis. A principal diferença entre uma instalação normal e uma instalação do Server Core é que a instalação normal inclui os recursos necessários para instalar funções adicionais a qualquer momento e é compatível com todas as funções. O Server Core, no entanto, nem mesmo tem uma interface gráfica do usuário para seu shell e é compatível apenas com um número limitado de funções.

Gerenciador do Servidor
O novo console do Gerenciador do Servidor no Windows Server 2008 facilita a tarefa de gerenciar e proteger várias funções do servidor em uma empresa. Essencialmente um MMC (Console de Gerenciamento da Microsoft®) expandido, o Gerenciador do Servidor permite que você veja e gerencie praticamente todas as informações e ferramentas que afetam a produtividade do seu servidor. Ele fornece uma única fonte para gerenciar a identidade do servidor e as informações do sistema, exibir o status do servidor, identificar problemas de configuração das funções do servidor e gerenciar todas as funções instaladas no servidor. (Observe também que ele substitui diversos recursos incluídos com o Windows Server 2003, como Gerenciar seu Servidor, Configurar seu Servidor e Adicionar ou Remover os Componentes do Windows.)
Em alguns casos, o Gerenciador do Servidor pode também reduzir a necessidade do administrador de executar o SCW (Assistente de Configuração de Segurança) antes de implantar os servidores. O Gerenciador do Servidor irá configurar seu servidor para que qualquer função instalada seja funcional – por exemplo, configurando o firewall do Windows automaticamente. Em casos, porém, em que as funções foram adicionadas e removidas, ou quando você quer ter mais controle sobre as configurações exatas de segurança, o SCW ainda é uma ferramenta valiosa. Para obter mais informações, consulte a coluna Security Watch de Jesper Johansson, “Usando o ACS no Windows Server 2008”, nesta edição (microsoft.com/technet/technetmag/issues/2008/03).
Quando trabalhamos no Windows Server 2008, tivemos um olhar aprofundado sobre como se espera que os administradores realizem tarefas. Descobrimos maneiras pelas quais as ferramentas e os assistentes facilitavam o trabalho e casos em que existia muita alternância de ferramentas. Nós definimos uma importante meta de projeto para o Windows Server 2008 em geral – e o Gerenciador do Servidor em particular – para tornar a administração do servidor mais eficiente com a permissão dos administradores de executar muitos tipos de tarefas em um só local. Como resultado, com o Gerenciador do Servidor você pode:
  • Visualizar e alterar as funções e recursos instalados no servidor.
  • Executar tarefas de gerenciamento que são relativas ao servidor, como iniciar e interromper serviços ou gerenciar contas locais de usuário.
  • Executar tarefas de gerenciamento relativas às funções instaladas no servidor.
  • Verificar o status do servidor, identificar eventos críticos e analisar problemas de configuração.
  • Instalar e remover funções, serviços de função e recursos usando uma interface gráfica do usuário ou linha de comando.
O Console do Gerenciador do Servidor apresenta várias informações e funcionalidades incluídas em um pequeno espaço. A Figura 2 mostra o nó da função dos Serviços de Arquivo no Console do Gerenciador do Servidor. A janela principal do console contém quatro seções recolhidas: Resumo de Servidor, Resumo de Funções, Resumo de Recursos e Recursos e Suporte.
Figura 2 O Console do Gerenciador do Servidor mostrando a Função dos Serviços de Arquivo
Figura 2 O Console do Gerenciador do Servidor mostrando a Função dos Serviços de Arquivo
A seção do Resumo do Servidor inclui duas subseções, Informações do Computador e Informações de Segurança. A subseção Informações do Computador exibe o nome do computador, o domínio, o nome da conta do Administrador local, as conexões de rede e a ID do produto do sistema operacional. Você também dispõe de comandos para editar essas informações. A subseção de Informações de Segurança exibe se as atualizações automáticas e o Firewall do Windows estão habilitados, bem como se a Configuração de segurança avançada do Windows Internet Explorer® está ativada (para administradores ou outros usuários). Do mesmo modo, há comandos disponíveis para editar essas configurações e para ver todas as opções avançadas.
A seção de Resumo das Funções contém uma tabela que indica quais funções estão instaladas no servidor. Os comandos nessa seção permitem adicionar ou remover funções ou ir para um console mais detalhado através do qual uma função específica pode ser gerenciada.
A seção de Resumo dos Recursos fornece uma tabela que mostra quais recursos estão instaladas no servidor. Aqui, como esperado, você pode adicionar e remover recursos.
Por fim, a seção de Recursos e Suporte indica se o servidor participa no Programa de Aperfeiçoamento da Experiência do Usuário e no Relatório de Erros do Windows e permite configurar a participação do servidor nos programas de feedback. Você também pode localizar rapidamente ajuda adicional relacionada e tópicos de pesquisa disponíveis nos TechCenters do Windows Server e Bibliotecas Técnicas.

Informações de função
Cada função instalada possui sua própria página inicial dentro do Gerenciador do Servidor. Para cada umas dessas páginas iniciais da função, a seção de Recursos e Suporte oferece um menu de configurações recomendadas ou cenários nos quais a função ou partes da função trabalham. Cada configuração recomendada se conecta a uma lista de verificação de ajuda que o guia através das tarefas que precisam ser executadas para criar a melhor experiência para uma determinada função.
Uma boa particularidade sobre o Gerenciador do Servidor é que informações e comandos importantes são exibidos, colocando-os exatamente onde eles são necessários. Quando, por exemplo, você estiver verificando a página inicial de função dos Serviços de Arquivo, verá imediatamente quaisquer eventos relacionados a essa função, sem precisar iniciar Visualizar eventos e criar um filtro.
No entanto, algumas funções podem gerar centenas de eventos, de modo que você também poderá personalizar filtros diretamente da página inicial da função. Você pode escolher Filtrar eventos no menu lateral e refinar ainda mais os eventos exibidos. Essa caixa de diálogo não fornece todas as opções de filtragem disponíveis no visualizador de log de eventos, mas permite que você se concentre rapidamente nos eventos relacionados a essa função específica e não em filtrar os outros.
Da mesma forma, você pode visualizar o status dos serviços do sistema (serviços necessários para essa função, mas parte do sistema geral) e serviços de função (serviços específicos para essa função). Para algumas funções, você pode escolher que partes de uma função estarão disponíveis e quais conjuntos diferentes de serviços de função serão instalados. Diretamente da página inicial da função, você pode iniciar e interromper serviços, bem como especificar quais serviços devem ser monitorados como serviços do sistema para a função.

Trabalhando com assistentes
Um assistente bem desenvolvido pode economizar seu tempo e ajudar a impedir erros, especialmente com tarefas realizadas ocasionalmente. As versões anteriores do Windows Server exigem que você use Configurar seu Servidor, Gerenciar seu Servidor e Adicionar ou Remover os Componentes do Windows para alterar os componentes instalados no seu servidor. As verificações de dependência eram limitadas, e os Componentes do Windows Adicionar ou Remover exigiam que a instalação de uma função tivesse sido concluída antes que outra fosse adicionada.
Agora, usando os assistentes do Gerenciador do Servidor, você pode instalar ou remover várias funções, serviços de função e recursos em uma só sessão. O que é mais importante, as verificações de dependência são realizadas à medida que você avança nos assistentes do Gerenciador do Servidor, assegurando que todos os serviços de função e funções sejam instalados. Além disso, as funções são definidas com configurações de segurança padrão recomendadas; no entanto, você pode usar o Assistente de configuração de segurança para modificar as configurações de segurança. Na verdade, o seu servidor está completamente pronto para implantação depois de uma única sessão em um dos assistentes do Gerenciador do Servidor.
O Gerenciador do Servidor tem vários assistentes, entre eles, o Assistente para Adicionar Funções, para Adicionar Serviços de Função, para Adicionar Recursos, para Remover Funções, para Remover Serviços de Função e para Remover Recursos.
O Assistente para Adicionar Funções, que, como você já deve ter adivinhado, é usado para adicionar funções ao servidor, verifica automaticamente se há dependências entre funções e se todas as funções e serviços de funções necessários estão instalados em cada função selecionada. Para algumas funções, como Serviços de Terminal e Serviços de Certificado do Active Directory, o Assistente para Adicionar Funções também fornece páginas de configuração que permitem que o usuário especifique como a função deve ser configurada como parte do processo de instalação. A Figura 3 mostra a página Selecionar Funções do Servidor do Assistente para Adicionar Funções.
Figura 3 Usando o Assistente para Adicionar Funções para selecionar funções de servidor
Figura 3 Usando o Assistente para Adicionar Funções para selecionar funções de servidor
A maioria das funções é composta de vários subelementos, aos quais o Gerenciador do Servidor se refere como serviços de função. Assim que uma função complexa estiver instalada, você poderá usar o Assistente para Adicionar Funções para adicionar serviços à função.
Semelhante ao Assistente para Adicionar Funções, o Assistente para Adicionar Recursos permite que você instale recursos. É possível adicionar um ou mais recursos ao sistema em uma única sessão.
O Assistente para Remover Funções, como seu nome indica, permite que você remova funções de um servidor. O assistente verificará automaticamente as dependências para garantir que quaisquer funções ou serviços de função necessários para as funções não removidas permaneçam instalados. Você também pode remover os serviços de função de uma função instalada usando o Assistente para Remover Serviços de Função. Ao passo que o Assistente para Remover Funções permite que você remova recursos do sistema.

A linha de comando
Às vezes, encontro profissinais de TI que simplesmente são relutantes em usar assistentes. Enquanto alguns são tão intensos em suas opiniões, muitos profissionais de TI gostam da opção de usar uma linha de comando. Elas podem ser mais convenientes, permitindo a simples repetição e script. O Gerenciador do Servidor oferece uma ferramenta da linha de comando, ServerManagerCmd.exe, que é notavelmente mais fácil do que as ferramentas anteriores, ocsetup e pkgmgr. Você pode usar o ServerManagerCmd.exe para instalar e remover funções, serviços de função e recursos. Além disso, você pode usar parâmetros simples para exibir uma lista de todas as funções, serviços de função e recursos – indicando os que estão instalados e os que estão disponíveis para instalação.
De modo conveniente, essa linha de comando permite que você execute a instalação autônoma e remoção de funções, serviços de função e recursos. Você também pode usar a linha de comando para instalar ou remover uma única função, serviço de função ou recurso em uma instância de comando, ou pode usar um arquivo de resposta XML com o comando do Gerenciador do Servidor para adicionar ou remover várias funções, serviços de função e recursos em uma única instância de comando. Além disso, você pode visualizar logs de operações e executar consultas para exibir listas de funções, serviços de função e recursos que foram instalados e os que estão disponíveis para instalação.
Um destaque dessa ferramenta da linha de comando é o parâmetro –whatif, que permite que você veja exatamente quais altearções seriam feitas no seu servidor se a função especificada estivesse instalada. Por exemplo, a Figura 4 mostra os resultados da execução do seguinte comando:
ServerManagerCmd -install Web-Server
-allsubfeatures -whatif
Evidentemente, você pode salvar isso em um arquivo para análise posterior.
Figura 4 Usando o parâmetro –whatif para ver quais alterações seriam feitas no servidor
Figura 4 Usando o parâmetro –whatif para ver quais alterações seriam feitas no servidor
Para obter uma análise mais profunda dos detalhes e sintaxe do ServerManagerCmd.exe, consulte "Apêndice de visão geral técnica do Gerenciador do Servidor", disponível em go.microsoft.com/fwlink/?LinkId=107113.
Gostaria de agradecer a Gaby Kaplan por sua contribuição neste artigo.

Byron Hynes é uma estrategista de tecnologia empresarial no grupo empresarial e de parceiros na Microsoft. Ele já trabalhou na divisão do Windows Server e como consultor e instrutor. Você pode contatá-lo pelo email bhynes@microsoft.com.


 Cobertura especial: Windows Server 2008: Implantando o Windows Server 2008 com o System Center
Cobertura especial: Windows Server 2008 Tim Mintner

Implantando o Windows Server 2008 com o System Center
Visão geral:
  • Recursos de implantação do Configuration Manager
  • Criando e personalizando uma seqüência de tarefas do servidor
  • Adicionando funções de servidor
  • Definindo variáveis específicas de computador

Com o lançamento do System Center Configuration Manager 2007, os administradores de servidor passam a poder aproveitar as mesmas ferramentas de implantação de sistemas operacionais que os administradores de cliente vêm
utilizando há anos. Antigamente, era comum os administradores de servidor executarem instalações manuais do Windows Server® usando o CD ou DVD e depois passarem horas configurando o servidor. Alguns administradores deram um passo à frente e compilaram rotinas de instalação autônoma criando um arquivo unattend.txt e usando o RIS (Serviços de Instalação Remota) para automatizar o processo de instalação, o que eliminou a necessidade de estarem fisicamente presentes no console do servidor. Administradores mais avançados aproveitaram o ADS (Automated Deployment Services) para Windows Server 2003 para automatizar completamente todo o processo de compilação do servidor. Agora, com o Windows Server 2008, o processo de instalação para servidores foi alterado consideravelmente – pela primeira vez desde o Windows NT® 4.0.
A implantação do Windows Server 2008 usa as mesmas tecnologias e ferramentas de implantação subjacentes que o Windows Vista®. Por causa dessa alteração, as ferramentas usadas pelos administradores de servidor no passado precisarão ser atualizadas ou substituídas. O RIS foi substituído pelo WDC (Serviços de Implantação do Windows®), e o ADS não oferece suporte à implantação do Windows Server 2008. Para obter mais informações sobre as tecnologias e ferramentas que sofreram alterações com a implantação de clientes e de servidores, consulte "Dez coisas que você precisa saber sobre a implantação do Windows Vista", em technetmagazine.com/issues/2006/11/Deployment.
Como as tecnologias subjacentes para implantar o Windows Server 2008 e o Windows Vista são idênticas, não seria ótimo se fosse possível usar as mesmas ferramentas e aproveitar o mesmo conhecimento para implantar ambas? O System Center Configuration Manager e o Microsoft® Deployment Toolkit agora fornecem esse conjunto de ferramentas integrado. Este artigo descreverá como o Configuration Manager pode ser usando em conjunto com o Microsoft Deployment para implementar o Windows Server 2008.

Implantação de sistemas operacionais com o Configuration Manager
Antes de começar a implantar o Windows Server 2008, vamos examinar os recursos de implantação de sistemas operacionais do Configuration Manager. Inicie o Configuration Manager Console (Console do Configuration Manager) e vá para Computer Management (Gerenciamento do Computador). Você observará uma nova área de aterrissagem referente para implantação de sistemas operacionais, como mostra a Figura 1.
Figura 1 A página Operating System Deployment (Implantação de Sistemas Operacionais)
Figura 1 A página Operating System Deployment (Implantação de Sistemas Operacionais)
Nesta página, você pode visualizar um resumo rápido das implantações de sistemas operacionais ocorridas em seu ambiente e navegar para outros nós da Operating System Deployment, como Manage Task Sequences (Gerenciar Seqüências de Tarefas) e Manage Boot Images (Gerenciar Imagens de Inicialização). Você encontrará uma lista de relatórios da Web para visualizar o status das implantações e a integridade do seu ambiente de implantação. Há também uma referência rápida em Resources (Recursos) que o vinculará à documentação de ajuda relativa à implantação de sistemas operacionais.
Se você observar abaixo dos nós no painel de navegação, poderá ver todos os itens que precisam ser configurados para executar uma implantação de sistemas operacionais. Veja a seguir um resumo deles:
Boot Images (Imagens de Inicialização) Contém uma lista de imagens de inicialização baseadas no Windows PE 2.0 que serão usadas durante o processo de implantação.
Computer Associations (Associações de Computador) Usado basicamente em implantações de clientes para mapear um computador existente para outro novo a fim de que o User State (Perfil do Usuário) possa ser gerenciado com segurança. Também contém um assistente para importar contas de computador desconhecidas para o banco de dados do Configuration Manager visando possibilitar a implantação de servidores bare-metal.
Operating System Images (Imagens do Sistema Operacional) Contém uma lista de pacotes que armazenam imagens WIM (Windows Imaging Format) personalizadas para implantação de clientes e de servidores.
Operating System Install Packages (Pacotes de Instalação do Sistema Operacional) Armazena pacotes que contêm o conjunto completo de arquivos de origem para uma implantação de sistemas operacionais, como os do Windows Server 2008.
Task Sequences (Seqüências de Tarefas) Contém várias etapas, sendo que cada uma define as ações de linha de comando que serão executadas sem interação com o usuário. As seqüências de tarefas são o mecanismo de controle do processo de implantação de sistemas operacionais e podem fornecer todas as etapas necessárias para implantar e configurar um sistema operacional.
Drivers Um repositório central para gerenciar todos os drivers necessários para os diversos modelos de computadores cliente e servidor.
Driver Packages (Pacotes de Driver) Contém um ou mais conjuntos de drivers que podem ser distribuídos para Configuration Manager Distribution Points (Pontos de Distribuição do Configuration Manager) e são usados durante a implantação de computadores cliente ou servidor.
Agora que temos uma compreensão básica dos recursos da implantação de sistemas operacionais do Configuration Manager, vamos juntar todas as peças necessárias para executar uma implantação do Windows Server 2008.

Preparando-se para implantar o Windows Server 2008
O que é o Microsoft Deployment?
O Microsoft Deployment é a próxima versão do Business Desktop Deployment (BDD) 2007. Ele reúne as ferramentas e os processos necessários para a implantação de servidores e de desktops em um console de implantação comum, além de uma coletânea de diretrizes. O produto adiciona novas funcionalidades de seqüenciamento de tarefas e de implantação para desktops e servidores que usam o System Center Configuration Manager 2007.
O Microsoft Deployment está disponível no Centro de Download da Microsoft, e as diretrizes podem ser lidas online nos Desktop Deployment e Server Deployment TechCenters do Microsoft TechNet. Para obter mais informações e links para esses destinos e outros conteúdos relacionados, visite microsoft.com/deployment.

Para implantar o Windows Server 2008 com o Configuration Manager, você precisa dos seguintes itens:
Microsoft Deployment Toolkit (MDT) Fornece ferramentas e documentação sobre práticas recomendadas para implantar sistemas operacionais cliente e servidor. Ele se integra diretamente ao Configuration Manager Console para simplificar o processo de implantação. Você pode baixar o Microsoft Deployment Toolkit em microsoft.com/deployment.
Custom Boot Image (Imagem de Inicialização Personalizada) O Configuration Manager fornece imagens de inicialização de 32 e 64 bits baseadas no Windows PE 2.0 e inclui o suporte ao VBScript, à WMI (Instrumentação de Gerenciamento do Windows) e a aplicativos HTML (HTAs). Entretanto, se você quiser que o seu processo de implantação solicite informações de um banco de dados SQL Server® separado, precisará de uma imagem de inicialização personalizada com suporte à ADO.
Operating System Install Package (Pacote de Instalação do Sistema Operacional) Contém os arquivos de origem do DVD do Windows Server 2008.
MDT Package (Pacote do MDT) Contém todos os scripts e arquivos de suporte necessários para o Microsoft Deployment Toolkit.
Configuration Manager Client Package (Pacote do Cliente Configuration Manager) Contém os arquivos de instalação do cliente Configuration Manager.
Settings Package (Pacote de Configurações) Contém o arquivo unattend.xml usado para uma instalação automatizada do Windows Server 2008, assim como o arquivo customsettings.ini usado com o Microsoft Deployment Toolkit.
Sysprep Package (Pacote do Sysprep) Usado somente na implantação do Windows Server 2003 ou do Windows XP, fornece os arquivos do Sysprep necessários para preparar um computador para capturar uma imagem do sistema operacional.
Drivers Contém todos os drivers necessários para determinados modelos de servidores.
Network shares for Package Sources and Captured WIMs (Compartilhamentos de rede para Origens do Pacote e WIMs Capturados) As localizações UNC nas quais serão armazenados os pacotes listados acima, juntamente com a imagem WIM personalizada.
Pode parecer que dá muito trabalho para criar todos esses pacotes, mas a boa notícia é que, com o Microsoft Deployment Toolkit, um assistente criará todos eles para você.
Para usar o Microsoft Deployment Toolkit com o Configuration Manager, você deve instalá-lo no mesmo computador que o console de gerenciamento do Configuration Manager. Depois disso, vá para Iniciar | Todos os Programas | Microsoft Deployment Toolkit e escolha Configure ConfigMgr Integration (Configurar Integração do ConfigMgr). Em seguida, especifique o nome do seu Configuration Manager Site Server (Servidor de Site do Configuration Manager) e o código do Site e clique em Next (Avançar). Isso adiciona extensões ao Configuration Manager Console fornecido pelo Microsoft Deployment Toolkit. Agora, quando você iniciar o Configuration Manager Console e clicar com o botão direito do mouse em Task Sequences, poderá ver uma nova opção, como mostra a Figura 2.
Figura 2 Import Microsoft Deployment Task Sequence (Importar Seqüência de Tarefas do Microsoft Deployment)
Figura 2 Import Microsoft Deployment Task Sequence (Importar Seqüência de Tarefas do Microsoft Deployment)
Escolha Import Microsoft Deployment Task Sequence e siga as etapas abaixo para criar os pacotes necessários e a seqüência de tarefas do Windows Server 2008:
  1. Na tela Choose Template (Escolher Modelo), selecione Server Task Sequence (Seqüência de Tarefas do Servidor) e clique em Next.
  2. Forneça um Task Sequence Name (Nome de Seqüência de Tarefas), descreva a seqüência usando comentários e clique em Next.
  3. Preencha os detalhes para ingressar em um domínio ou grupo de trabalho, como as credenciais da conta de usuário para ingressar o servidor no domínio. Preencha suas informações organizacionais e a chave do produto (Product Key) e forneça um nome de arquivo e um caminho UNC para a imagem WIM personalizada que será capturada. Forneça as credenciais do usuário para conectar-se ao compartilhamento de rede que armazenará o arquivo WIM e clique em Next.
  4. Na tela Boot Image (Imagem de Inicialização), escolha criar um novo pacote de imagens de inicialização, forneça um local de rede a ser usado como diretório de origem do pacote para esse novo pacote e clique em Next.
  5. Forneça um nome de pacote, informações de versão e comentários sobre o pacote de imagens de inicialização e clique em Next.
  6. Escolha uma plataforma (x86 ou x64), o suporte à ADO, qualquer fonte opcional de que precisar, um plano de fundo personalizado para a imagem de inicialização (se necessário) e qualquer pasta extra a ser incluída na imagem do Windows PE. Em seguida, clique em Next.
  7. Na tela MDT Package, escolha Create a new Microsoft Deployment Toolkit Files Package (Criar um novo Pacote de Arquivos do Microsoft Deployment Toolkit), forneça um caminho UNC a ser usado como origem do pacote e clique em Next.
  8. Forneça nome, versão, idioma, fabricante e comentários sobre o pacote MDT e clique em Next.
  9. Para a OS Image (Imagem do SO), escolha Create a new OS Install Package (Criar um novo Pacote de Instalação de SO), forneça o caminho para os arquivos de origem do Windows Server 2008 e uma localização UNC a ser usada como diretório de origem do pacote. Em seguida, clique em Next.
  10. Para o Client Package (Pacote do Cliente), escolha Create a new Configuration Manager client package (Criar um novo pacote do cliente Configuration Manager) e clique em Next.
  11. Para o Settings Package (Pacote de Configurações), escolha Create a new Settings Package (Criar um novo Pacote de Configurações) e forneça uma localização UNC a ser usada como origem do pacote para o Settings Package. Em seguida, clique em Next.
  12. Para o Sysprep Package (Pacote do Sysprep), escolha No Sysprep Files required (Nenhum arquivo do Sysprep necessário) e clique em Next.
Agora o assistente criará a imagem de inicialização e todos os pacotes. Se você expandir Packages (Pacotes), Boot Images, Operating System Install Packages e Task Sequences, poderá ver a seqüência de tarefas e os pacotes criados. Depois que todos eles forem gerados, deverão ser implantados em Distribution Points.
Além desses pacotes, quase sempre será necessário adicionar drivers para determinados hardwares de servidor. Faça isso adicionando drivers ao armazenamento correspondente do Configuration Manager e criando um Driver Package (Pacote de Drivers) que será usado durante a implantação.
Para importar drivers para o Driver Catalog (Catálogo de Drivers) e criar um Driver Package, vá para o Configuration Manager Console, clique com o botão direito do mouse em Drivers e selecione Import (Importar). Escolha importar todos os drivers no caminho UNC especificado e digite um caminho UNC que contenha todos os drivers reunidos para os modelos de servidor específicos. Quando terminar, clique em Next.
Na página Drivers Details (Detalhes de Driver), escolha quais arquivos INF deseja que sejam importados e, opcionalmente, atribua os drivers a uma categoria. (Uma categoria pode ser baseada em um tipo de modelo de servidor específico.) Clique em Next e, na página Add Drivers to Package (Adicionar Drivers a Pacote), clique em New Package (Novo Pacote). Especifique um nome, comentários e um caminho UNC que será usado como origem do pacote para o Driver Package. Em seguida, clique em OK. Escolha Update distribution points when finished (Atualizar pontos de distribuição quando terminar) e clique em Next.
Na página Add Driver to Boot Images (Adicionar Driver a Imagens de Inicialização), escolha a imagem de inicialização criada anteriormente e marque a caixa referente a Update distribution points when finished. Clique em Next e, na página de resumo, clique em Next novamente para concluir o assistente, importar os drivers e criar o Driver Package.

Editando a seqüência de tarefas
Agora que você terminou de criar a seqüência de tarefas e todos os pacotes necessários para instalar o Windows Server 2008, convém personalizar diversas ações na seqüência de tarefas padrão. Para modificar a seqüência de tarefas, clique nela com o botão direito do mouse e escolha Edit (Editar). O modelo de seqüência de tarefas do Microsoft Deployment Server (Servidor do Microsoft Deployment) será exibido, como mostra a Figura 3.
Figura 3 É possível personalizar a seqüência de tarefas padrão
Figura 3 É possível personalizar a seqüência de tarefas padrão
Em termos gerais, uma seqüência de tarefas é uma série de itens de linha de comando (conhecidos como tarefas) que executam operações específicas. Cada tarefa pode ter propriedades específicas configuráveis, além de condições definidas na guia Options (Opções) que avaliam se determinadas tarefas devem ser executadas. Por exemplo, a Figura 4 mostra as condições definidas para a primeira tarefa na seqüência de tarefas.
Figura 4 É possível desabilitar uma tarefa ou definir condições para ela na guia Options
Figura 4 É possível desabilitar uma tarefa ou definir condições para ela na guia Options
Neste exemplo, a tarefa está desabilitada por padrão porque a caixa de seleção "Disable this step" (Desabilitar esta etapa) foi desmarcada. Se a tarefa estivesse habilitada, ela seria executada somente com base nas condições especificadas no momento.
Algumas das tarefas mais comuns que talvez seja preciso modificar antes de implantar o Windows Server 2008 incluem Format and Partition Disk (Formatar e Particionar Disco), Validate (Validar), Apply Operating System Image (Aplicar Imagem do Sistema Operacional) e Apply Network Settings (Aplicar Configurações de Rede).
A tarefa Format and Partition Disk permite definir como você deseja criar a estrutura de partições de disco para as implantações do seu servidor. A configuração padrão cria uma partição que usa todo o espaço disponível no primeiro disco. Se você não quiser implantar os servidores com essa configuração, poderá alterá-la para especificar o layout de disco desejado.
A tarefa Validate permite verificar alguns requisitos básicos como memória e velocidade do processador. Se, por exemplo, o padrão da sua empresa para implantações de servidores for 2 GB de memória, você poderá defini-lo como requisito, e a instalação não continuará caso esse requisito não seja atendido pelo servidor.
A tarefa Apply Operating System Image permite configurar a imagem específica a ser implantada. Por exemplo, ao usar arquivos de origem do Windows Server 2008, você tem a opção de implantar Server Standard, Server Enterprise, Server Datacenter, Server Standard Core, Server Enterprise Core e Server Datacenter Core. A escolha da imagem apropriada a ser utilizada depende de qual versão do Windows Server 2008 você deseja implantar.
A tarefa Apply Network Settings permite configurar endereços IP estáticos para as placas de rede e alterar as configurações para ingressar em um domínio ou grupo de trabalho. Embora seja possível definir um endereço IP estático usando esta tarefa, isso tornaria essa seqüência de tarefas funcional apenas para um servidor. Mais tarde, você verá como definir endereços IP estáticos com variáveis para poder usar uma única seqüência de tarefas para vários servidores.

Instalando e configurando funções de servidor
Até agora, você viu como modificar a seqüência de tarefas para configurar itens relacionados à instalação do sistema operacional. Com o Microsoft Deployment Toolkit, porém, também é possível instalar e configurar funções de servidor. Por exemplo, você pode configurar uma seqüência de tarefas para implantar o Windows Server 2008 no servidor de uma filial que executará um controlador de domínio somente leitura e um servidor de arquivos.
Para fazer isso com êxito, no editor de seqüência de tarefas, navegue até a tarefa Install Software (Instalar Software) e escolha Add | MDT | Install Roles and Features (Adicionar | MDT | Instalar Funções e Recursos). Em seguida, na tarefa Install Roles and Features recém-criada, marque Active Directory Domain Controller (Controlador de Domínio do Active Directory) e File Server (Servidor de Arquivos), como mostra a Figura 5.
Figura 5 Instalando funções e recursos
Figura 5 Instalando funções e recursos
Agora é preciso definir as configurações do controlador de domínio somente leitura. No editor de seqüência de tarefas, escolha Add | MDT | Configure ADDS (Adicionar | MDT | Configurar ADDS). Na tarefa Configure ADDS recém-criada, escolha criar uma réplica do controlador de domínio somente leitura New (Novo) e especifique valores para as seguintes propriedades:
  • Existing domain DNS name (Nome de domínio DNS existente)
  • Replication source domain controller (Controlador de domínio da origem de replicação)
  • Account (Conta)
  • Recovery (safe mode) password (Senha [modo de segurança] de recuperação)

Trabalhando com variáveis
É importante que você entenda que um dos recursos mais avançados oferecidos pelas seqüências de tarefas aos usuários é a capacidade de definir praticamente qualquer propriedade na seqüência de tarefas dinamicamente como uma variável durante a implantação. O Configuration Manager e o Microsoft Deployment fornecem diversos mecanismos para definir e usar variáveis.
O Configuration Manager permite defini-las como uma variável Computer, uma variável Collection ou diretamente dentro da seqüência de tarefas. O Microsoft Deployment permite defini-las através do arquivo customsettings.ini, de um banco de dados back-end ou de um serviço Web. Em technet.microsoft.com/bb632442.aspx, você encontrará uma lista de variáveis que podem ser definidas.
Vamos usar como exemplo a definição de um endereço IP estático em um determinado servidor. Você viu anteriormente neste artigo que é possível definir o endereço IP estático dentro da seqüência de tarefas na tarefa Apply Network Settings. Contudo, isso não é o ideal, porque torna a seqüência de tarefas útil apenas para um determinado servidor.
Em vez disso, o que você deve fazer é deixar a seqüência de tarefas sozinha e definir o endereço IP através de uma variável. Veja a seguir o processo passo a passo da definição do endereço IP estático como uma variável Computer:
  1. No console do Configuration Manager, navegue para System Center Configuration Manager | Site Database | Computer Management | Collections (System Center Configuration Manager | Banco de Dados do Site | Gerenciamento do Computador | Coleções).
  2. Para atribuir uma variável por computador a um computador, localize e expanda a coleção à qual pertence o computador e clique com o botão direito do mouse no computador. Em seguida, clique em Properties (Propriedades) e depois na guia Variables (Variáveis).
  3. Para especificar variáveis personalizadas e seus valores associados, clique no ícone New (Novo) para abrir a caixa de diálogo <New> Variable (<Nova> Variável).
  4. Na caixa de diálogo <New> Variable, é necessário especificar um nome para a variável e se ela estará visível no console do Configuration Manager 2007. Para um endereço IP estático, você adicionaria as seguintes variáveis:
  • OSDAdapter0IPAddressList
  • OSDAdapter0SubnetMask
  • OSDAdapter0Gateways
  • OSDAdapter0DNSServerList
As variáveis configuradas devem ser semelhantes às exibidas na Figura 6.
Figura 6 Usando variáveis de computador para definir um endereço IP estático
Figura 6 Usando variáveis de computador para definir um endereço IP estático

Implantando a seqüência de tarefas
Agora que a seqüência de tarefas foi totalmente configurada e as variáveis foram definidas, você está pronto para implantar o Windows Server 2008. O Configuration Manager oferece diversos mecanismos para implantar um sistema operacional, como PreBoot eXecution Environment (PXE), mídia inicializável de seqüência de tarefas, mídia autônoma e através de um anúncio padrão para computadores existentes.
Para simplificar, descreverei como criar uma seqüência de tarefas para mídia inicializável. No console do Configuration Manager, navegue até Task Sequences e escolha Create Task Sequence Media (Criar Mídia de Seqüência de Tarefas) no menu Actions (Ações). Na página Select Media Type (Selecionar Tipo de Mídia), escolha Bootable Media (Mídia Inicializável) e clique em Next. Na página Media Type (Tipo de Mídia), especifique um CD como tipo de mídia e um nome para o arquivo de mídia. Na página Security (Segurança), você pode especificar uma senha para proteger a mídia ou um certificado auto-assinado. Em seguida, especifique a imagem de inicialização. Quando terminar, você será remetido à página Confirmation (Confirmação), na qual deverá clicar em Finish (Concluir). Para obter instruções detalhadas sobre como implantar o uso deste e de outros mecanismos, consulte a documentação em technet.microsoft.com/bb681029.aspx.

Conclusão
Neste artigo, você viu como usar o System Center Configuration Manager e o Microsoft Deployment para implantar o Windows Server 2008, adicionar funções como File Server e Domain Controller, definir variáveis específicas de computador e implantar o sistema operacional usando mídia inicializável de seqüência de tarefas. Embora as implantações de servidores reais possam ser muito mais complexas, este artigo deve ajudá-lo a começar a unificar suas ferramentas de implantação de clientes e de servidores.

Tim Mintner é engenheiro sênior de desenvolvimento de software na equipe do Microsoft Solutions Accelerator, com foco no Microsoft Deployment Toolkit. Ele tem mais de 14 anos de experiência trabalhando com clientes para implantar sistemas operacionais da Microsoft. Entre em contato com Tim pelo email tmintner@microsoft.com.


 Cobertura especial: Windows Server 2008: Auditoria e conformidade no Windows Server 2008
Cobertura especial: Windows Server 2008 Rob Campbell e Joel Yoker

Auditoria e conformidade no Windows Server 2008
Visão geral:
  • Importância crescente da conformidade
  • Compreendendo as alterações no ambiente
  • Desafios de auditar eventos de segurança
  • Aspectos técnicos da auditoria

No mundo da tecnologia da informação, as alterações são constantes. Se a sua organização de TI é como a maioria, você está sob crescente pressão para entender as alterações que ocorrem no ambiente. O impacto de erros administrativos e divulgações acidentais de dados aumenta na
mesma proporção que a complexidade e a escala dos ambientes de TI. A sociedade atual exige responsabilidade sobre tais eventos, por isso as organizações passaram a ser responsabilizadas legalmente pela guarda das informações sob seus cuidados.
Com isso, a auditoria de alterações no ambiente ganhou importância. Por quê? A auditoria fornece os meios para compreender e gerenciar alterações nos ambientes de TI atuais, que são grandes e altamente distribuídos. Neste artigo, abordaremos desafios comuns enfrentados pela maioria das organizações,o panorama de conformidade e regulamentação, algumas noções básicas de auditoria no Windows® e como a funcionalidade do Windows Server® 2008 e do ACS (Serviços de Coleta de Auditoria) do Microsoft® System Center Operations Manager 2007 pode complementar uma estratégia de auditoria abrangente.

Desafios de auditoria
Uma olhada rápida nas manchetes dos jornais mostra que a divulgação de dados está se tornando um problema cotidiano. Muitos desses incidentes envolvem ações legais, perdas financeiras e assuntos de relações públicas para as organizações responsáveis. A capacidade de explicar quais alterações ocorreram ou identificar problemas rapidamente é fundamental para reduzir o impacto dos incidentes de divulgação de dados.
Por exemplo, digamos que a sua organização é responsável pelo gerenciamento de informações de identificação pessoal (PII) de uma determinada base de clientes. Embora haja várias formas de proteger as informações contidas nos sistemas que você gerencia, o comprometimento pode acontecer mesmo assim. A auditoria apropriada pode permitir que a organização saiba exatamente quais sistemas foram comprometidos e, talvez, quais dados foram perdidos. Sem a auditoria, o impacto da perda de dados pode ser muito maior, principalmente porque não haveria como estimar a extensão do comprometimento.
Então, por que as organizações de TI já não estão fazendo isso? O fato é que a maioria delas não compreende plenamente os aspectos técnicos da auditoria. Embora a diretoria geralmente entenda conceitos como backup e restauração, a complexidade inerente de auditar alterações no ambiente é uma mensagem difícil de transmitir. Com isso, é comum surgirem perguntas sobre auditoria após um incidente significativo. Por exemplo, a auditoria básica pode estar habilitada, mas se, por falha no planejamento, o sistema não estiver configurado para auditar uma determinada alteração, essa informação não será coletada.
Além disso, os eventos de segurança auditados têm alguns problemas inerentes com os quais os profissionais de TI devem lidar. Uma dessas dificuldades é a distribuição de sistemas dentro dos grandes ambientes computacionais atuais, o que representa desafios de coleta e agregação consideráveis, já que as alterações podem ocorrer em qualquer sistema ou conjunto de sistemas a qualquer momento. Isso leva a outro desafio: correlação. A conversão de relações entre eventos em um ou vários sistemas quase sempre é necessária para atribuir significado real ao que está acontecendo.
Outro problema é que a auditoria geralmente transcende as fronteiras organizacionais tradicionais. Diferentes estruturas de equipe ou de organização existem por diferentes motivos e pode não ser fácil uni-las. Muitas organizações têm uma equipe de serviços de diretório, uma equipe de infra-estrutura de mensagens e uma equipe de desktops, mas provavelmente há apenas uma equipe de segurança responsável por todas essas áreas. E mais: os funcionários de segurança dedicados da sua organização podem não estar fisicamente presentes em todas as localidades. Por exemplo, as filiais costumam ter uma única pessoa ou uma equipe pequena para todas as tarefas, inclusive o gerenciamento de log de eventos da Segurança.
Finalmente, só a quantidade de eventos já é desafiadora. Os eventos de segurança auditados ocorrem com volumes muito maiores que outros tipos de log de eventos. O número de eventos coletados dificulta a retenção e a análise dos logs de modo eficiente. Além disso, ao estipular requisitos de retenção para essas informações, as regulamentações propostas e as atuais não ajudam a reduzir esse fardo nas infra-estruturas computacionais.
No passado, a auditoria de acesso a informações podia ser resumida como um desejo de saber e uma tentativa de se proteger. Hoje em dia, com as organizações – e a diretoria que responde por elas – sendo legalmente responsabilizadas pela perda de informações ou pela falta de medidas preventivas adequadas, é fundamental que os administradores de TI se familiarizem com as regulamentações aplicáveis a seus ambientes. No caso de empresas globais, os desafios são ainda mais complexos, já que cada país tem suas próprias regulamentações no tocante a informações e à proteção delas. Alguns exemplos de legislação já existente de conformidade a normas estão listados na Figura 1, juntamente com as respectivas expectativas para as organizações de TI.
Figure 1 Regulamentações e o que elas significam para profissionais de TI (Close Figure 1)

Regulamentação | Expectativa
Lei Sarbanes-Oxley de 2002 (SOX) | A Seção 404 reconhece o papel dos sistemas de informações e exige que empresas públicas forneçam uma análise anual de seus controles internos através de relatórios financeiros.
Lei HIPAA (Health Insurance Portability and Accountability Act) | Dirigida à segurança e à privacidade de dados de seguros de saúde; a "Regra de Segurança" abrange garantias técnicas, físicas e administrativas desses dados.
Electronic Discovery (eDiscovery) | Define padrões para o acesso a documentos e sua retenção, como a responsabilidade de quem acessa os documentos e de que forma.
Lei Federal de Gerenciamento de Segurança da Informação de 2002 (FISMA) | Mandato federal para fornecer uma estrutura abrangente de Segurança da Informação (INFOSEC) para sistemas do governo norte-americano, coordenação com várias autoridades competentes, estabelecimento de controles, confirmação de produtos comerciais e recursos de software. A Seção 3544 aborda responsabilidades das autoridades, como controles de TI.
Publicação 200 das Normas Federais de Processamento de Informações (FIPS) | Especifica os requisitos mínimos de segurança para informações federais e sistemas de informações, além de descrever o uso das recomendações contidas na Publicação Especial da NIST (SP) 800-53. Na NIST SP800-53, a seção AU-2 (Eventos auditáveis) especifica que os sistemas de informações devem fornecer os recursos para compilar registros de auditoria de vários componentes em uma trilha de auditoria relacionada ao tempo e válida para todo o sistema, para gerenciar eventos auditados por componentes individuais e para garantir que a organização analise periodicamente os eventos auditáveis.
Dada toda a pressão legal, o que se espera que os profissionais de TI façam? Os técnicos e gerentes de TI precisam criar uma história clara e concisa para apresentar a quem está dentro e fora da organização. Isso inclui o desenvolvimento de uma estratégia de auditoria apropriada, o que requer medidas pró-ativas e investimentos. O principal conceito aqui é que a auditoria não pode ser uma reflexão tardia no design, como quase sempre ocorre.
Desafios de TI desse tipo normalmente podem ser resolvidos por uma combinação de pessoal, processos e tecnologias. Com a auditoria, o que importa é o processo. Portanto, a primeira etapa deve ser dominar as noções básicas para poder responder às necessidades da organização e aos requisitos de conformidade a normas. Vamos abordar alguns dos fundamentos de auditoria no Windows e depois nos aprofundaremos nas alterações no Windows Server 2008 e no Windows Vista®.

Auditando eventos de segurança
Todos os eventos auditados são registrados no log de eventos da Segurança do Windows. Em geral, esses eventos não são podem ser acionados imediatamente e quase sempre são de natureza informativa. Cada evento registra um simples Êxito na Auditoria ou Falha na Auditoria para um tipo específico de acesso que tenha ocorrido. Isso é diferente dos logs de eventos do Sistema e do Aplicativo, nos quais os problemas podem ser identificados através da codificação de cores (dica: procure os eventos em vermelho para ir direto ao problema).
O log de eventos da Segurança é diferente porque é comum os eventos auditados serem ocultados pelo volume e, conforme observado anteriormente, a correlação de dados de segurança pode representar um desafio significativo. Mesmo uma simples violação de dados em um único sistema é problemática. O log de eventos da Segurança precisaria ser analisado para identificar qual conta foi usada para acessar os dados, exigindo que um administrador rastreasse o log para tentar localizar a conta. Infelizmente, os ataques sofisticados de hoje em dia costumam ser coordenados e distribuídos, tornando esse tipo de análise bem difícil para a vítima.
Isso posto, é importante compreender os elementos principais que permitem o registro de informações no log de eventos da Segurança no Windows: Diretiva de Auditoria e SACLs (listas de controle de acesso do sistema). As Diretivas de Auditoria são configurações para um computador local feitas através da Diretiva de Grupo ou da Diretiva de Segurança Local e definem a coleção de eventos de êxito e de falha para tipos específicos de acesso. Estas principais categorias de Diretiva de Auditoria estiveram presentes no Windows durante muitos anos (informações sobre a nova Diretoria de Auditoria Granular do Windows Server 2008 mais adiante):
  • Eventos de logon de conta de auditoria
  • Auditoria de gerenciamento de contas
  • Auditoria de acesso ao serviço de diretório
  • Eventos de logon de auditoria
  • Acesso a objetos de auditoria
  • Alteração de diretiva de auditoria
  • Uso de privilégios de auditoria
  • Auditoria de controle de processos
  • Eventos de sistema de auditoria
A necessidade de definir Diretiva de Auditoria e suas respectivas categorias normalmente é bem compreendida pela maioria das organizações de TI, mas a Diretiva de Auditoria representa apenas uma parte da solução. As SACLs também desempenham um papel significativo na implementação de um plano de auditoria holístico. Duas categorias de Diretoria de Auditoria específicas – Auditoria de acesso ao serviço de diretório e Acesso a objetos de auditoria – são totalmente dependentes das SACLs para retornar informações sobre o log de eventos da Segurança. Então, o que são exatamente as SACLs?
Cada objeto – arquivo, Registro ou serviço de diretório – tem uma ACL (lista de controle de acesso) com uma ou mais ACEs (entradas de controle de acesso) divididas em dois tipos: uma DACL (lista de controle de acesso discricionário) e uma SACL (a qual define configurações que registram em log as tentativas de acesso a objetos protegidos). Cada ACE em uma SACL determina os tipos de tentativas de acesso por um objeto de confiança especificado que deverão ser registrados no log de eventos da Segurança. As ACEs definem o log de tentativas de acesso com êxito e/ou falha em relação a objetos especificados. A Figura 2 mostra o uso de uma SACL em um objeto para gerar eventos para tipos específicos de acesso.
Figura 2 Usando uma SACL em um objeto
Figura 2 Usando uma SACL em um objeto
A compreensão da relação entre Diretiva de Auditoria e SACLs é fundamental, pois a configuração é necessária para capturar os eventos auditados "corretos", já que está relacionada a alterações no ambiente. Conforme mencionado, as diretivas Auditoria de acesso ao serviço de diretório e Acesso a objetos de auditoria permitem a geração de auditorias no log de eventos da Segurança apenas para essas categorias específicas, mas os eventos só serão gerados se um objeto tiver uma ACE de auditoria configurada em sua SACL. Depois de tudo implementado, os eventos de segurança são gerados pela autoridade de segurança local do Windows (LSA) e gravados no log de eventos da Segurança.
Os eventos consistem em duas áreas distintas: o cabeçalho, que é estático e predefinido para cada identificador de evento (ID do Evento), e o corpo, que é dinâmico e contém detalhes diferentes para diferentes eventos. A Figura 3 mostra esses dois elementos em um exemplo de evento de segurança do Windows Server 2008. Importante para a fase de análise de qualquer projeto de auditoria, a compreensão desses componentes de eventos é de particular interesse com respeito ao modo de retorno das informações em ferramentas como o ACS.
Figura 3 O cabeçalho e o corpo de um evento auditado
Figura 3 O cabeçalho e o corpo de um evento auditado

Windows Eventing 6.0
Agora que compreendemos o problema, como o Windows Server 2008 ajuda as organizações a enfrentarem os desafios? O Windows Server 2008 é a primeira versão de servidor a conter o novo subsistema de eventos Windows Eventing 6.0, que melhorará expressivamente o panorama em torno do gerenciamento de eventos de segurança. Observe que, embora o foco aqui seja o Windows Server 2008, 95% do novo conjunto de recursos também existe no Windows Vista.
Uma das novidades no Windows Eventing 6.0 que muitas pessoas logo observarão é a interface do usuário. O novo snap-in MMC (Console de Gerenciamento Microsoft) de Visualizar Eventos oferece uma excelente página Visão Geral e Resumo, Modos de Exibição Personalizados flexíveis e Texto Explicativo amplamente aprimorado. Essas interfaces podem ajudar o usuário final ou administrador do sistema a localizar informações de eventos e configurar importantes opções de log de eventos diretamente no próprio Visualizar Eventos.
Um grande problema que costumava impactar os dados de segurança dentro do log de eventos era a retenção de dados. Anteriormente, o subsistema Log de Eventos (incluindo todos os logs) possuía limites de escalabilidade. Caso eles fossem excedidos, o subsistema inteiro parava de registrar eventos em log. Porém, esse não é o caso no Windows Eventing 6.0, e agora as organizações estão limitadas apenas pela quantidade de espaço em disco disponível. Mas observe que a análise de logs de eventos muito grandes pode ser complicada, já que cada entrada de log individual deve ser avaliada durante a filtragem. Por isso, é certo que você vai querer manter seu log em um tamanho gerenciável.
Obviamente, isso ainda deixa para o administrador de TI a tarefa de desenvolver um plano de arquivamento para logs de eventos em relação a muitos sistemas. Para ajudar a fazer isso no nível do servidor local, um recurso exposto no Windows Eventing 6.0 é a opção "Arquivar o log quando estiver cheio; não substituir eventos". Nas versões anteriores do Windows, essa opção podia ser definida através de modificação no valor do Registro AutoBackupLogFiles. Embora isso forneça um mecanismo para arquivo morto local de logs, não oferece uma solução para o gerenciamento desses arquivos ao longo do tempo, nem resolve o problema de agregação que ocorre em vários sistemas. Os Serviços de Coleta de Auditoria não oferecem uma solução completa para isso. Falaremos sobre esse assunto mais adiante.
A nova interface é apenas o começo. A verdadeira força do Windows Eventing 6.0 é o novo serviço Log de Eventos do Windows e o mecanismo subjacente baseado em XML. São esses componentes que geram as opções de gerenciamento, acessibilidade e escalabilidade aprimoradas. Os eventos passam a ser armazenados em um formato XML flexível que permite soluções personalizadas capazes de canalizar essas informações nativamente.
O Windows Eventing 6.0 também possibilita associar ações administrativas a eventos específicos. Ele faz isso integrando o serviço Coletor de Eventos do Windows ao Agendador de Tarefas para fornecer eventos baseados em tarefas. Esse é um novo paradigma do Agendador de Tarefas, que antes era limitado a eventos disparadores baseados em tempo. O assistente "Anexar Tarefa a este Evento" (disponível no menu de contexto de qualquer evento no Visualizar Eventos do Windows Server 2008) proporciona uma maneira fácil de iniciar um programa, enviar um email ou exibir uma mensagem sempre que um evento específico é registrado em log. Isso pode ser muito útil quando se tenta identificar ações específicas em andamento no ambiente que podem ser isoladas para um evento de segurança específico. Por exemplo, se você estiver auditando alterações na chave do Registro "Schema Update Allowed" em seus controladores de domínio, poderá criar uma tarefa que envie um email para administradores de segurança específicos a fim de notificá-los quando essa chave do Registro for modificada.
Além da nova capacidade de coletar e armazenar um grande número de entradas de evento, agora você também pode controlar melhor quais eventos são registrados no log de eventos. Isso é realizado através de um novo recurso chamado Diretoria de Auditoria Granular (GAP). Nas versões anteriores do Windows, era comum as nove categorias amplas de auditoria resultarem em sobrecarga de eventos. Agora, essas categorias de nível superior podem ser controladas por 50 subcategorias granulares, cada uma representando um subconjunto relacionado de eventos.
Isso permite filtrar informações não-críticas do log de eventos sem perder a visibilidade no nível de categoria. Por exemplo, se você quiser monitorar alterações em um determinado sistema apenas no Registro, mas não no sistema de arquivos, a única opção anteriormente era relatar êxito ou falha na categoria Acesso a Objeto. Com o GAP, é possível filtrar subcategorias como Sistema de Arquivos, Serviços de Certificação e Compartilhamento de Arquivos e só relatar eventos na subcategoria Registro. Para explorar as subcategorias do GAP em um sistema do Windows Server 2008, você deve executar o comando Auditpol a partir de um prompt de comando elevado. Para listar as subcategorias do GAP disponíveis, digite:
auditpol /list /subcategory:*
Para obter uma lista de subcategorias do GAP configuradas em seu sistema, digite:
auditpol /get /category:*
Observe que o GAP não pode ser configurado por meio da interface do usuário de Diretiva de Grupo padrão e deve ser gerenciado através de auditpol.exe. O artigo da Base de Dados de Conhecimento em support.microsoft.com/kb/921469 fornece diretrizes sobre como implantar configurações do GAP através da Diretiva de Grupo para subsistemas do Windows Server 2008 e do Windows Vista.
O Windows Server 2008 também pode capturar os valores antigos e novos dos tipos específicos no log de eventos da Segurança. Nas versões anteriores do Windows, o subsistema de auditoria só registrava em log o nome do valor do Registro ou do atributo de objeto do Active Directory® que tinha sido alterado, e não o valor anterior e o atual do atributo. Esse novo recurso se aplica aos Serviços de Domínio Active Directory, ao Active Directory Lightweight Directory Services e ao Registro do Windows. Com a habilitação de Êxito na Auditoria ou Falha na Auditoria nas subcategorias de "Registro" ou "Alterações no Serviço de Diretório" e a definição das SACLs associadas, os eventos detalhados serão gerados no log de eventos para ações nesses objetos. Isso pode ser feito com o uso dos seguintes comando auditpol:
auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service
    Changes" /success:enable
No caso de alterações no Registro, elas aparecem como eventos com a identificação 4657, como mostra a Figura 4.
Figura 4 Antes e depois de uma alteração no Registro
Figura 4 Antes e depois de uma alteração no Registro
Este recurso é particularmente útil quando se tenta rastrear alterações em objetos do Active Directory. No caso de Alterações no Serviço de Diretório, elas aparecem em um par de eventos com a identificação 5136, como mostra a Figura 5. Cada evento tem um serviço de diretório de objeto, de atributo e de operação no corpo do evento. Para alterações em atributos com dados existentes, vemos duas operações: Valor Excluído e Valor Adicionado. Para atributos que não tenham sido populados, só veríamos a operação Valor Adicionado quando os dados fossem gravados nesse atributo. Por exemplo, quando uma operação de modificação é executada com êxito em um atributo de um objeto de usuário, como telephoneNumber, o Active Directory registra em log o valor anterior e o atual do atributo em entradas detalhadas do log de eventos.
Figura 5 Antes e depois de um evento Alterações no Serviço de Diretório
Figura 5 Antes e depois de um evento Alterações no Serviço de Diretório
Se um novo objeto for criado, os valores dos atributos que foram populados na época da criação do objeto serão registrados em log. Se um objeto for movido dentro de um domínio, o novo local e o anterior (na forma do nome distinto) serão registrados. Esse recurso "antigo e novo" é habilitado por padrão quando as configurações de Diretiva de Auditoria apropriadas são implementadas. Se você quiser manter um atributo em sigilo (como alterações no número de identificação dos funcionários, por exemplo), poderá excluir especificamente os atributos fazendo uma simples modificação de esquema. Modificando a propriedade searchFlags do atributo no esquema para 0x100 (valor 256 -NEVER_AUDIT_VALUE), como mostra a Figura 6, o evento Alterações no Serviço de Diretório não será gerado quando as alterações no atributo ocorrerem.
Figura 6 Excluindo um atributo de Alterações no Serviço de Diretório
Figura 6 Excluindo um atributo de Alterações no Serviço de Diretório
Finalmente, um dos novos recursos incríveis do Windows Eventing 6.0 é Inscrições de Eventos. Como mencionado anteriormente, o acesso ao log de eventos e sua análise é uma tarefa essencial de administração do sistema. Esse novo recurso permite encaminhar eventos entre sistemas. Ele consiste em um Coletor de Eventos que agrupa eventos e Fontes de Evento configurados para encaminhar eventos para hosts especificados. A capacidade de consumir eventos é fornecida pelo serviço Coletor de Eventos do Windows (novo no Windows Eventing 6.0), e a funcionalidade de assinante está integrada ao serviço Log de Eventos do Windows. Um coletor pode ser configurado para agrupar eventos de muitas fontes de evento, que podem ser os sistemas Windows Server 2008 ou Windows Vista.
Todos os dados coletados de fontes de evento residem em um Log de Eventos distinto, chamado Eventos Encaminhados (ForwardedEvents.evtx) e são gerenciados pelo serviço Log de Eventos no coletor. A configuração nos dois pontos de extremidade (coletor e fonte) é necessária e pode ser automatizada (winrm quickconfig –q na fonte; wecutil qc /q no coletor). É importante observar que esse recurso de inscrição de eventos não foi projetada para empresas ou para substituir sistemas que entregam eventos a um banco de dados externo.
Um exemplo de onde esse recurso pode ser aproveitado é uma pequena web farm. Suponha que você tem um conjunto pequeno de sistemas associado a um determinado site (inclusive servidores Web e servidores SQL). Esses sistemas podem consolidar as informações do seu log de eventos da Segurança em um único sistema usando o novo recurso Inscrições de Eventos. Ambientes maiores normalmente requerem um conjunto de ferramentas mais avançado para consolidação de log de eventos.

Serviços de Coleta de Auditoria
Considerando todos os novos recursos do Windows Server 2008, a solução real para gerenciamento a longo prazo e arquivamento de informações do log de eventos da Segurança reside em um banco de dados centralizado de informações de auditoria. Os Serviços de Coleta de Auditoria são um dos principais recursos do System Center Operations Manager 2007. O ACS fornece um mecanismo para o encaminhamento, a coleta, o armazenamento e a análise de dados de eventos de segurança. Os eventos de segurança são coletados quase em tempo real e armazenados em um repositório central do SQL. O ACS também oferece às organizações um método de conceder acesso de privilégio mínimo para auditar informações, já que não é necessário nenhum acesso físico aos sistemas que realmente estão sendo auditados. Vejamos como o ACS funciona.
O ACS possui três componentes principais. O primeiro é o Encaminhador, que é a parte do agente do Operations Manager que transmite os dados do log de eventos do cliente para a infra-estrutura do ACS. Os encaminhadores transmitem dados para o segundo componente, o Coletor, que é o ouvinte do servidor. Os Encaminhadores ACS se conectam pela porta TCP 51909 a fim de se comunicarem com o Coletor atribuído de forma segura. Antes da transmissão, os dados do log de eventos são normalizados no XML, o que significa que o excesso de informações será removido e as informações de eventos serão resumidas em campos mapeados com base em informações de cabeçalho e de corpo específicas do evento. Quando as informações chegam ao coletor, elas são enviadas para o terceiro e último componente – o banco de dados ACS. Ele se torna o repositório para armazenamento a longo prazo de informações de eventos de segurança. Depois de armazenadas, as informações podem ser extraídas através de consultas SQL ou processadas por meio de relatórios HTML usando o SQL Server® Reporting Services. O ACS fornece três exibições padrão, como mostra a Figura 7.
Figure 7 Exibições do ACS (Close Figure 7)

Nome da exibição do ACS | Objetivo
AdtServer.dvHeader | Informações do cabeçalho de eventos coletados.
AdtServer.dvAll | Informações do cabeçalho e todas as informações do corpo de eventos coletados.
AdtServer.dvAll5 | Informações do cabeçalho e as primeiras cinco cadeias de informações do corpo de eventos coletados.
Do ponto de vista de desempenho, um único coletor ACS pode processar um pico máximo de 100.000 eventos por segundo e um número máximo constante de 2.500 eventos por segundo. Para fins de planejamento, um único coletor ACS pode dar suporte a até 150 controladores de domínio, 3.000 servidores membros ou 20.000 estações de trabalho com base nas configurações de Diretiva de Auditoria padrão. Em um cenário real testado, cerca de 150 controladores de domínio mostraram um máximo de aproximadamente 140 eventos por segundo, com um pico médio de 500.000 eventos por hora. Em apenas 14 dias (a configuração de retenção padrão do ACS), mais de 150 GB de dados de eventos de segurança foram armazenados no banco de dados do SQL Server. Obviamente, uma Diretiva de Auditoria mais agressiva e a configuração SACL associada irão gerar ainda mais dados (por hora, por dia e geral).
O importante a perceber aqui é que, com esse volume de dados, seria impossível qualquer ser humano analisar cada evento em um grande ambiente corporativo normal. Por outro lado, as organizações não devem temer os números apresentados aqui. A compreensão das alterações em andamento no ambiente impacta a análise de uma grande quantidade de dados.
É aí que o ACS faz diferença. Através do SQL Server Reporting Services e do ACS, é possível transformar problemas que normalmente jazem enterrados no log de eventos da Segurança em algo facilmente identificável, como os eventos codificados por cores encontrados no log de eventos do Aplicativo. Embora o ACS inclua um conjunto de relatórios padrão, é simples estendê-los para atender às necessidades específicas do ambiente.
Considere o seguinte cenário: devido à sensibilidade das relações de confiança externas no ambiente, a diretoria pediu que desenvolvêssemos um relatório detalhando a criação de Relações de Confiança do Active Directory. Após um pouco de pesquisa, sabemos que, quando uma Relação de Confiança é criada, um objeto trustedDomain é gerado no contêiner cn=System dentro do contexto de nomeação de domínio específico no Active Directory. Depois de editar a SACL nesse contêiner para auditar a criação bem-sucedida de qualquer objeto de domínio confiável, poderemos capturar eventos de segurança sempre que um objeto desse tipo for criado. Isso é processado em um evento 566 no log de eventos da Segurança no controlador de domínio em que a criação de relação de confiança foi executada. Podemos então escrever uma consulta SQL simples para recuperar essas informações do ACS:
select * from AdtServer.dvAll
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc
Para compilar esses dados em um relatório, use a versão do Visual Studio® 2005 incluída no SQL Server 2005 Reporting Services, que é específica para o desenvolvimento de relatórios. Após a conclusão do assistente, será fácil criar relatórios semelhantes ao exibido na Figura 8. E mais: qualquer alteração no ambiente que possa ser representada no log de eventos da Segurança pode ser resumida em um relatório com aparência bem semelhante.
Figura 8 Exemplo de relatório do ACS
Figura 8 Exemplo de relatório do ACS

Desenvolvendo um plano de auditoria
Agora que compreendemos os desafios e os aspectos legais e técnicos da auditoria, como os administradores de TI devem proceder para desenvolver um "plano de auditoria" para a organização deles? O desenvolvimento de uma diretiva de auditoria abrangente é um processo em várias etapas. A primeira é determinar o que deve ser auditado. Isso inclui analisar o ambiente e determinar que tipos de eventos e alterações devem gerar auditorias. Pode incluir itens simples (como bloqueios de conta, alterações em grupos confidenciais, criação de relação de confiança) ou alterações complexas, como modificações de elementos de configuração em aplicativos no ambiente. O principal aqui é que a diretoria deve se envolver na determinação do "que" em um plano de auditoria. Este exercício precisa ser feito no papel e deve ser repetido em intervalos regulares, e não somente após incidentes significativos.
A segunda etapa envolve identificar como as informações de auditoria relativas a alterações específicas são retornadas na forma de eventos de segurança. Às vezes, essas informações estão cifradas e ilegíveis. Antes da implementação, devem ser estabelecidas correlações entre eventos de segurança e várias ações para entender o que esses eventos significam na realidade. Após um incidente não é hora de descobrir as relações entre eventos e ações.
A terceira etapa é quando o pneu encontra a estrada, ou seja, quando você implementa sua Diretiva de Auditoria e as SACLs. Conforme discutido anteriormente, você precisará definir as configurações da Diretiva de Auditoria (para habilitar a geração de eventos de segurança) e as SACLs (para gerar trilhas de auditoria referentes a ações associadas) no diretório, no sistema de arquivos e no Registro para obter um panorama completo das alterações nessas áreas.
Tudo isso nos conduz à quarta e última etapa – coleta, disparo e análise. Dependendo do tamanho e das necessidades da sua organização, eles podem ser cobertos pelos recursos nativos do Windows Server 2008 ou por soluções avançadas, como a funcionalidade Serviços de Coleta de Auditoria do System Center Operations Manager. Um erro comum cometido pela maioria das organizações é configurar apenas a Diretiva de Auditoria, sem definir as SACLs. A última etapa é toda sobre a implementação de uma solução de tecnologia para relatar e compartilhar dados com os participantes dentro da organização. Como mencionado anteriormente, boa parte das organizações tem uma entidade estabelecida responsável pela segurança, e um plano de auditoria precisa ser estruturado em torno dos elementos organizacionais existentes para ser eficaz. O principal nesta última etapa é coletar e apresentar informações de forma clara a todos os responsáveis pela compreensão das alterações no ambiente.
A maior parte das organizações de TI está à distância de um evento significativo de meramente pensar sobre um plano de auditoria abrangente até realmente precisar de um. Em comparação com as plataformas anteriores, o Windows Server 2008 fornece mecanismos avançados para a coleta e análise de dados de eventos de segurança. Tecnologias avançadas de coleta e relatório como o ACS expõem problemas antes ocultos pela distribuição e pelo volume de eventos, tornando essas alterações imediatamente óbvias.
Como a maioria dos problemas de TI, o processo é o principal desafio. Configuração e análise adicionais são sempre necessárias para capturar o que os gerentes de TI esperam, por isso o desenvolvimento de uma compreensão profunda dos requisitos do ambiente e dos recursos da plataforma do Windows lhe permitirão responder a esses desafios de cabeça erguida. Boa sorte!

Rob Campbell e Joel Yoker Rob Campbell é especialista técnico sênior e Joel Yoker é consultor sênior da equipe Microsoft Federal. Rob e Joel estão concentrados no desenvolvimento e na implantação de soluções de segurança para clientes do governo federal dos Estados Unidos.


 Do editor: Que venha o Windows Server 2008
Do editor
Que venha o Windows Server 2008

Produtos são lançados o tempo todo. E quando você tem um portfólio de centenas de produtos (milhares, realmente, quando se considera a Web), a noção do lançamento de um produto pode se tornar muito trivial. Não desta vez.
No mês de fevereiro, a Microsoft marca o lançamento do Windows Server 2008 e nós não poderíamos estar mais empolgados. Não há dúvida de que esse lançamento demorou, mas acredito que você verá que valeu a pena esperar. O número de principais melhorias – e a quantidade de novos recursos – é impressionante. Certamente poderíamos falar sobre o IIS 7.0 (e o faremos) ou sobre a Proteção de Acesso à Rede (também o faremos). Poderíamos falar sobre o Gerenciador de Servidores, ou sobre novas técnicas de implantação, ou sobre os novos recursos de conformidade (verificação, verificação e verificação). É verdade, a lista é longa, mas para ser sincero, o que me impressiona nesse novo lançamento é quanto esforço foi feito para aprimorar a capacidade de gerenciamento do Windows Server.
Foi gasto muito tempo aqui tentando focalizar o que poderia ser feito para facilitar a vida de um profissional de TI. Levando isso em conta, é realmente satisfatório ver um produto cujo foco é ajudar o profissional de TI para que ele faça melhor o seu trabalho. Como exemplo, veja a nova infra-estrutura do Eventing no Windows Server 2008, que Rob Campbell e Joel Yoker abordam na edição deste mês. É difícil até mesmo para o mais especializado de nós se empolgar com o Eventing, mas eu preciso confessar: estou chocado com a grande diferença que ele faz neste lançamento. Dados XML, exibições personalizadas, descrições mais detalhadas, geração simplificada de relatórios... são coisas demais para gerenciar.
Brincadeiras à parte, as principais melhorias para a base dos nossos negócios através desse lançamento são bons motivos para você se empolgar. Os aprimoramentos no Active Directory, IIS, rede, segurança, virtualização e assim por diante, tornam esse o mais significativo lançamento de produto na nossa história. Portanto, dedicamos essa edição a tudo que você precisa saber sobre o Windows Server 2008.
E, em especial, estamos muito satisfeitos em dar as boas-vindas de novo a Mark Russinovich, colega da área técnica na divisão de plataforma e serviços e autor das sempre populares ferramentas Sysinternals. Mark criou alguns dos contéudos mais procurados na história da TechNet Magazine, sendo o mais notável a sua série "Por dentro das alterações no kernel do Windows Vista” (de nossas edições de fevereiro, março e abril de 2007). Mark reprisa essa série neste mês com uma profunda análise técnica sobre as alterações que você encontrará no kernel do Windows Server 2008. Aproveite!
– Joshua Hoffman

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Brandon Baker, Mai-lan Tomsen Bukovec, Bryce Cogswell, Nils Dussart, Gregoire Guetat, Brett Hill, Gaby Kaplan, Jason Leznek, Paul Mayfield, Nathan Muggli, Meg Muran, Michael Murgolo, Michael Niehaus, Raja Perumal, David Solomon, Eric Traut, Jim Truher e Landy Wang.


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

Backup completo de PC com Windows Vista
Agradecemos por seu excelente artigo na edição de setembro de 2007 sobre o Backup completo de PC com Windows Vista® ("Uma guia para as tecnologias de backup do Windows Vista", technetmagazine.com/issues/2007/09/Backup). No entanto, eu mesmo não posso experimentá-lo, pois quando ele me pergunta onde desejo inserir a imagem de backup, ele afirma que irá inseri-la na minha unidade de disco rígido externo (que é o que eu gostaria de fazer). Mas ele não me dá a opção de inserir o arquivo em uma pasta específica na minha unidade de disco rígido externo, o que me faz pensar que ele irá substituir todos os meus outros arquivos que já estão lá. Preciso me preocupar com isso?
– Ben B.

Passamos a nossa pergunta para a autora, Christine Fok, que afirmou que o Backup completo de PC irá, de fato, criar uma pasta no destino para o armazenamento da imagem; portanto, não há motivo para preocupação – nenhum dado será substituído.

Referência da chave de Registro errada
O artigo de dezembro de 2007, "Rastrear problemas de rede enganosos" (technetmagazine.com/issues/2007/12/Network) contém um pequeno erro ao fazer referência a uma chave do Registro para ajustar a Pilha TCP/IP no Windows®. Na página 70, o autor, Christopher Stoneff, menciona que você pode ajustar valores na chave HKLM\System\CurrentControlSet\Services\TCPIP, quando a chave correta é, na verdade, HKLM\System\CurrentControlSet\Services\TCPIP\Parameters (ele deve ter se esquecido de adicionar "Parameters").
– Ingmar K.

Christopher Stoneff confirmou que você está certo. A chave realmente inclui \Parameters no final. Pedimos desculpas pela parte necessária do caminho do Registro que foi omitida. Corrigimos isso na versão online do artigo.

Criptogrando arquivos
Estou muito interessado em aprender mais sobre o EFS (Sistema de Arquivos com Criptografia) e li a sua coluna Security de março de 2007: "Implantando o EFS: parte 2" (technetmagazine.com/issues/2007/03/SecurityWatch). Tenho um ambiente de domínio e alguns usuários já estão criptografando alguns arquivos. Introduzi então modelos de EFS e CA (autoridade de certificação). Minha pergunta é: se esses usuários que já tiverem criptografado arquivos usando seus próprios certificados auto-assinados precisarem criptografar novos arquivos, eles devem criptografá-los usando o antigo certificado auto-assinado ou devem se inscrever em um novo certificado da minha CA? Além disso, se todos os meus usuários tiverem perfis de roaming, onde serão armazenadas as chaves privadas dos usuários?
– Ammar H.

John Morello, que escreveu a coluna sobre a implantação do EFS, enviou a resposta para a sua dúvida:
Assim que os usuários se inscreverem para o novo certificado do EFS, eles começarão a usá-lo para operações novas. No entanto, quaisquer arquivos criptografados existentes continuarão sendo criptografados com o antigo par de chaves até que sejam atualizados. Assim, depois que os usuários tiverem se inscrito, você pode executar cipher /u, que atualizará todos esses arquivos com o novo par de chaves.
Se você estiver usando perfis de roaming, os pares de chaves ganharão mobilidade nos perfis. Recomendo usar a Mobilidade de Credenciais, que é mais simples do que os perfis de roaming. Clique aqui para obter mais informações: go.microsoft.com/fwlink/?LinkId=107469.

Expressão regular errada
Na coluna Ei, Equipe de Scripts!, de janeiro de 2008, "Não há como errar usando expressões regulares" (technetmagazine.com/issues/2008/01/HeyScriptingGuy), o exemplo usando
objRegEx.Pattern = "[^A-Z][^a-z]"
talvez não seja o pretendido. O objetivo era localizar qualquer caractere que não fosse uma letra em maiúscula ou minúscula. No entanto, esse padrão é para uma maiúscula seguida de uma letra minúscula. Ele falha com uma seqüência de caracteres como "aBcde". Talvez devesse ser assim:
objRegEx.Pattern = "[^A-Z^a-z]"
– Roger R.

Passamos a sua pergunta para a Equipe de Scripts e veja o que eles disseram:
Olá, Roger! Obrigado por destacar isso. Parece que fizemos uma alteração na coluna em algum momento e não detectamos isso. No rascunho original (que ainda tenho em algum lugar no meu computador), afirmamos que o objetivo era localizar uma letra maiúscula seguida por uma letra minúscula. Provavelmente, decidimos depois que isso não era tão útil quanto localizar caracteres que não fossem letras e mudamos o texto, mas esquecemos de alterar o código de exemplo. Corrigiremos isso na versão online. Desculpe-nos.


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

Gerenciar banco de dados SQL
Gerenciador de Evento Sentry SQL
sqlsentry.net/event-manager/standard-sql-server.asp
Quanto maior e mais complexa sua infra-estrutura, mais você precisa se preocupar com a manutenção e as tarefas operacionais interferindo entre si. Isso pode causar confusão no fluxo do processo para seus usuários finais. Felizmente, existem algumas ferramentas disponíveis para o banco de dados e para o administrador do sistema, a fim de ajudar a coordenar um complexo cronograma de ambiente.
Uma das ferramentas que pode ser considerada para o seu ambiente do servidor de vários bancos de dados é o Gerenciador de Evento Sentry SQL, um aplicativo de servidor .NET Framework da Microsoft® que utiliza um SQL Server® 2000 ou uma instância do SQL Server 2005 no back-end. Você se conecta ao aplicativo do servidor através da interface do usuário do Console Sentry SQL, que lhe oferece uma visão unificada dos servidores gerenciados no seu ambiente. O aplicativo de servidor não tem agente, mas isso, como sempre, implica uma necessidade de ser executado sob um contexto de usuário que tenha os direitos de se conectar a máquinas e serviços que você deseja gerenciar.
Um dos recursos mais considerados do aplicativo é a interface do usuário do console, que fornece um reagendamento de arrastar e soltar de suas tarefas do servidor, a fim de ajudar na manutenção do alinhamento e na atividade operacional, para evitar conflitos e tempo de inatividade. Enquanto a interface do usuário pode parecer um pouco complicada a princípio, ela permite localizar potenciais problemas rapidamente e encontra um intervalo para alterar uma tarefa conflitante. Ela oferece até mesmo uma visualização do Microsoft Outlook® dos trabalhos do seu agente SQL e das tarefas agendadas do Windows® para os servidores que você decidiu monitorar. Além disso, a exibição do calendário destaca as tarefas de longa duração e as tarefas que falharam, a fim de ajudá-lo a rastrear e resolver os problemas ao longo do processo.
Além da funcionalidade do agendamento, o Sentry SQL também possui um robusto sistema de notificação que suplanta a necessidade do SQL Mail, MAPI, xp_sendmail ou sp_send_dbmail. Ele também roteia suas notificações de evento do servidor gerenciado através de seu subsistema, fornecendo um controle centralizado sobre os tipos, a freqüência e a distribuição dessas notificações.
As notificações podem ser configuradas nos níveis global, de servidor e de tarefa ou trabalho, oferecendo a granularidade que os adminstradores esperam para esse tipo de evento. Você pode configurar vários diferentes tipos de condições de evento para disparar a notificação, como quando o trabalho demora muito ou pouco tempo para ser concluído, quando um indicador de desempenho como a utilização da CPU atinge um certo limite, ou quando um trabalho do agente SQL é bloqueado por alguma razão. Você também pode configurar o Sentry SQL para ser notificado quando a configuração mudar, assim você saberá quando alguém ajustar um cronograma, pausar um monitor e assim por diante.
Mas o Sentry SQL lida com mais do que trabalhos do agente SQL e eventos do agendador de tarefas do Windows. O aplicativo também é compatível com eventos dos planos de manutenção, pacote DTS, tarefas SSIS e log de agente SQL.
Os poderes que geralmente são para ver quão bem os sistemas estão se desempenhando e, se você tivesse um avaliador de tempo ativo para se orgulhar, provavelmente você iria gostar de exibi-lo também. O Sentry SQL possui várias opções internas de relatório para tarefas, permitindo que você gere e imprima os gráficos estatísticos do tempo de execução e do desempenho. Você também pode exportar os dados do relatório para XML, CSV ou HTML, para inclusão em seus próprios documentos e tarefas de relatório.
Observe que a Edição Profissional acrescentou a habilidade de gerenciar os servidores Oracle bem como recursos, como o monitoramento de serviços de relatório, o enfileiramento de trabalho do Agente SQL, o encadeamento de eventos de servidor não-SQL e o calendário para recursos compartilhados.

Preço: a Standard Edition é oferecida a partir de US$395
Programando a manutenção com o Sentry SQL
Programando a manutenção com o Sentry SQL

Gerenciar sistemas temporários
Mobile Admin
rovemobile.com/products/ma/features
Considerando que você não pode estar em mais de um lugar ao mesmo tempo, uma ferramenta de administração móvel e remota do servidor é uma boa idéia para o profissional TI superatarefado. E um que deve ser conferido é o Mobile Admin do Rove Mobile (o antigo Idokorro Mobile).
O Mobile Admin é uma instalação do servidor cliente na qual um servidor de comunicação (que tem acesso aos servidores gerenciados) interage com um conjunto de dispositivos portáteis sem fio. A parte do servidor do aplicativo não possui agente, o que significa que não é necessário instalar nada nos servidores que você quer gerenciar. Você, no entanto, precisa fornecer ao contexto da máquina e do aplicativo os direitos apropriados de administração remota para permitir a administração das máquinas na sua infra-estrutura.
O servidor pode ser acessado por boa parte das principais plataformas móveis, incluindo o Windows Mobile® Pocket PCs e os Smartphones, bem como os smartphones BlackBerry. Além disso, qualquer computador conectado na Internet que possua um navegador compatível pode se conectar ao Mobile Admin (desde que sua diretiva de segurança esteja configurada para permitir isso).
Uma das primeiras preocupações que qualquer profissional de sistemas ou de rede tem com as administrações móveis é a segurança. Para aqueles com o BlackBerry Enterprise Server implantado, é possível escolher criptografar todas as comunicações com o TDES (padrão de criptografia de dados triplo) ou o AES (padrão avançado de criptografia) – que são compatíveis com o FIPS (Normas Federais de Processamento de Informações).
Além disso, o Mobile Admin amplia a funcionalidade "kill" para um BlackBerry perdido, removendo o software e os dados do telefone remotamente. Para outros portáteis, você pode implementar uma VPN para proteger suas comunicações e/ou configurar o Mobile Admin para usar o logon do Windows, autenticação do LDAP, do RSA SecurID, do RADIUS ou um logon específico do Mobile Admin.
Uma vez conectado, você pode executar as tarefas de administração do Windows, como visualizar e limpar logs de evento, reinicializar as máquinas, gerenciar arquivos e diretórios e visualizar e editar tarefas programadas.
Em termos da integração do Active Directory®, você pode criar, editar, desabilitar ou excluir usuários, grupos e computadores. Enquanto isso, para a administração do Exchange, você pode mudar as configurações da caixa de correio e travar e destravar as filas de mensagens e muito mais.
Com o IIS você pode reiniciar pools de aplicativos ou sites da Web e mudar configurações de diretório virtual. Para os seus servidores SQL você pode executar as consultas do T-SQL, modificar logons e iniciar e parar trabalhos do agente SQL. E, se você estiver executando os Serviços do Cluster, poderá mover grupos, selecionar recursos offline e failover, entre outras tarefas administrativas comuns.
Por fim, o Mobile Admin também possui suporte para os aspectos de gerenciamento da Oracle, Novell LDAP, Lotus Domino, Citrix, HP iLO, Backup Exe e muito mais.

Preço: a partir de US$245 por servidor.

Resenha de livro
Mastering Windows Network Forensics and Investigation
sybex.com
Você pode ter o hardware e os procedimentos corretos para detectar e reduzir as ameaças na sua rede. Mas você conhece os procedimentos ou possui os protocolos necessários para a investigação e, talvez, para processar os invasores depois que um evento relacionado com a segurança acontece?
É aqui onde o livro Mastering Windows Network Forensics and Investigation (Sybex, 2007) entra em cena. Ele foi projetado para ensinar as habilidades que investigam completamente as invasões de rede do Windows, de pequena escala, incidentes em uma única máquina (como a utilização inapropriada de serviços da empresa) para ataques maiores e mais disseminados contra os sistemas mais confidenciais.
O livro guia você pelo processo de coleta de evidências, abrangendo tudo, desde a realização de entrevistas até o rastreamento de eventos auditados e logs. Ele aborda onde e como coletar evidências das máquinas e redes do Windows usando ferramentas como WireShark, LogParser, EnCase e o conjunto de ferramentas SysInternals.
Além disso, o livro explora as informações que você pode obter do registro, a estrutura e os conteúdos do sistema de arquivo, os logs baseados em texto, os logs de evento e os processos da máquina em questão. Você também irá descobrir como criar um Live-Analysis CD, que contém as ferramentas necessárias para rastrear as evidências necessárias. Por fim, o livro aborda como apresentar os resultados de sua investigação, detalhando as diretrizes e os procedimentos para testemunhar em processos judiciais.

Preço: US$59,99.

Coletar dados de sistema
MetaLAN
hammer-software.com/metalan.shtml
A administração detalhada é um dos principais componentes para a administração de sistemas bem-sucedidos. Ela elimina grande parte dos problemas e libera um pouco do seu valioso tempo, reduzindo a quantidade de estresse que você tem no trabalho.
O MetaLAN da Software Hammer é uma ferramenta que o ajuda a gerenciar e oferecer suporte aos usuários e servidores na sua rede do Windows. Esse aplicativo sem agente permite reunir rapidamente informações, fazer mudanças na configuração e, geralmente, gerenciar suas máquinas do Windows. Isso, naturalmente, requer o contexto e direitos de usuário necessários para tal.
O MetaLAN possui dois modos de operação. Você pode escolher executá-lo diretamente no modo do Administrador (que atinge as máquinas que você gostaria de consultar ou modificar as propriedades) ou pode usar o agente/serviço de complemento gratuito, chamado de ProbeServer, no computador remoto em conjunto com o MetaLAN em execução no modo de servidor para monitorar continuamente sua estação de trabalho.
Ao inicializar o aplicativo, você é conduzido para a interface do usuário do Painel de Controle do MetaLAN, que, por sua vez, oferece a opção de testar sua rede atual quanto a domínios a serem gerenciados. Aqui, você também pode inicializar os vários componentes da ferramenta, como a ferramenta de suporte técnico, de relatório, de software e RegCast.
A ferramenta de suporte técnico lhe oferece uma visualização de pesquisa e navegação para as máquinas no domínio que você está gerenciando. Selecionar um computador faz com que apareçam várias informações úteis sobre a máquina, incluindo o fabricante, os endereços IP, os processadores, as unidades, os endereços MAC e as funções do servidor. A partir daqui, você pode executar as consultas do WMI (Instrumentação de Gerenciamento do Windows), conectar-se a monitores de desempenho em tempo real, ver os softwares instalados e executar outras tarefas administrativas úteis.
A ferramenta de relatório fornece exibições gráficas rápidas e exportáveis de seus nós gerenciados. Por exemplo, você pode gerar um gráfico de pizza das velocidades da CPU de todas as máquinas na sua rede ou verificar quais máquinas possuem o Windows XP Service Pack 2 instalado.
A ferramenta de software permite ver e exportar rapidamente as listas do software instalado em um grupo de uma para N máquinas na sua rede – é uma excelente ferramenta para auditoria.
E a ferramenta RegCast permite ver (e também modificar, se você estiver em um administrador corporativo ou de domínio) informações de registro de máquinas remotas de um grupo específico de máquinas.
O MetaLAN também inclui uma ferramenta para implantação e instalação temporária de pacotes MSI (Microsoft Installer) (se eles oferecerem suporte à instalação silenciosa); uma visão geral do armazenamento que mostra cada unidade na sua máquina e quanto espaço livre está disponível; e uma ferramenta Service Admin que permite iniciar, parar e até remover serviços. Como se isso não fosse suficiente, ainda há uma excelente ferramenta de controle remoto VNC que disponibiliza um pequeno executável VNC, que, quando executado, lhe fornece controle remoto da máquina (muito semelhante à Assistência remota).

Preço: a partir de US$75 para um pacote de licença com 20 nós.
A ferramenta de suporte técnico lhe fornece uma visualização de pesquisa e navegação
A ferramenta de suporte técnico lhe fornece uma visualização de pesquisa e navegação

Automatizar tarefas
AutoHotkey
autohotkey.com
A automação pode ser o melhor amigo do profissional de TI, ajudando-o a evitar tarefas repetitivas e que consomem tempo. Entre as várias ferramentas que nos ajudam nisso está o utilitário AutoHotkey. Essa ferramenta de código-fonte gratuita ajuda a otimizar as rotinas de desktop ao automatizar praticamente todas as tarefas que exigem entrada de teclado, mouse ou até mesmo joystick. É uma ferramenta macro e de teclas de acesso baseada em scripts para esteróides.
O AutoHotkey é executado na bandeja do seu sistema e, mediante a inicialização, executa a definição de script que você criou. O programa executa comandos de script individuais à medida que eles são exibidos no arquivo de script. Isso é excelente para iniciar o seu conjunto favorito de aplicativos na inicialização, por exemplo. Mas, espere; tem mais: você também pode definir qualquer número de teclas de acesso e hotstrings.
As teclas de acesso, ou de atalho, são qualquer combinação que você definir para acionar uma ação, como iniciar um aplicativo, colocar as janelas em primeiro plano ou até mesmo simular a ação do mouse.
As Hotstrings, por outro lado, são abreviaturas de texto para comandos ou frases digitados com freqüência. Além disso, essas hotstrings podem ser usadas para iniciar uma ação com script semelhante a uma tecla de acesso. Por exemplo, você poderia criar uma hotstring com a simples seqüência chave de "td", que abre o Microsoft Word e escreve a data de hoje no formato que você desejar. Ou, se houver uma resposta de parágrafo específica que você sempre costuma enviar aos seus usuários, você poderia criar uma hotstring simples para que esse parágrafo seja automaticamente inserido em uma nova mensagem do Outlook.
A linguagem de script por si só é compatível com variáveis, expressões para operações matemáticas e de seqüência de caracteres, variáveis globais internas, funções, looping e instruções condicionais, de modo que você possa criar um script que seja adequado às necessidades do seu sistema. No total, há mais de 100 comandos e construções de linguagem para ajudá-lo. Por exemplo, você pode simular a ação de arrastar do mouse, mostrar caixas de mensagens, executar operações assíncronas, enviar mensagens de email, modificar o Registro, definir timers nos loops para que tenham verificações recorrentes, abrir aplicativos, fechar janelas e eliminar processos, para citar apenas alguns.
Outro recurso interessante do AutoHotkey é que você pode compilar seus scripts para a reutilização e a distribuição assim que eles corresponderem às suas necessidades. Dessa forma, os usuários que não tiverem o AutoHotkey instalado podem aproveitar os seus atalhos e scripts. E, graças à licença do projeto de código-fonte, você poderá distribuí-los ou vendê-los sem rsetrições.
Na sua organização interna, você pode distribuir facilmente aos seus usuários finais um script executável que execute um conjunto de personalizações que, de outra forma, você precisaria executar manualmente diretamente no desktop. Além disso, se você precisar personalizar esses scripts para cada usuário, o AutoHotkey também aceita comutadores e parâmetros da linha de comando, de modo que você pode realmente ter algo útil e reutilizável no seu domínio.
Ao contrário de muitos projetos de código-fonte, que freqüentemente não oferecem muito em termos de documentação, a documentação do AutoHotkey é completa e bem desenvolvida, mostrando a você o que é necessário saber para realizar o script de suas tarefas de automação com exemplos muito bons e úteis. Além disso, no site da Web do projeto, você encontrará um fórum de usuários ativos, que irá ajudá-lo com perguntas, e um wiki que contém scripts, tutoriais e uma referência de comando. Também há uma página de demonstração do script, que oferece um bom conjunto de exemplos enviados por usuários e que podem ser utilizados.

Preço: gratuito.
O AutoHotKey pode compilar scripts para reutilização e distribuição
O AutoHotKey pode compilar scripts para reutilização e distribuição

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


 Utilit&#225;rio em destaque: Certifica&#231;&#227;o do logotipo Windows Server
Utilitário em destaque
Certificação do logotipo Windows Server
Venkat Krishnamachari
Faça download do código deste artigo: Works with Windows Server 2008 (KB)

Com a Certificação do Software Windows Server® 2008, a Microsoft está tentando ajudar os desenvolvedores a manter a conformidade com as práticas recomendadas e permitir que os profissionais de TI avaliem aplicativos antes da compra, economizando tempo e aborrecimentos. Para ajudar os clientes a avaliar a compatibilidade de aplicativos, a Microsoft criou o programa "Works with Windows Server 2008", que inclui ferramentas gratuitas de teste de suporte, a fim de ajudar a garantir que um aplicativo forneça uma experiência previsível.
A ferramenta "Works with" coleta dados sobre o impacto do aplicativo no sistema operacional, monitorando o estado do sistema de arquivos, registro, serviços e drivers. Então, a ferramenta analisa esses dados e relata falhas e êxitos de casos de testes específicos. O documento Estrutura de Teste da ferramenta "Works with" e ferramentas adicionais, disponíveis em windowsservercatalog.com/ready, fornecem mais detalhes. Essas ferramentas devem ajudar os ISVs a compilar a compatibilidade de aplicativos e, ao mesmo tempo, permitir que os profissionais de TI avaliem a prontidão do aplicativo para a implantação no Windows Server 2008.
Para usar essas ferramentas, primeiro instale a versão mais recente do Windows Server 2008 em um computador de teste, baixe a ferramenta "Works with" de windowsservercatalog.com/ready e certifique-se de incluir a ferramenta Application Verifier. A interface gráfica do usuário da ferramenta tem quatro funções simples: criar uma aprovação do teste, retomar uma aprovação de teste existente, visualizar os resultados do teste e criar um pacote de envio (para ISVs buscando validação da "Works with" de um fornecedor de testes autorizado).
Relatório de texto mostrando resultados
Relatório de texto mostrando resultados
Crie uma aprovação de teste fazendo com que um aplicativo percorra seu ciclo de vida: instalação, configuração, execução e desinstalação. A ferramenta "Works with" é executada principalmente em segundo plano, verificando a estabilidade do SO e a compatibilidade do instalador, bem como se os recursos são executados adequadamente, de acordo com os novos requisitos de segurança da plataforma e outros recursos configuráveis. Em geral, é melhor concluir a aprovação de teste e gerar o relatório completo, o que costuma demorar de duas a quatro horas. No entanto, você pode interromper uma aprovação de teste, gerar um relatório rápido e retomar o teste posteriormente.
Quando você tiver concluído, terá relatórios de status vermelho ou verde em cada caso de teste com resultados detalhados, como os mostrados na captura de tela. Os testes relatados como verde indicam compatibilidade. Para resultados em vermelho, você pode analisar um arquivo de log para compreender a condição de erro. Certifique-se de salvar os logs gerados localmente em outra máquina, de modo que possa consultá-los depois que limpar o computador de teste. A ferramenta "Works with" é executada em qualquer aplicativo de servidor e também pode avaliar componentes cliente e ferramentas de gerenciamento desenvolvidos para o Windows Vista®.
Se você estiver usando software comercial, a ferramenta "Works with" poderá ajudá-lo a planejar a migração de aplicativos compatíveis. Você poderá usar os resultados do teste para consultar fornecedores sobre planos de suporte, economizando, assim, o tempo dos desenvolvedores em solucionar problemas de compatibilidade e priorizar correções. Em relação a aplicativos personalizados, você pode fornecer comentários extremamente específicos para suas equipes de desenvolvimento. Você também pode confirmar a compatibilidade de forma contínua, à medida que novos patches forem lançados, e documentar dados de configuração do seu aplicativo com o departamento de TI. Alguns clientes têm utilizado as ferramentas para documentar arquivos utilizados pelos aplicativos do sistema.
Estamos interessados nos seus comentários sobre como podemos aprimorar os casos de testes ou ferramentas para aperfeiçoar o uso em seu ambiente. Entre em contato conosco pelo email wslogofb@microsoft.com.

Venkat Krishnamachari atua como Líder técnico de Certificação de Software do Windows Server desde 2005 e trabalhou anteriormente na equipe responsável pelo SQL Server 2005.


 The Cable Guy: Migrando sua intranet para IPv6 com o ISATAP
The Cable Guy
Migrando sua intranet para IPv6 com o ISATAP
Joseph Davies
Este artigo se baseia em uma versão de pré-lançamento do Windows Server 2008. Todas as informações deste artigo estão sujeitas a alterações.

Uma percepção errônea comum sobre o Internet Protocol versão 6 (IPv6) é que, para usá-lo, você deve implantar endereçamento e roteamento IPv6 nativos, o que requer uma análise detalhada de esquemas de endereçamento IPv6, atualizações de roteador e configuração, bem como um cronograma de implementação. Embora isso seja feito eventualmente para conectividade
IPv6, você pode implantar facilmente conectividade IPv6 encapsulada usando o ISATAP. Com a conectividade IPv6 encapsulada, hosts que são compatíveis com ISATAP podem se comunicar usando tráfego IPv6 encapsulado com um cabeçalho IPv4 (o campo Protocolo IPv4 é definido como 41). O tráfego de ISATAP atravessa uma intranet Somente IPv4; portanto, você pode começar a testar imediatamente aplicativos com capacidade para IPv6 sem precisar aguardar por uma infra-estrutura IPv6 nativa.
O ISATAP é uma atribuição de endereço e tecnologia de encapsulamento automático definida no RFC 4214, que fornece conectividade IPv6 unicast entre a intranet Somente IPv6/IPv4hostsacrossanIPv4-. Os hosts ISATAP usam uma interface de encapsulamento lógico para a qual são atribuídos endereços ISATAP, que têm a forma UnicastPrefix:0:5EFE:w.x.y.z (quando w.x.y.z for um endereço IPv4 privado atribuído ao host ISATAP) ou UnicastPrefix:200:5EFE:w.x.y.z (quando w.x. y.z for um endereço IPv4 público atribuído ao host ISATAP). O UnicastPrefix é um prefixo de endereço unicast de 64 bits, incluindo prefixos de link local, global e local exclusivo. Exemplos de endereços ISATAP são 2001:DB8::98CA:200:131.107.28.9 e 2001:DB8::98CA:0:10.91.211.17.

Migração da intranet para IPv6 com o ISATAP
Uma implantação ISATAP consiste em uma ou mais sub-redes ISATAP lógicas, que são redes Somente IPv4 com prefixo de sub-rede IPv6 de 64 bits. Em uma sub-rede ISATAP lógica, há hosts ISATAP e roteadores ISATAP. Um host ISATAP utiliza uma interface de encapsulamento ISATAP para encapsular tráfego IPv6. Esse tráfego pode ser enviado diretamente para outros hosts ISATAP na mesma sub-rede ISATAP lógica. Para atingir destinos que estão em outras sub-redes ISATAP ou em sub-redes IPv6 nativas, o tráfego é enviado para um roteador ISATAP. Um roteador ISATAP é um roteador IPv6 que anuncia prefixos de sub-rede para hosts ISATAP e encaminha tráfego IPv6 entre hosts ISATAP e hosts em outras sub-redes IPv6. A Figura 1 mostra os componentes de ISATAP em uma intranet simplificada.
Figura 1 Partes compatíveis com IPv6 e Somente IPv4 de sua intranet
Figura 1 Partes compatíveis com IPv6 e Somente IPv4 de sua intranet
O ISATAP permite que você implante recursos de endereçamento e roteamento IPv6 nativos na sua intranet em três fases.
Fase 1: Intranet Somente IPv4 Nessa fase, a sua intranet inteira pode ser uma única sub-rede ISATAP lógica. A Figura 2 mostra um exemplo com uma intranet Somente IPv4 com um roteador ISATAP que está anunciando somente um prefixo de endereço local único ou global para hosts ISATAP.
Figura 2 Uma intranet Somente IPv4
Figura 2 Uma intranet Somente IPv4
Fase 2: Partes compatíveis com IPv6 e Somente IPv4 de sua intranet Nessa fase intermediária, a sua intranet tem uma parte Somente IPv4 (a sub-rede ISATAP lógica) e uma parte compatível com IPv6. A parte com capacidade IPv6 da sua intranet é compatível com IPv4 e foi atualizada para oferecer suporte a endereçamento e roteamento IPv6 nativos. Você viu essa configuração na Figura 1.
Fase 3: Intranet compatível com IPv6 Nessa fase final, a sua intranet inteira será compatível com endereçamento e roteamento IPv4 e IPv6 nativos. Observe que o ISATAP não é mais necessário. A Figura 3 mostra um exemplo.
Figura 3 Intranet compatível com IPv6
Figura 3 Intranet compatível com IPv6
Com o ISATAP, você pode ter conectividade IPv6 entre hosts e aplicativos durante as duas primeiras fases da transição a partir de uma intranet Somente IPv4 para uma compatível com IPv6.

Windows Server 2008 e Windows Vista
O protocolo IPv6 para Windows Server® 2008 e Windows Vista® é compatível com ISATAP tanto como host ISATAP quanto roteador ISATAP. Há uma interface de encapsulamento ISATAP separada para cada interface LAN instalada no computador com um sufixo DNS diferente. Por exemplo, se um computador executando Windows Vista tiver duas interfaces LAN e ambas forem conectadas à mesma intranet e receberem o mesmo sufixo DNS, haverá somente uma interface de encapsulamento ISATAP. Se essas duas interfaces LAN estiverem conectadas a duas redes diferentes com sufixos DNS distintos, haverá duas interfaces de encapsulamento ISATAP. Para computadores executando Windows Server 2008 ou Windows Vista SP1, as interfaces de encapsulamento ISATAP serão posicionadas em um estado sem conexão de mídia, a não ser quer o nome "ISATAP" possa ser resolvido.
Por padrão, o protocolo IPv6 para Windows Vista sem service packs instalado configura automaticamente endereços ISATAP de link local (FE80::5EFE: w.x.y.z ou FE80::200:5EFE:w.x.y.z) nas interfaces de encapsulamento ISATAP para endereços IPv4 para os quais foram atribuídas as interfaces LAN correspondentes.
O protocolo IPv6 para o Windows Server 2008 e Windows Vista SP1 configura endereços ISATAP de link local nas interfaces de encapsulamento ISATAP somente se o nome "ISATAP" puder ser resolvido.
Para receber do roteador ISATAP uma mensagem de anúncio de roteador, o host ISATAP deverá enviar ao roteador ISATAP uma mensagem de solicitação do roteador. Em uma sub-rede Ethernet, um host IPv6 nativo enviará uma mensagem de solicitação do roteador multicast e, então, os roteadores na sub-rede responderão a uma mensagem de anúncio de roteador. Como o ISATAP não usa tráfego multicast IPv4 ou requer uma infra-estrutura compatível com IPv4 multicast, o host ISATAP deve transmitir em unicast a mensagem de solicitação do roteador para o roteador ISATAP.
Para transmitir em unicast a mensagem de solicitação do roteador ao roteador ISATAP, o host ISATAP deve primeiro determinar o endereço IPv4 unicast da interface do roteador na sub-rede ISATAP lógica. Para o protocolo IPv6 do Windows Server 2008 e Windows Vista, um host ISATAP obterá o endereço IPv4 unicast do roteador ISATAP através da resolução bem-sucedida do nome de host "ISATAP" para um endereço IPv4 ou com o comando netsh interface isatap set router.

Migrando sua intranet. Fase 1
Para implantar ISATAP na sua intranet na fase 1 da sua migração para IPv6, será necessário realizar as seguintes etapas:
Determinar o prefixo de sub-rede ISATAP Você deve determinar o prefixo de sub-rede de 64 bits para que seja atribuído à sub-rede ISATAP lógica correspondente à sua intranet. Você pode obter um prefixo de 48 bits de um Registro da Internet ou ISP ou poderá derivar o seu próprio prefixo local exclusivo de 48 bits (consulte o RFC 4193 online em tools.ietf.org/html/rfc4193).
A partir do prefixo de 48 bits, escolha um ID de sub-rede de 16 bits da sub-rede ISATAP lógica. A combinação do ID de sub-rede de 16 bits e do prefixo de 48 bits é o prefixo de sub-rede ISATAP de 64 bits. Por exemplo, o prefixo local exclusivo de 48 bits FD8A:219C:052A::/48 e o ID de sub-rede 1 formam o prefixo de sub-rede de 64 bits FD8A:219C:052A:1::/64.
Designar um computador como roteador ISATAP Determine qual computador será o roteador ISATAP. Embora muitos roteadores comerciais sejam compatíveis com a funcionalidade de roteador ISATAP, as informações apresentadas aqui são específicas para computadores que executam o Windows Server 2008.
O computador de roteador ISATAP não precisa de várias interfaces LAN, nem precisa estar conectado a uma parte compatível com IPv6 de sua intranet para fase 1; no entanto, o computador deverá ser escolhido de modo que posteriomente possa ser atualizado com uma interface LAN adicional conectada à parte compatível com IPv6 de sua intranet.
Configurar o computador de roteador ISATAP No computador de roteador ISATAP, a emissão do seguinte comando posicionará as interfaces de encapsulamento ISATAP no computador de roteador ISATAP em um estado de mídia conectada:
netsh interface isatap set router IPv4Address
IPv4Address é o endereço IPv4 atribuído à interface LAN do computador de roteador ISATAP conectado à sub-rede ISATAP lógica.
Em seguida, determine o nome ou índice da interface de encapsulamento ISATAP que corresponde à interface LAN do computador de roteador ISATAP conectado à sub-rede ISATAP lógica, tudo a partir da saída deste comando:
netsh interface ipv6 show interfaces
Em seguida, use este comando para habilitar o anúncio na interface ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex advertise=enabled
ISATAPInterfaceNameOrIndex é o nome ou índice da interface de encapsulamento ISATAP.
Em seguida, use este comando para configurar o computador de roteador ISATAP para anunciar o prefixo de sub-rede ISATAP para hosts ISATAP:
netsh interface ipv6 add route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex publish=yes
ISATAPSubnetPrefix é o prefixo de sub-rede ISATAP determinado
Configurar DNS No seu DNS, adicione um registro de endereço (A) ao nome ISATAP para os domínios apropriados, de modo que os hosts ISATAP na sua intranet possam resolver com êxito o nome "ISATAP". Por exemplo, se seus hosts de intranet utilizarem o sufixo DNS contoso.com, agora você deverá adicionar um registro A no domínio contoso.com para o nome isatap.contoso.com com o endereço IPv4 atribuído à interface LAN do roteador ISATAP na intranet Somente IPv4.
Se o servidor DNS estiver executando o Windows Server 2008, use o editor do Registro (regedit.exe) no servidor DNS para remover a entrada ISATAP do valor de Registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList.
Testar hosts ISATAP De um host ISATAP na sua intranet, use a ferramenta Ipconfig para visualizar os endereços atribuídos. Os hosts ISATAP devem ter um endereço de formato ISATAPSubnetPrefix:: 5EFE:w.x.y.z ou ISATAPSubnetPrefix:: 200:5EFE:w.x.y.z. Por exemplo, se o prefixo de sua sub-rede ISATAP for FD8A:219C: 052A:1::/64 e um host ISATAP tiver o endereço IPv4 10.1.31.97, o host ISATAR deverá ter o endereço FD8A: 219C:052A:1::5FE:10.1.31.97 atribuído à sua interface de encapsulamento ISATAP.
Se um host ISATAP não tiver um endereço ISATAP baseado no prefixo de sub-rede ISATAP, verifique se o host pode resolver o nome "ISATAP". Caso contrário, verifique se os registros A foram criados nos domínios apropriados e, para servidores DNS executando o Windows Server 2008, verifique se o valor do Registro GlobalQueryBlockList foi modificado para remover a entrada ISATAP. Se o nome puder ser resolvido, verifique se o computador de roteador ISATAP foi configurado corretamente. Se tiver, verifique se os roteadores na sua intranet permitem o encaminhamento do tráfego do protocolo IPv4 41.
Quando hosts ISATAP puderem se configurar com êxito com endereços baseados no prefixo de sub-rede ISATAP, eles registrarão esses endereços ISATAP como registros AAAA no DNS e começarão usando-os para a conectividade baseada em IPv6.

Migrando sua intranet: Fase 2
Na fase 2 da sua migração para IPv6, é necessário que você modifique sua configuração do roteador ISATAP, a fim de executar o encaminhamento entre partes compatíveis com IPv6 e Somente IPv4 da sua intranet.
No computador de roteador ISATAP, acione o seguinte comando:
netsh interface ipv6 show interfaces
A partir da saída do comando acima, determine o nome ou índice da interface LAN conectada à parte compatível com IPv6 da intranet e da interface de encapsulamento ISATAP.
Use este comando para habilitar o encaminhamento na interface ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=enabled
Use este comando para habilitar o encaminhamento na interface LAN:
netsh interface ipv6 set interface LANInterfaceNameOrIndex forwarding=enabled
LANInterfaceNameOrIndex é o nome ou índice de interface da interface LAN.
Use o seguinte comando para adicionar uma rota padrão para o roteador ISATAP:
netsh interface ipv6 add route ::/0 LANInterfaceNameOrIndex NextHopAddress publish=yes
NextHopAddress é o endereço IPv6 de um roteador IPv6 nativo vizinho na parte compatível com IPv6 da intranet.
Para tornar a sub-rede ISATAP lógica acessível a partir da parte compatível com IPv6 da intranet, é importante que você configure os roteadores IPv6 nativos com uma rota para o prefixo de sub-rede ISATAP que aponte de volta para o computador de roteador ISATAP.
Para desativar seletivamente ISATAP para computadores na parte compatível com IPv6 da intranet, manipule registros A para o nome ISATAP no seu DNS, de modo que os computadores na parte compatível com IPv6 da intranet não possam resolver o nome ISATAP.
Outra opção que você tem é criar e definir o valor do Registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents como 0x4 (tipo DWORD).

Migrando sua intranet: Fase 3
Para a fase 3, quando a sua intranet inteira for compatível com IPv6, você precisará remover a implantação ISATAP através de DNS e reconfigurar o computador de roteador ISATAP. Para DNS, remova todos os registros A do nome ISATAP. Isso impedirá qualquer host de determinar o endereço IPv4 do roteador ISATAP.
Para o computador de roteador ISATAP, execute o seguinte comando:
netsh interface isatap set router default
Esse comando restaura o estado padrão do componente ISATAP.
Determine o nome ou índice de interface da interface de encapsulamento ISATAP a partir da saída deste comando:
netsh interface ipv6 show interfaces
Use este comando para desabilitar o encaminhamento e anúncio na interface ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=disabled advertise=disabled
Use este comando para remover a rota do prefixo de sub-rede ISATAP do computador de roteador ISATAP:
netsh interface ipv6 delete route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex
ISATAPSubnetPrefix é o prefixo de sub-rede ISATAP.
Para obter mais informações sobre a implantação ISATAP, incluindo detalhes sobre roteadores ISATAP redundantes e considerações de firewall, consulte “Guia de implantação de protocolo de endereçamento de encapsualmento automático intra-site” em go.microsoft.com/fwlink/?LinkId=106926.

Joseph Davies é redator técnico da Microsoft. Além disso, ensina e escreve sobre assuntos relacionados a sistemas de rede do Windows desde 1992. Ele tem oito livros publicados pela Microsoft Press e é autor da coluna mensal online da TechNet, The Cable Guy. Leia mais sobre o The Cable Guy em microsoft.com/technet/community/columns/cableguy/about.mspx.


 Windows PowerShell: Relat&#243;rio de andamento
Windows PowerShell
Relatório de andamento
Don Jones

Recentemente, estava escrevendo um script do Windows PowerShell um tanto longo e complicado, que, em execução, praticamente não respondia. Escrevi-o para ser executado como uma tarefa programada; portanto, ele realmente não produzia muito em termos de saída visível. Quando o executei para seu primeiro grande teste, comecei a ficar um pouco preocupado que
tivesse escrito acidentalmente um loop infinito ou alguma outra parte de script problemática.
Como o shell continuava lá, parado, e seu cursor piscava pateticamente, me perguntei, “O que eu faço agora?”. Aparentemente, não tenho muita segurança, pois pressionei rapidamente Ctrl+C para interromper o script. É o momento de acrescentar algum relatório de progresso.

Blá, blá, blá
Cmdlet do mês: Tee-Object
Este mês, vou analisar um dos meus cmdlets de solução de problemas favoritos. Veja este, por exemplo:
Get-WMIObject Win32_Service | Where { $_.State -ne "Running"
-and $_.StartMode -eq "Automatic" } | ForEach-Object { $_.Start() }
À primeira vista, ele parece iniciar todos os serviços definidos para iniciar automaticamente, mas que ainda não iniciaram por algum motivo. Isso, na verdade, não funciona, e descobrir o motivo pelo qual não funciona poderia ser complicado, pois você não pode fazer um ponto no meio do pipeline. Ou seja, você não pode fazer um ponto no pipeline, a não ser que esteja usando Tee-Object.
O Tee-Object redireciona objetos para um arquivo (ou uma variável) e os passa para o pipeline. Por exemplo:
Get-WMIObject Win32_Service | Tee-Object AllServices.csv | Where
{ $_.State -ne "Running" -and $_.StartMode -eq "Automatic" } |
Tee-Object FilteredServices.csv | ForEach-Object { $_.Start() }
Essa modificação me permite ver o que acontece depois de cada comando de pipeline e descubro rapidamente que meu arquivo FilteredServices.csv está vazio! Não importa, esse script não funciona! Um pouco mais de pesquisa revela a causa principal do problema – StartMode está como "Auto", não "Automatic" – e o Tee-Object me permite verificar exatamente onde o problema estava ocorrendo.

A primeira ação que eu queria tomar era adicionar várias mensagens de status, permitindo que eu soubesse exatamente o que o script estava fazendo. O shell permite que você faça isso facilmente com o cmdlet Write-Verbose. Siga em frente e experimente isto no shell:
Write-Verbose "Test Message"
Se você já tiver tentado, observou que não resolve. Isso acontece porque o Write-Verbose envia objetos ao pipeline Verbose especial, que, por padrão, não exibe sua saída. Uma variável interna do shell, $VerbosePreference, controla esse pipeline. O valor padrão dessa variável é SilentlyContinue, que suprime a saída detalhada. Defini-lo como Continue, no entanto, abre o pipeline:
$VerbosePreference = "Continue"
Agora, posso adicionar várias instruções Write-Verbose ao meu script e obter uma visão detalhada do que está acontecendo à medida que a execução for progredindo. E a beleza dessa técnica é que, quando eu tiver concluído os testes e a solução de problemas, posso desativar todos os extras ao definir $VerbosePreference novamente como SilentlyContinue no início do meu script.
Não há necessidade de prosseguir e remover todas as instruções Write-Verbose. Na realidade, como elas permanecem no script, a qualquer momento que eu precisar executar o script manualmente, posso alternar facilmente o pipeline Verbose de novo, se necessário.

Mas eu preciso de verdadeiros avanços
Assim que eu estiver satisfeito com o fato de o script não ser chamado em um loop infinito e estar, de fato, funcionando perfeitamente, posso desativar o pipeline Verbose e executá-lo novamente – apenas para me certificar.
O problema agora é que, apesar de saber que o script está funcionando perfeitamente, não suporto esse cursor piscando. (Tenho problemas para me concentrar. Por isso, procurei desesperadamente algo para me distrair.)
O que eu precisava era de uma indicação geral de quanto o script tinha progredido e alguma idéia de quando seria concluído. Basicamente, desejo algo como uma barra de andamento.
Felizmente, o Windows PowerShellTM inclui o cmdlet Write-Progress. Esse cmdlet não fornece uma barra de progresso gráfico, como a que você vê no Windows®, mas produz uma barra de progresso interessante, como mostra a Figura 1. Ela é semelhante à barra de progresso de cópia de arquivo usada na Instalação no Windows Server® 2003 ou até mesmo no Windows XP.
Figura 1 Quanto o script já progrediu?
Figura 1 Quanto o script já progrediu?
O uso do Write-Progress requer um pouco de explicação. Na verdade, penso que um exemplo seria ainda melhor. Considere este script:
for ($a=1; $a -lt 100; $a++) {
  Write-Progress -Activity "Working..." `
   -PercentComplete $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Ele utiliza Write-Progress para exibir uma barra de progresso. Utilizei o Start-Sleep para fazer com que o script fizesse uma pausa de um segundo sempre que estivesse em loop, de modo que fosse executado lentamente, o suficiente para vermos o andamento, de fato – sem a pausa, o loop conta de 0 a 100 tão rapidamente que a barra de progresso apenas pisca na tela.
Como você pode ver, a Activity – que defini como Working – é exibida no início da barra de progresso. O Status é mostrado logo depois dele e CurrentOperation é exibido na parte inferior. O shell é compatível somente com uma barra de progresso individual por vez. Qualquer uso de Write-Progress irá criar uma nova barra de andamento se não houver uma sendo atualmente exibida ou irá atualizar a que está sendo exibida.
O que não fiz aqui foi informar à barra para desaparecer ao final do andamento. Posso fazer isso simplesmente adicionando o seguinte ao final do meu script:
Write-Progress -Activity "Working..." `
 -Completed -Status "All done."
Em termos gerais, a barra de progresso desaparecerá por si só assim que o seu script for concluído, mas se o seu script tiver outros itens a executar, você desejará ocultar a barra quando tiver concluído; o parâmetro Completed simplesmente remove a barra do monitor.

Tique-taque, tique-taque
Outro uso comum de Write-Progress é para criar uma exibição de “segundos restantes”, em vez de uma barra de progresso real. Por exemplo:
for ($a=100; $a -gt 1; $a--) {
  Write-Progress -Activity "Working..." `
   -SecondsRemaining $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Tudo que fiz aqui foi alterar o loop para contar de 100 a 1 e utilizei o parâmetro SecondsRemaining de Write-Progress, em vez de PercentComplete. O resultado é mostrado na Figura 2. Como você pode ver, o medidor de progresso desapareceu e foi substituído por um relógio de contagem progressiva. O shell converterá automaticamente o número total de segundos restantes em horas, minutos e segundos, oferecendo informações mais acessíveis. O percentual completo mostrado aqui realiza, na verdade, uma contagem progressiva de 100, pois é simplesmente o parâmetro CurrentOperation fornecido. Não há cálculo real do percentual concluído; o Windows PowerShell está simplesmente exibindo o valor atual de $a seguido pela seqüência de caracteres "% complete".
Figura 2 Quanto falta para concluir o script?
Figura 2 Quanto falta para concluir o script?

Scripts com objetivos claros
Adoro escrever scripts que têm um objetivo claro. Posso utilizar a forma de saída detalhada ou apenas uma barra de progresso simples. Isso pode ser para o meu próprio benefício, pela minha falta de atenção, ou para o benefício de outra pessoa que precisará executar meu script do mês a partir de agora. No final das contas, exibir algum tipo de status e informações sobre o andamento será um grande benefício para todos.

Don Jones é editor-colaborador da TechNet Magazine e co-autor de Windows PowerShell: TFM (SAPIEN Press, 2007). Ele é professor de Windows PowerShell (consulte www.ScriptingTraining.com) e pode ser contatado pelo site ScriptingAnswers.com.


 Ei, Equipe de Scripts!: Nossos jogos do shell favoritos
Ei, Equipe de Scripts!
Nossos jogos do shell favoritos
The Microsoft Scripting Guys
Faça download do código deste artigo: HeyScriptingGuy2008_03.exe (150KB)

De acordo com um antigo provérbio, nem o menor dos pássaros cai na terra sem que Deus saiba. Isso não significa que a Equipe de Scripts esteja sugerindo que as pessoas saiam por aí acertando pardais. (Mas se alguém quiser dar conta daqueles pássaros estúpidos que ficam chiando no telhado às 7h da manhã de sábado... bem , isso é outra história. [O Editor de Scripts gosta de pássaros e, portanto, estamos certos de que ao dizer “dar conta”, o que a Equipe de Scripts que escreve esta coluna realmente quis dizer foi “tomar conta”, para que os pássaros permaneçam fortes e saudáveis .-Ed.]) Contudo, é confortante saber que se você cair, alguém cuidará de você, e que não importa o quão pequeno e insignificante você possa parecer, alguém estará cuidando de você. [Mesmo que seja apenas um editor.-Ed.]
O que é verdade em relação aos pássaros é também para scripts da administração do sistema. É seguro dizer que, no mundo dos scripts, a maior atenção é focalizada nos maiores acontecimentos de script: Windows PowerShellTM, VBScript, WMI, ADSI e até mesmo o FileSystemObject. É compreensível que essas tecnologias obtenham maior atenção e publicidade; afinal de contas, elas permitem que você faça realmente muitas coisas interessantes e úteis. Mas isso não significa que essas sejam as únicas tecnologias disponíveis para autores de script. Longe disso.
Pense no objeto Shell, por exemplo. Embora o objeto Shell possa não ser tão conhecido ou tão amplamente divulgado como o Windows PowerShell, ele também é importante – e útil.
Há uma boa chance de que, cedo ou tarde, alguém solicite que você escreva um script de administração do sistema que utilize o objeto Shell. Isso leva a uma pergunta óbvia: o que exatamente você pode fazer com o objeto Shell? Na verdade, há muitas coisas interessantes que você pode fazer com ele, algumas das quais (como gerenciamento de cotas de disco e exibição de uma barra de progresso quando copiar ou mover arquivos) foram abordadas no Microsoft® Windows® 2000 Scripting Guide (microsoft.com/technet/scriptcenter/guide). Na coluna deste mês, vamos mostrar a você mais uma série de coisas que podem ser feitas com o objeto Shell; ações que provavelmente você não sabia que eram possíveis, muito menos usando o objeto Shell.

Mudando a data da última modificação de um arquivo
Muitos de vocês provavelmente estão lendo o título e pensando “Ei, espere aí. Você não pode alterar a data da última modificação de um arquivo usando um script, pelo menos não com o VBScript”. Em relação a isso, só podemos dizer uma coisa: de onde você tirou essa idéia?
Ah, sim; nós, a Equipe de Scripts, provavelmente já dissemos isso anteriormente, não foi? Bem, acontece que estávamos errados. Chocante! Você pode alterar a data da última modificação de um arquivo usando o VBScript. E tudo que você precisa fazer é usar o objeto Shell.
Observação: não se aborreça pergutando como a Equipe de Scripts pôde se enganar em relação a isso; depois de todos esses anos, isso deveria ser óbvio. Uma pergunta mais interessante seria: como conseguimos fazer algo correto?
Então, você deseja alterar a data da última modificação de um arquivo, certo? Para isso, basta usar este script:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")

objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Como você pode ver, não há nada tão complicado nisso. Começamos criando um exemplo do objeto Shell.Application. (Falando nisso, não confunda Shell.Application com Wscript.Shell, o objeto Shell do Host de Scripts do Windows. O objeto Shell que estamos tratando hoje é o objeto Windows Shell.) Depois que nossa instância do objeto Shell estiver funcionando, usamos o método Namespace para fazer a ligação com a pasta C:\Scripts; em seguida, usamos o método estranhamente denominado ParseName para vincular um arquivo específico nessa pasta. Nesse caso, estamos vinculando a uma image JPEG com o nome de arquivo Dr_Scripto.jpg:
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")
E, o que precisamos fazer depois que vinculamos ao próprio arquivo? Isso é fácil; simplesmente atribuímos uma nova data e hora à propriedade ModifyDate:
objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Isso é tudo o que temos de fazer.
Sabe, você têm razão. Isso é muito bom, não? Assim que executarmos o script, a data da última modificação do arquivo será definida como 1º de janeiro de 2008, 8h. (Se você quiser, poderá abrir a pasta C:\Scripts no Windows Explorer para verificar por você mesmo.)
Claro, é possível que alguns de vocês estejam pensando: “Legal. Eu posso mudar a data da última modificação de um arquivo. Mas por que desejo alterar a data da última modificação de um arquivo?”. Bem, várias vezes as pessoas usam a data da última modificação como um tipo de sistema de controle de versão; se você tiver várias cópias de, digamos, um script circulando, uma forma de controlar a versão oficial é verificar a data da última alteração. Ao verificar a data da última modificação, você poderá dizer se uma cópia particular ou não desse script é uma versão não modificada do script original.
Observação: Está bem, certo, alguém pode executar o script que acabamos de mostrar a você e alterar a data da última modificação. Mas apesar de toda a assinatura de código feita por você, alguém sempre pode descobrir uma forma de atingir o sistema. Supondo que você tenha colegas éticos com os quais compartilha scripts, essa abordagem é razoável.
Em algum momento, você pode decidir o que atualizar – e padronizar – a data da última modificação de todos os seus scripts. Como fazer isso? Bem, supondo que todos os seus scripts estejam na pasta C:\Scripts, você pode simplesmente executar a seguinte parte do código:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set colItems = objFolder.Items

For Each objItem In colItems
    objItem.ModifyDate  = _
      "01/01/2008 8:00:00 AM"
Next
Como você pode ver, esse script inicia de modo muito parecido com o primeiro script que mostramos. No entanto, nesse caso, depois que efetuamos a ligação com a pasta C:\Scripts, não usamos ParseName para efetuar a ligação a um arquivo individual nessa pasta. Em vez disso, usamos essa linha de código para retornar uma coleção de todos os arquivos encontrados nessa pasta:
Set colItems = objFolder.Items
Assim que tivermos a nossa coleção, vamos configurar um loop For Each para percorrer todos os itens na coleção. Dentro do loop For Each, usamos esta linha de código útil para alterar o valor da propriedade ModifyDate da primeira linha na coleção para 1º de janeiro de 2008, 8h:
objItem.ModifyDate  = _
  "01/01/2008 8:00:00 AM"
E, em seguida, simplesmente executamos o loop e repetimos o processo com o próximo arquivo na coleção. Quando tudo isso tiver sido concluído, todos os arquivos na pasta C:\Scripts (bem, exceto para quaisquer arquivos ocultos) terão exatamente a mesma data da última modificação. Viu como é fácil? Agora, quem disse que você não pode alterar a data da última modificação de um arquivo usando o VBScript?
Ah, sim.

Falando em estar errado...
De volta a tempos remotos, quando a Equipe de Scripts iniciou pela primeira vez o trabalho com script de administração de sistema, não havia como acessar todas as informações de arquivo estendido anexadas a um arquivo no sistema de arquivos NTFS. Por exemplo, se você clicar com o botão direito em um arquivo .wav e, em seguida, clicar em Propriedades, verá informações semelhantes ao que está na Figura 1.
Figura 1 Resumo de propriedades do arquivo
Figura 1 Resumo de propriedades do arquivo
Como você recupera valores como Taxa de bits ou tamanho da amostra de áudio usando um script? Não é possível fazer isso. Bem, a não ser que você use o objeto Shell. (Ou Windows Desktop Search 3.0, pressupondo que você baixou e instalou esse software.) Em algum momento durante o processo, a capacidade de recuperar todas as informações de propriedade estendida de um arquivo foi adicionada ao objeto Shell, mas de alguma forma a Equipe de Scripts não detectou isso. Conseqüentemente, dizemos às pessoas, “Você não pode usar um script para determinar a taxa de bits de um arquivo .wav”, mas mesmo assim, como mostra o código na Figura 2, você pode.
Figure 2 Use um script para localizar a taxa de bits de um arquivo .wav (Close Figure 2)
Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = objFolder.ParseName("J0388563.wav")

For i = 0 to 33
    strHeader = objFolder.GetDetailsOf(objFolder.Items, i)
    strValue = objFolder.GetDetailsOf(objFolderItem, i)
    If strValue <> "" Then
        Wscript.Echo strHeader & vbTab & strValue
    End If
Next
Como esse script funciona? Bem, esse script inicia da mesma forma que o primeiro script que lhe mostramos: criamos uma instância do objeto Shell.Application e a vinculamos à pasta C:\Scripts; em seguida, usamos o método ParseName para vincular ao arquivo em questão (nesse caso, J0388563.wav).
Nesse momento, as coisas ficam um pouco complicadas. Para começar, configuramos um loop For Next que é executado de 0 a 33; isso porque os arquivos são compatíveis com 31 propriedades estendidas diferentes que receberam números de índice de 0 a 3. (Observe que há alguns números, como 27 e 28, que são números de índice válidos mas não contêm valores de propriedades.) Na verdade, os arquivos são compatíveis com as propriedades mostradas na Figura 3.
Figure 3 Propriedades do arquivo (Close Figure 3)

Índice | Propriedade
0 | Nome
1 | Tamanho
2 | Tipo
3 | Data da modificação
4 | Data da criação
5 | Data de acesso
6 | Atributos
7 | Status
8 | Proprietário
9 | Autor
10 | Título
11 | Assunto
12 | Categoria
13 | Páginas
14 | Comentários
15 | Copyright
16 | Artista
17 | Título do álbum
18 | Ano
19 | Número do controle
20 | Gênero
21 | Duração
22 | Taxa de bits
23 | Protegido
24 | Modelo da câmera
25 | Data em que a imagem foi feita
26 | Dimensões
29 | Nome do episódio
30 | Descrição do programa
32 | Tamanho da amostra de áudio
33 | Taxa da amostra de áudio
Então, o que fazemos dentro desse loop For Next? Bem, a primeira coisa é executar esta linha de código:
strHeader = _
  objFolder.GetDetailsOf(objFolder.Items, i)
O que estamos fazendo aqui é usar o método GetDetailsOf para recuperar o nome da propriedade 0 (lembre-se, o nosso loop é executado de 0 a 33). Então, armazenamos esse nome em uma variável nomeada strHeader e usamos essa linha de código para recuperar o valor de propriedade do item 0, armazenando as informações retornadas em uma variável nomeada strValue:
strValue = _
  objFolder.GetDetailsOf(objFolderItem, i)
Entendeu como funciona? O item 0 é a propriedade Name. Então, na primeira vez que o loop é percorrido, strHeader será igual a Name. Enquanto isso, o nome real (ou seja, o valor da propriedade Name) desse primeiro arquivo é J0388563.wav. Portanto, na primeira vez que o loop é percorrido, strValue será igual a J0388563.wav Quando o colocamos dessa forma, ele não parece tão complicado, não é mesmo?
Como você provavelmente já sabe, nem todos os tipos de arquivos são compatíveis com todas as propriedades estendidas. (Por exemplo, um arquivo .jpg não irá ter um título de álbum nem uma taxa de amostra de áudio.) Portanto, na próxima linha de código, verificamos para ver se um valor retornado é uma seqüência de caracteres vazia:
If strValue <> "" Then
Se o valor for uma seqüência de caracteres, então simplesmente voltamos para o início do loop e repetimos o processo com a próxima propriedade estendida. Se o valor não for uma seqüência de caracteres vazia, repetimos o nome da propriedade e o valor, da seguinte forma:
Wscript.Echo strHeader & vbTab & strValue
O resultado líquido? Algo muito semelhante a isso:
Nome    j0388563.wav
Tamanho    169 KB
Tipo    Wave Sound
Data de modificação   1/19/2004 8:56 AM
Data de criação    3/6/2006 2:02 PM
Data de acesso   12/3/2007 10:41 AM
Atributos      A
Status  Online
Proprietário   FABRIKAM\kenmyer
Taxa de bits        90kbps
Tamanho da amostra de áudio       4 bit
Taxa da amostra de áudio       11 kHz
Legal.
Estamos com pouco tempo (e espaço), mas se você procura uma forma mais fácil de retornar para os valores de propriedade mais relevantes, experimente o script na Figura 4.
Figure 4 Uma forma fácil de retornar valores de propriedade (Close Figure 4)
Const colInfoTip = -1

Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("01. Out On The Weekend (Album Version).wma)")

Wscript.Echo objFolder.GetDetailsOf(objFolderItem, colInfoTip)
O que esse script faz? Bem, se você estiver no Windows Explorer e parar o ponteiro do mouse sobre um arquivo, uma dica de ferramentas será exibida e lhe fornecerá algumas informações úteis sobre o arquivo, como as informações mostradas na Figura 5. Como você pode obter essas informações de dicas de ferramentas usando um script? É isso mesmo. Use o script que acabamos de mostrar:
Figura 5 Propriedades mostradas em uma dica de ferramentas
Figura 5 Propriedades mostradas em uma dica de ferramentas
Artista: Neil Young
Título do álbum: Harvest
Ano: 1972
Número do controle: 1
Duração: 0:04:35
Tipo: Windows Media Audio file
Taxa de bits: 256kbps
Protegido: Yes
Tamanho: 5.31 MB
Acabou o espaço que tínhamos para a coluna deste mês. Bem, uma última observação sobre pássaros. Um motivo para você estar atento aos pequenos pássaros é: em algumas partes do mundo, é considera-se má sorte um pássaro entrar na sua casa. Por quê? Porque isso significa que alguém que mora na casa irá morrer. (Em alguns casos isso é verdade somente se o pássaro pousar em um piano. Mas isso não é superstição, é apenas mistério.) Mas aqui está a parte interessante: em outras partes do mundo, um pássaro entrar na sua casa significa que alguém que mora lá irá se casar. Isso é que é estar preso entre a cruz e a espada, hein?

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

Março de 2008: script enigmático
O quebra-cabeça deste mês é um criptograma, o que significa que cada letra foi substituída por uma letra diferente. (Deixamos todos os símbolos e números intactos.) A mesma letra representará sempre uma letra substituída. Por exemplo, todas as ocorrências da letra a podem ser substituídas pela letra b, todas as ocorrências da letra b seriam substituídas pela letra z e assim por diante. Este é um exemplo simples:
tdsjqu dfoufs
é decodificado assim:
script center
A decodificação nesse caso foi feita substituindo cada letra pela letra do alfabeto que a precede; portanto, t foi substituído por s, d foi substituído por c e assim por diante.
O quebra-cabeça é um pouco mais aleatório do que isso. Decodifique esse script e você terá um script que abre uma instância do Microsoft Excel®, adiciona uma nova planilha, atribui quatro valores à primeira coluna na planilha e, em seguida, classifica essa coluna na ordem ascendente.
Divirta-se!

O quebra-cabeça
kqyjs edfjkzyrlyg = 1
kqyjs edyq = 2
kqyjs edjqtstqmj = 2

jzs quwzekzd = ktzfszquwzks("zekzd.faadlkfslqy")
quwzekzd.iljludz = stcz

jzs quwmqtxuqqx = quwzekzd.mqtxuqqxj.frr
jzs quwmqtxjozzs = quwmqtxuqqx.mqtxjozzsj(1)

quwmqtxjozzs.kzddj(1, 1) = "kfs"
quwmqtxjozzs.kzddj(1, 2) = "rqg"
quwmqtxjozzs.kzddj(1, 3) = "ufs"
quwmqtxjozzs.kzddj(1, 4) = "faz"

jzs quwtfygz = quwzekzd.fkslizkzdd.zysltztqm
quwtfygz.jqts quwtfygz, edfjkzyrlyg, , , , , , edyq, , , edjqtstqmj

O desafio de script do Dr. Scripto
Resposta: script enigmático, março de 2008
Veja a chave para decodificar o script:
Actual Letter	a	b	c	d	e	f	g	h	i	j	k
Coded Letter	f	u	k	r	z	b	g	o	l	w	x

Actual Letter	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z
Coded Letter	d	n	y	q	a	h	t	j	s	c	i	m	e	v	p
E aqui está o script decodificado:
Const xlAscending = 1
Const xlNo = 2
Const xlSortRows = 2

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True

Set objWorkbook = objExcel.Workbooks.Add
Set objWorksheet = objWorkbook.Worksheets(1)

objWorksheet.Cells(1, 1) = "Cat"
objWorksheet.Cells(1, 2) = "Dog"
objWorksheet.Cells(1, 3) = "Bat"
objWorksheet.Cells(1, 4) = "Ape"

Set objRange = objExcel.ActiveCell.EntireRow
objRange.Sort objRange, xlAscending, , , , , , xlNo, , , xlSortRows

The Microsoft Scripting GuysA Equipe de Scripts trabalha na – quer dizer, é contratada pela – Microsoft. Quando não estão jogando/treinando/assistindo beisebol (e diversas outras atividades), eles administram o Script Center da TechNet. Confira no site www.scriptingguys.com.


 Security Watch: Usando o ACS no Windows Server 2008
Security Watch
Usando o ACS no Windows Server 2008
Jesper M. Johansson
Este artigo se baseia em uma versão de pré-lançamento do Windows Server 2008. Todas as informações deste artigo estão sujeitas a alterações.

Em 2005, a Microsoft lançou o Windows Server 2003 SP1. Esse service pack introduziu a primeira ferramenta para Windows de gerenciamento de segurança baseada em funções: o ACS (Assistente de Configuração de Segurança). A Microsoft projetou o ACS para ser, antes de tudo, uma ferramenta para redução da superfície de ataque. Sua finalidade era analisar o que você estava
realmente fazendo com o computador e configurá-lo automaticamente para dar suporte às funções de que precisava, desabilitando os serviços e as funções que não estivessem em uso.
O Windows Server® 2008 manteve o ACS, que foi atualizado com novas funções e a integração ao novo Firewall do Windows®. Entretanto, ele continua sendo uma ferramenta de administração avançada como sempre foi.
O Windows Server 2008 também inclui uma nova ferramenta baseada em funções, o Gerenciador de Servidores, e seus parentes, os Assistentes para Adicionar Funções e para Adicionar Recursos. No Windows Server 2008, em vez de adicionar componentes individuais através do antiquado painel de controle Adicionar ou Remover Componentes do Windows, agora você pode usar as ferramentas de gerenciamento de funções para configurar o servidor. Byron Hynes aborda essas ferramentas no artigo "Configurando funções com o Gerenciador de Servidores", também nesta edição da TechNet Magazine.
Os Assistentes para Adicionar Funções e para Adicionar Recursos foram desenvolvidos para configurar o servidor com os componentes certos para dar suporte às funções escolhidas por você. Eles também configuram o firewall interno para garantir que essas funções funcionem corretamente. Isso posto, você pode estar se perguntando se ainda há necessidade do ACS. Admito que muitos administradores não precisarão mais do ACS. No entanto, há dois grupos de pessoas para quem o ACS pode ser uma ferramenta inestimável. O primeiro grupo é formado pelos paranóicos por segurança. Trata-se de pessoas que apreciam como o ACS leva a segurança ao próximo nível.
Você pode pensar nos Assistentes para Adicionar Funções e para Adicionar Recursos como as ferramentas que tomam um servidor padrão e o configuram para dar suporte seguro às funções e aos recursos desejados. O ACS, por outro lado, é a ferramenta que configura o servidor para dar suporte apenas às funções e aos recursos desejados. O ACS também tem um efeito pedagógico, pois ajuda a entender melhor como o servidor é configurado. Portanto, recomendo enfaticamente que você execute o ACS depois que o servidor tiver sido configurado com seu complemento de funções e recursos.
O segundo grupo consiste naqueles usuários que querem entender as relações entre os diversos componentes. O ACS vem com um conjunto de arquivos XML que documentam as relações entre funções e recursos, serviços e portas de rede. Trata-se de uma ferramenta muito valiosa para quem está interessado em entender do que os diversos componentes precisam.
Nesta coluna, descreverei como o ACS funciona e como você o usará para proteger o servidor. Farei também uma comparação entre o ACS e as ferramentas do Gerenciador de Servidores. Observe que esta coluna é adaptada do meu livro Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008).

Visão geral do Assistente de Configuração de Segurança
Para preparar o terreno, quero apresentar algumas estatísticas sobre a superfície de ataque no Windows Server 2008. Antes de você configurar um servidor adicionando sua seleção pessoal de funções e recursos, ele ainda tem uma capacidade de serviços relativamente significativa. Por padrão, o Windows Server 2008 tem 105 serviços, sendo que 42 estão definidos para inicialização automática, 55 para manual e 8 desabilitados. Confronte isso com uma instalação limpa do Windows Server 2003 R2 SP2, que tem 86 serviços instalados por padrão, sendo que 34 estão definidos para iniciar automaticamente, 32 para iniciar por demanda e 20 desabilitados.
Mesmo com a metáfora de funções e a redução em funções padrão com suporte, o Windows Server 2008 ainda tem uma capacidade maior e requer cuidados adicionais na proteção aos servidores. O ACS o orientará na criação de uma configuração de segurança personalizada para seus servidores específicos.
Em relação às ferramentas existentes, o ACS adota uma abordagem completamente diferente para a proteção de servidores. Ele trabalha com uma metáfora de funções para configurar o sistema de modo a dar suporte a essas funções e pouco (ou nada) mais. Embora o ACS ajude a configurar o firewall, como fazem os Assistentes para Adicionar Funções e para Adicionar Recursos, ele também desabilita serviços desnecessários e define algumas configurações de segurança adicionais. Finalmente, enquanto os Assistentes para Adicionar Funções e para Adicionar Recursos só são capazes de instalar e configurar funções internas no Windows, o ACS é extensível. Um desenvolvedor ou administrador pode escrever um arquivo personalizado de configuração de funções ou recursos e usar o ACS para configurar qualquer produto.
O ACS foi projetado para ser usado depois que você instalar todas as funções e todos os recursos que o servidor deve ter. Se houver aplicativos de terceiros no servidor, eles também deverão ser instalados antes da execução do ACS.
Para demonstrar como isso funciona, configurei um servidor com três funções (Servidor de Aplicativos, Servidor DNS e Servidor Web) e dois recursos (Recursos do Microsoft® .NET Framework 3.0 e Serviço de Ativação de Processos do Windows). Esse não é um conjunto particularmente lógico de funções e recursos, mas serve de exemplo para esta discussão.
Para iniciar o ACS, execute-o no menu Ferramentas Administrativas. A Figura 1 mostra a caixa de diálogo que será exibida.
Figura 1 O ACS começa a perguntar o que você deseja fazer
Figura 1 O ACS começa a perguntar o que você deseja fazer
A primeira etapa é escolher se deseja criar uma nova diretiva de segurança, editar ou aplicar uma diretiva existente ou reverter uma diretiva para que o sistema retorne às configurações originais. As opções são relativamente auto-explicativas.
Quando você opta por criar uma nova diretiva de segurança, o ACS a cria usando algum computador como modelo para aquilo a que a diretiva deve dar suporte. Ele analisa o computador e determina quais recursos e funções ele suporta, garantindo que funcionem mas também que muitos recursos desnecessários não sejam habilitados.
O ACS funciona em um modelo de protótipo. Ele usa arquivos XML para especificar a aparência das funções e dos recursos em termos de quais arquivos estão instalados, quais serviços estão configurados, etc. É por isso que você precisa ter tudo instalado no computador em relação ao qual está desenvolvendo a diretiva. Se você tiver programas de terceiros que instalam definições do ACS durante a instalação, eles se integrarão diretamente. No entanto, se os seus programas de terceiros não instalarem definições do ACS, você precisará configurá-las manualmente.
Como você pode ver, é possível criar uma diretiva em um sistema e depois aplicá-la em muitos outros. Caso você esteja desenvolvendo uma rede com muitos sistemas, primeiro defina classes host que sejam configuradas separadamente. Em seguida, crie uma diretiva usando uma delas como protótipo e aplique a diretiva a todas as outras, com pouca ou nenhuma modificação.
Quando você clicar em Avançar (na caixa de diálogo mostrada na Figura 1), o assistente perguntará qual computador deseja usar como linha de base (ou seja, protótipo) para essa nova diretiva. Normalmente, você escolheria o computador local, mas também há a opção de usar um computador remoto como protótipo.
Depois de especificar qual sistema deverá ser usado, você entra na fase de análise. Aqui, o ACS enumera quais funções e recursos estão instalados e faz a correspondência em relação ao banco de dados de funções e recursos. O banco de dados contém informações relativas a quais serviços são usados por cada função e recurso, de quais portas de rede eles precisam e outras informações de configuração importantes. Uma vez concluída a análise, você pode clicar em Exibir Banco de Dados de Configuração para ver o que o Assistente de Configuração de Segurança encontrou. Observe que é uma exibição somente leitura que apresenta informações abrangentes sobre a configuração do computador. Na verdade, se você estiver realmente interessado em entender o que há no computador, poderá gastar um bom tempo estudando essas informações.

Configurando o seu servidor com o ACS
Quando você clicar em Avançar, entrará na primeira das quatro seções do ACS: a Configuração de Serviços com Base em Funções. Você poderá observar que as funções encontradas no ACS, como mostra a Figura 2, não são o mesmo conjunto encontrado no Assistente para Adicionar Funções. A maioria das funções nele disponíveis também estão presentes aqui, mas o ACS ainda oferece algumas a mais. Por exemplo, a função Servidor de Aplicativos que selecionei não está presente. Isso ocorre porque o ACS usa uma metáfora ligeiramente diferente para funções. Discutirei isso detalhadamente em breve.
Figura 2 Usando o ACS para selecionar a funções às quais deseja que o servidor dê suporte
Figura 2 Usando o ACS para selecionar a funções às quais deseja que o servidor dê suporte
Em geral, o conjunto certo de funções já vem selecionado nesta caixa de diálogo. Com isso, basta verificar se a análise encontrou o que você acha que deveria ter encontrado. Se algo estiver errado, confira se a função foi instalada e, caso contrário, instale-a antes de tornar a executar o ACS. Caso você cometa um erro, não é o fim do mundo. O recurso de reversão no ACS o levará de volta ao ponto de partida, desfazendo as alterações feitas pela diretiva.
As respostas dadas nesta seção são muito importantes porque determinam o que você verá mais tarde na seção sobre rede. Felizmente, a lógica de detecção é muito boa e o conjunto correto de funções normalmente é selecionado.
Observe também que, por padrão, você vê Funções Instaladas, às quais o servidor é capaz de dar suporte com os bits colocados no disco. As funções selecionadas são aquelas que têm suporte no momento. Você também pode optar por ver todas as funções existentes no banco de dados; basta selecionar Todas as Funções na lista suspensa. Isso é útil basicamente quando você precisa criar uma diretiva usando um servidor de protótipo que não tem ainda todas as funções necessárias instaladas.
Após a configuração de funções, você seleciona os recursos de cliente aos quais deseja dar suporte. O conjunto de recursos é semelhante, mas não idêntico ao existente no Assistente para Adicionar Recursos, além de possuir uma quantidade menor de recursos. Mais uma vez, como as metáforas não são exatamente as mesmas e o ACS pode ser estendido, o que você verá é diferente do Assistente para Adicionar Recursos.
Quando você clicar em Avançar na página Recursos de Cliente no ACS, irá para a caixa de diálogo Selecionar Administração e Outras Opções, como mostra a Figura 3. Uma Opção no ACS é algo que não se adapta harmoniosamente em uma função nem em um recurso. Ela pode fornecer suporte administrativo ou ser simplesmente um único serviço, como a Detecção de Serviços Interativos. Novamente, a maioria das opções de que você precisa devem ser selecionadas aqui. Vale a pena destacar o menu suspenso, também. Ele é populado com opções relevantes às funções e aos recursos que você selecionou anteriormente e será diferente em diferentes computadores.
Figura 3 Selecionando outros serviços e recursos no ACS
Figura 3 Selecionando outros serviços e recursos no ACS
A próxima etapa é a caixa de diálogo Selecionar Serviços Adicionais. Embora o ACS seja fornecido com um banco de dados de serviços bem grande, nem tudo está descrito aqui. Esses serviços que o ACS encontra em um computador e que não estão presentes no banco de dados são exibidos na página Serviços Adicionais. Todos os serviços internos devem ser descritos, e você não deverá ver esta caixa de diálogo a menos que tenha algum serviço de terceiros instalado.
O assistente então permite que você selecione o que fazer com os serviços que não está configurando. Esta opção é indicada para quando você planeja tomar a diretiva que está criando e aplicá-la em um computador diferente. Se esse computador tiver serviços diferentes do que você usou para criar a diretiva, o ACS precisará saber o que fazer com eles. Uma opção é deixá-los sozinhos, o que é o padrão. A outra opção é desabilitá-los, que, embora mais seguro, pode danificar itens. Porém, se você seguir o conselho de só aplicar diretivas a servidores idênticos ao que você usou para criá-las, sua opção nesta página será irrelevante.
Agora que você terminou a parte de configuração de funções do ACS, o assistente recapitula o que foi feito. Como pode ver na Figura 4, você afetará a superfície de ataque do computador mesmo se simplesmente clicar com o botão direito do mouse. Por exemplo, como esse computador não é um Servidor de Impressão e não tem nenhuma impressora instalada, não há motivo para você executar o serviço Spooler de Impressão. O ACS desabilita todos os serviços que não são necessários. No nosso servidor de teste, o ACS desabilita 17 serviços que foram definidos para inicialização automática e define 42 serviços de inicialização manual como desabilitados. Nossos resultados, obviamente, irão variar de acordo com a configuração do servidor, mas você pode ver que o ACS permite adaptar uma diretiva específica para servidores exclusivos, reduzindo drasticamente a superfície de ataque deles.
Figura 4 O ACS resume as alterações feitas
Figura 4 O ACS resume as alterações feitas
Agora, vamos passar para a seção que, comprovadamente, é a mais importante do ACS: Sistema de Rede. Após a página de boas-vindas inicial, você vê a caixa de diálogo Regras de Segurança de Rede, mostrada na Figura 5. Ela contém uma lista de todas as regras de firewall propostas pelo ACS, que se baseiam no suporte a funções selecionado por você nas seções anteriores.
Figura 5 O ACS lista todas as regras que ele define como necessárias
Figura 5 O ACS lista todas as regras que ele define como necessárias
Se nenhuma configuração adicional for feita na seção Rede, o ACS criará regras de firewall que bloqueiam as interfaces de rede para que apenas essas funções e esses recursos tenham suporte, mas todos os clientes possam acessá-los. Entretanto, para otimizar realmente a segurança em seus servidores, você deve usar o ACS como parte integrante na criação de uma estratégia de isolamento de servidor. Para saber mais sobre isolamento de servidor (e seu irmão, isolamento de domínio), dê uma olhada em technet.microsoft.com/network/bb545651.
No Windows Server 2008 Security Resource Kit, há um capítulo sobre como proteger a rede com isolamento de servidor e de domínio. Ele também aborda como usar a modelagem de ameaças à rede para analisar a rede e facilitar a implantação do isolamento de servidor. O ACS é uma ferramenta valiosa nesse processo.
Você pode configurar restrições nas regras propostas selecionando a regra e clicando em Editar. Isso o remeterá à caixa de diálogo mostrada na Figura 6. Essa é uma das quatro páginas que permitem estabelecer restrições adicionais nas regras de sistema de rede. Por exemplo, você pode exigir autenticação IPsec. Isso lhe permite associar a porta a apenas certos pontos de extremidade. Por exemplo, você pode configurá-la para que permita administração remota apenas de certos hosts. Como você pode ver, é uma vantagem fundamental em relação aos Assistentes para Adicionar Funções e para Adicionar Recursos.
Figura 6 O ACS permite criar regras de firewall e de IPsec
Figura 6 O ACS permite criar regras de firewall e de IPsec
Essa capacidade de criar regras de segurança da conexão baseadas nas funções selecionadas atende a dois objetivos importantes. Primeiro, ela oferece uma oportunidade de ouro para entender o que os servidores estão fazendo. Você não precisa nem criar um servidor; basta executar o assistente, fazer seleções diferentes e ver como elas afetam as opções nas páginas posteriores. Segundo, ela permite associar o conceito bem abstrato de porta a um conceito muito mais lógico de serviço, além de configurar restrições de rede baseadas exatamente no que o sistema está realmente fazendo.
Feito corretamente, isso permite desenvolver uma configuração bem firme para os servidores. A seção Sistema de Rede do ACS é, sem dúvida alguma, aquela à qual você deve dedicar a maior parte do tempo ao criar a diretiva de segurança para seus servidores.
O restante do ACS permite definir algumas configurações do Registro e auditoria. As configurações padrão desses parâmetros são adequadas para a maioria das organizações e, a menos que você tenha requisitos especiais, não há muito que fazer aqui.
Depois de criar sua diretiva, você pode salvá-la e aplicá-la ao computador no qual está trabalhando ou em outros computadores. Também pode transformar sua diretiva em um GPO (objeto de diretiva de grupo) usando o comando scwcmd.exe /transform.
Entretanto, caso haja configurações específicas de computador na diretiva, isso pode não dar certo – ou pode dar resultados bem estranhos. Por exemplo, se você criar restrições de ponto de extremidade que incluam adaptadores locais na seção de sistema de rede, a diretiva será considerada específica de computador e não será transformada com êxito. Isso se deve ao fato de que esses adaptadores precisam ser especificados por meio de GUIDs. O GUID de um adaptador em um computador não faz sentido em outro computador.
Portanto, o ACS costuma ser mais bem utilizado em uma base de servidor a servidor e como ferramenta de aprendizado. Para grandes farms de servidores, você pode usar o ACS como forma de aprender sobre os computadores e desenvolver uma diretiva básica. Depois você toma essa diretiva e a recria para ser implementada através de qualquer ferramenta usada para configurar os servidores, como Diretiva de Grupo ou um sistema corporativo de gerenciamento (o Microsoft Systems Center, por exemplo).

ACS versus Gerenciador de Servidores
Você já viu até agora que a metáfora usada para funções e recursos difere. Um "recurso" no ACS é algo que o computador faz para funcionar como cliente. Já uma "função" é algo que ele faz para funcionar como servidor.
Isso difere da metáfora usada nas ferramentas do Gerenciador de Servidores, nas quais uma função é uma coletânea de serviços e recursos que podem ser considerados uma unidade, e um recurso é algo que dá suporte às funções. Em essência, o Gerenciador de Servidores considera uma função como aquilo que motivou a compra do servidor. Os recursos são importantes, mas não foi para isso que você comprou o servidor. As duas metáforas e os dois usos diferentes dos mesmos termos tendem a confundir as pessoas. Você precisará parar e pensar sobre isso com cuidado antes de alternar entre as ferramentas.
Além disso, as ferramentas do Gerenciador de Servidores não são extensíveis. Elas foram projetadas para gerenciar apenas os componentes fornecidos com o Windows. Em compensação, os programas de terceiros instalados por você podem adicionar funções e recursos ao ACS. Você pode até escrever seus próprios recursos e funções. O white paper "Extending the Security Configuration Wizard" (disponível em go.microsoft.com/fwlink/?LinkId=107397) explica como fazer isso.
O ACS também desabilita componentes desnecessários. As ferramentas do Gerenciador de Servidores, por outro lado, implantam simplesmente os componentes solicitados, ou seja, não tocam em nada mais no computador. Se você precisar de ajuda para determinar quais componentes podem ser desnecessários, use o ACS.
Além disso, embora tanto o ACS como as ferramentas do Gerenciador de Servidores configurem a rede, o ACS é de longe mais eficaz nesse sentido. Se você estiver criando uma estratégia de isolamento de servidor, o ACS pode ser uma mina de ouro de informações e seu melhor amigo na implementação. Obviamente, esse é um tópico de administração de segurança avançada, mas o ACS é uma ferramenta de segurança avançada.
Finalmente, o ACS também irá definir algumas configurações de segurança adicionais que as ferramentas do Gerenciador de Servidores não configuram. No entanto, elas foram amplamente substituídas por controles mais efetivos – ou já definidos por padrão – no Windows Server 2008.

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


 Os arquivos da &#225;rea de trabalho: Nem tanto nem t&#227;o pouco
Os arquivos da área de trabalho
Nem tanto nem tão pouco
Wes Miller

Se você já esteve no campus da Microsoft, provavelmente já viu sistemas de quiosque de uso compartilhado nas áreas de recepção da maioria dos prédios. Esses sistemas foram incorporados com um front-end baseado na Web conectado aos Serviços de Terminal do Windows, para que os funcionários que vivem correndo de um prédio para outro possam ver seus emails e ter outra forma de
conectividade. Originariamente, os sistemas foram configurados usando PCs mais antigos que foram retirados do serviço e reciclados. O hardware, que de outra forma seria muito lento, com pouca memória e unidades de disco rígido inadequadas, foi perfeito para aplicativos de clientes finos. Se você tiver hardware mais antigo por qualquer outro motivo, poderá fazer um bom uso dele como estações de trabalho em salas de conferência, como máquinas de treinamento e assim por diante. Em vez de aumentar os aterros sanitários, pense ecologicamente e economize mais.
Se a sua organização estiver buscando uma atualização do Windows Vista®, você poderá descobrir que o seu hardware é mais antigo do que você pensava. Isso pode significar nenhum suporte TPM (Trusted Platform Module) ou Aero®, mas se todos os sistemas precisarem de uma unidade de disco rígido maior ou mais RAM, então atualize o hardware. No entanto, alguns dos seus sistemas simplesmente não poderão executar o Windows Vista, pois o hardware é muito inferior ou está sem os principais recursos. Esse é o hardware perfeito para execução como um cliente fino do Windows®. A Figura 1 relaciona os requisitos de hardware do Windows Vista, de modo que você saberá em qual classificação o seu hardware atual se encaixa.
Figure 1 Requisitos de hardware do Windows Vista (Close Figure 1)

Hardware | Requisitos
CPU | Recomenda-se mais de 1 GHz. A velocidade da CPU pode determinar a usabilidade do Windows Vista. Uma CPU lenta de um só núcleo não o eliminará, mas poderá torná-lo um excelente cliente fino. Observe que, se você tiver em vista o x64, uma atualização de hardware do Windows Vista é o melhor a fazer antes de mudar para o x64.
Memória | Recomenda-se mais de 1 GB. Com freqüência, é possível adicionar memória a um sistema, mas pense se é economicamente viável instalar memória em dezenas, centenas ou milhares de sistemas.
GPU | Mais de 128 MB de memória gráfica, com capacidade para DirectX® 9.0, com um driver WDDM e suporte para Pixel Shader 2.0. Essa pode não ser a melhor solução pois limita o suporte a Aero.
HD | Mais de 40 GB de disco rígido. Mais provável que seja um problema em sistemas móveis do que em desktops.
Problemas com driver | Estão disponíveis drivers do Windows Vista para todo o hardware nos seus sistemas?
TPM | Se você quiser suporte a BitLocker sem exigir uma unidade flash USB, o seu computador precisará de hardware TPM 1.2.

Então, o que posso fazer com um cliente fino?
Usando hardware antigo e sistemas operacionais menores, você poderá criar quiosques de área/recepção comuns, de modo que os usuários possam se inteirar por email, da mesma forma que fazem nos escritórios da Microsoft. Você pode configurar sitemas que executam Área de Trabalho Remota ou uma instância cuidadosamente gerenciada do Internet Explorer®. Você pode instalar sistemas de reprodução de apresentação em salas de conferência executando o Microsoft PowerPoint® e a Área de Trabalho Remota. Você também pode usar combinações de cliente fino/hardware antigo para sistemas de ponto de venda ou quiosques de pesquisa de trabalho. Então, qual cliente fino devo usar?

Windows XP Embedded
Mencionei nas colunas anteriores como o Windows XP Embedded foi desenvolvido como uma versão maleável e dividida em componentes do Windows XP. Conforme abordado na coluna de Don Jones da edição de abril de 2007 (acesse technetmagazine.com/issues/2007/04/XPe), há várias ferramentas usadas para criar imagens do Windows XP Embedded – sendo a principal delas a Target Designer (consulte a Figura 2). A Target Designer permite que você crie sua própria imagem personalizada do Windows XP Embedded.
Figura 2 Imagem da Target Designer do Windows XP Embedded
Figura 2 Imagem da Target Designer do Windows XP Embedded
Observe que a Target Designer é fornecida com vários modelos de design para ajudá-lo a iniciar. É claro, você pode fazer isso sozinho, mas com um modelo será consideravelmente mais fácil. Na Figura 2 você vê os modelos de Terminal baseado em Windows e Console do quiosque/jogos, que são bons lugares para iniciar. O Windows XP Embedded também lhe fornece suporte total ao dispositivo e gerenciamento de energia nativo, como você teria com a imagem do sistema operacional total (você apenas precisa criar o suporte para isso na sua imagem). É claro, quanto mais recursos você adicionar, mais hardware precisará; portanto, é importante escolher com inteligência. Há informações consideráveis sobre o Windows XP Embedded disponível no site sa Web da Microsoft: microsoft.com/windows/embedded/eval/xpe/default.mspx.

Windows Embedded para ponto de serviço
O Windows Embedded para ponto de serviço (WEPOS) fornece um modelo totalmente padronizado para sistemas de ponto de serviço (POS) incorporados no Windows XP Embedded. O WEPOS fornece suporte incorporado para vários periféricos relacionados a POS e se destina principalmente para uso nos mercados de varejo e hospitalidade. Ao contrário do Windows XP Embedded, ele fornece um conjunto muito fixo de funcionalidade, desenvolvido apenas para essa função, e não pode ser personalizado para o grau que o Windows XP Embedded pode.
A plataforma WEPOS foi desenvolvida para um sistema mínimo, exigindo somente um processador 233 MHz Pentium II ou superior, 64 MB de RAM, e apenas 280 MB para a imagem do sistema operacional central. Informações detalhadas sobre WEPOS e links para solicitar uma versão de avaliação estão disponíveis em microsoft.com/windows/embedded/wepos.

Conceitos básicos do Windows para PCs herdados
Ao contrário do Windows XP Embedded e WEPOS, que foram desenvolvidos principalmente para fabricantes de dispositivos fornecerem em um dispositivo, o Windows Fundamentals for Legacy PCs (FLP) é licenciado como um componente de Software Assurance, desenvolvido para ser usado principalmente nesse cenário. A Figura 3 mostra a tela de instalação do Windows FLP, que oferece quatro opções de configuração para escolha dos usuários: Minimum (Mínima), Typical (Típica), Full (Completa) e Custom (Personalizada).
Figura 3 Instalação do Windows FLP
Figura 3 Instalação do Windows FLP
O Windows FLP requer 64 MB de RAM, 500 MB ou mais de espaço de disco rígido e resolução do monitor de 800x600 ou mais. Os reais requisitos do sistema para o espaço de disco rígido podem variar, dependendo dos componentes do SO que você escolheu instalar.
Se você estiver buscando um sistema operacional mínimo relativamente flexível para usar no hardware legado e já tiver o Software Assurance, então o Windows FLP será uma boa escolha. Acesse microsoft.com/licensing/sa/benefits/fundamentals.mspx para obter mais informações sobre como o Windows FLP pode lhe fornecer uma migração perfeita para o hardware e sistema operacional mais recentes.

Um Windows XP simplificado
Além dessas versões menores, o próprio Windows XP pode ser perfeito para uso como está. Se você não tiver muita RAM, poderá economizar sobrecarga suficiente para fazer com que o sistema funcione adequadamente desabilitando serviços como Temas do Windows e outros. No entanto, saiba o que está desabilitando e certifique-se de que isso não comprometerá a segurança (por exemplo, ao desabilitar o Firewall do Windows).

O que não funcionará
Infelizmente, as pessoas, com freqüência, tentam usar várias outras opções do Windows para sistemas leves. Veja as escolhas mais óbvias e as razões por que cada uma não funcionará como esperado.
O Windows XP Starter Edition é simplificado para uso em sistemas restritos, mas foi projetado principalmente para uso nos mercados de tecnologia de desenvolvimento e está disponível somente como uma cópia licenciada do Windows a partir de um OEM incluído em um novo PC nesses mercados. Portanto, geralmente não é uma opção. Se você estiver curioso, veja o seguinte: microsoft.com/presspass/newsroom/winxp/WinXPStarterFS.mspx.
Da mesma forma, o Windows PE não é uma opção viável. Curiosamente, durante o desenvolvimento do Windows PE, a Microsoft inicialmente pensou que ele seria um SO leve. No entanto, no final das contas, ele simplesmente não foi desenvolvido para ser usado como um SO leve, mas como um ambiente de pré-instalação com foco na implantação mínima. Por exemplo, o Windows PE não tem shell além do prompt de comando (e você não pode adicionar facilmente um shell muito funcional), ele não tem um conjunto de API definido, não tem gerenciamento de energia e não tem suporte de áudio.
Uma versão mais simples do Windows XP também não é uma boa solução. Ouvi dizer que uma opção viável seria reduzir o Windows. Não estou me referindo simplesmente à desativação ou desabilitação de serviços, mas sim, à remoção de aplicativos para se atingir uma instalação simples do Windows. Eu realmente desaconselho essa opção. Se você remover binários do Windows para removê-lo, correrá o risco de torná-lo instável ou não protegido. Se uma versão menor do Windows for o que você precisa, use o Windows XP Embedded. Há uma curva de aprendizagem, e demora algum tempo para que sua imagem seja perfeita, mas ele é muito avançado e, o melhor de tudo, tem o suporte da Microsoft.
Semelhante a uma versão minimizada do Windows XP, o uso de uma versão anterior do Windows pode parecer interessante, mas a falta de suporte, atualizações e segurança deve desanimá-lo. Basta utilizar as soluções para as quais a Microsoft já oferece suporte, a fim de ajudá-lo com suas necessidades de computação leve, para obter o máximo de seu hardware antigo sem sacrificar os recursos apropriados ou a segurança.

Wes Miller é gerente sênior de produto técnico na CoreTrace (www.CoreTrace.com) em Austin, no Texas. Anteriormente, ele trabalhou na Winternals Software e como Gerente de programas na Microsoft. Entre em contato com ele pelo email technet@getwired.com.


 Anota&#231;&#245;es de campo: Prepara&#231;&#227;o para o IT 2.0
Anotações de campo
Preparação para o IT 2.0
Romi Mahajan

Em A vida da razão, o importante filósofo e ensaísta George Santayana escreveu que "aqueles que não são capazes de lembrar do passado estão condenados a repeti-lo”, indicando a extrema importância de se aprender com os erros do passado para se construir efetivamente um futuro melhor. A aplicação desse penamento é evidente nos mundos da política, cultura, história e até mesmo da ciência. Na verdade, a idéia de “aprender com os erros” é tão comum que virou um clichê. Mas quantos de nós do setor de Tecnologia da Informação pensa realmente sobre o passado – e aprende com ele? E se não o fizermos, estaremos preparados para o mundo de TI do futuro? E como será esse futuro?
Bem, vamos adivinhar, usando o poder da memória. Nos últimos 30 anos, as mudanças foram profundas. O setor de TI evolui de grandes mainframes à computação baseada em navegadores, da concentração de dispositivos à proliferação de dispositivos, da imaturidade e da raridade à superespecialização e simplicidade, da simplicidade relativa à extraordinária complexidade. Extrapolando, podemos, portanto, esperar que o setor de TI se torne mais complexo, mais especializado e mais democratizado. O setor de TI também precisa oferecer suporte ao crescente número de tipos de dispositivos e plataformas. Tudo isso requer um planejamento mais detalhado do que nunca.
Essas noções são comumente internalizadas? Nem de longe.
Veja, por exemplo, as conversas em uma recente apresentação sobre “Consumo de TI”, em uma conferência de tecnologia em novembro de 2007. A premissa da apresentação era simples: que as linhas entre as tecnologias empresariais e de consumo foram eliminadas, que os aplicativos e dispositivos de consumo estão liderando os desenvolvimentos de TI e que os departamentos de TI precisam se preparar para a série de fenômenos representada pelos Facebooks, iTunes e BlackBerrys do mundo. Uma idéia simples? Óbvia? Antiquada?
Bem julgando pela reação dos colegas na sala, nem um pouco. De aproximadamente 100, somente quatro mencionaram “Facebook”. "Isso é para os jovens”, afirmou um participante. "Bem, os funcionários do seu departamento de TI não são jovens e estão por dentro do Facebook?”, perguntou um dos nossos palestrantes. O que se seguiu foi confusão e negação. Poucos gerentes de TI presentes perceberam que é necessário desenvolver suas organizações contratando pessoas que compreendam como criar e oferecer suporte a aplicativos e dispositivos nas novas plataformas que ocupam a maior parte do tempo das pessoas.
Quando perguntamos como criar diretivas de TI eficazes para reger o uso e a segurança de tecnologias, como celulares e laptops, que são dispositivos de uso doméstico e empresarial, o público reclamou de imediato, mas não havia uma opinião formada. Um sentimento comum foi expresso por uma pessoa que afirmou na típica lógica draconiana de TI 1.0: “Se alguém no meu escritório conectasse um MP3 player em um laptop de trabalho ou deixasse por engano um celular de trabalho em um local fora do trabalho, eu o demitiria".
Nossa. Siga em frente.
Outra área na qual é possível detectar essa pobreza de pensamento é na aridez das conferências destinadas a líderes de TI. Se eu vir outra conferência dedicada a noções vagas de "alinhamento dos negócios de TI" ou “Cartões comuns de pontuação”, acho que vou parar de viajar. Por que não há mais pessoas se questionando sobre TI 2.0 e o que precisamos para avançar? Por que eles não estão se perguntando quais atributos e atitudes a nova geração de profissionais de TI precisa para criar um futuro dinâmico? Por que não estão lamentando o fato de que uma única empresa vê seu departamento de TI da mesma forma que empresas inovadoras consideram seus departamentos de pesquisa e desenvolvimento? Em vez de discutir a centralização versus a descentralização, por que não combater os reais problemas do totalitarianismo de TI versus a democratização de TI?
Temos que nos valorizar um pouco mais mostrando que nos preocupamos com o nosso futuro. Todos nós já ouvimos falar do Web 2.0. É o momento de começar a pensar no TI 2.0 se pretendemos realizar algo parecido em termos de potencial tecnológico.

Romi Mahajan é diretor de público técnico e da equipe de marketing de plataforma da Microsoft. Romi tem várias publicações em muitos campos, entre eles, política, meio-ambiente, tecnologia e sociologia.


 Segredos do Windows: Como os betas se tornam RCs
Segredos do Windows
Como os betas se tornam RCs
Raymond Chen

Na era do Windows®, as versões de pré-lançamento de produto seguiam claramente uma progressão padrão. Primeiro, foram os lançamentos alfa, que eram usados internamente e possivelmente compartilhados com parceiros de desenvolvimento de software fora da equipe de produto do Windows.
Depois dos lançamentos alfa, surgiram, naturalmente, os lançamentos beta, que foram enviados para um público um pouco mais amplo. A principal diferença entre os usuários de lançamento alfa e beta é que os lançamentos beta incluem pessoas que não são desenvolvedores de software, como usuários finais que gostam de testar software de pré-lançamento e corporações que desejam iniciar antecipadamente a avaliação do novo SO, a fim de determinar a compatibilidade do novo produto, não somente com seus aplicativos internos essenciais, mas também com sua rede corporativa, configurações de hardware padrão e ferramentas de gerenciamento do sistema.
Ao final, havia candidatos para o lançamento. Esses eram, como o nome sugere, versões do código que eram candidatos para o lançamento final. Em outras palavras, “Se tudo der certo, o lançamento será feito”. Se algum bug terrível invalidasse essa expectativa, logo era corrigido, um novo build candidato ao lançamento era lançado e o ciclo de teste, reiniciado. O Windows 95 teve seu sexto candidato a lançamento.
Soube que os colegas do Windows NT® seguiram o mesmo padrão de nomenclatura de lançamento, mas tiveram um problema: as corporações não se importaram em testar seus aplicativos fundamentais com lançamentos beta do Windows NT. A lógica geralmente era: "Por que perder tempo com isso? É apenas um beta. Betas são para os fanáticos. De qualquer forma, a versão final será totalmente diferente. Qualquer teste que fizéssemos agora seria uma perda de tempo.”
Da mesma forma, as empresas de software não deram importância aos problemas encontrados durante os testes beta do Windows NT. "Não oferecemos suporte a sistemas operacionais beta”, eles diriam.
Essas empresas começariam o teste com seriedade assim que surgissem de fato os builds candidatos a lançamento, e então, inevitavelmente encontrariam vários problemas. Alguns eram problemas que as empresas poderiam solucionar sozinhas, enquanto outros eram mais complexos e tinham a ver com o fato de o Windows NT não ser “compatível o suficiente” com a versão anterior do sistema operacional. Havia problemas não tão importantes com relação ao modo como um recurso de projeto específico funcionava, e alguns deles poderiam ser corrigidos em um curto período de tempo. Mas alguns problemas eram tão graves que o lançamento do produto era adiado de forma que a equipe pudesse resolvê-los.
Esses candidatos a lançamento também geraram muitas sugestões. Recebemos comentários, como “a interface do usuário seria melhor se os botões fossem distribuídos dessa forma” e “reformular essa mensagem para que seja menos confusa para os nossos funcionários". Essas seriam excelentes sugestões somente se tivessem sido enviadas durante a fase beta; mas, no momento em que o primeiro candidato ao lançamento foi divulgado, é muito tarde para começar a fazer alterações no design da interface. A documentação e os arquivos de ajuda já foram escritos, o produto foi convertido em vários idiomas e as capturas de tela do manual e do pacote do produto já foram desenvolvidas, ajustadas, separadas por cor e impressas. Tudo esse trabalho não será descartado e refeito somente para mover um botão.
Lembro de uma reunião durante a era Windows XP quando uma dessas alterações de última hora estava sendo discutida. A alteração proposta exigiria que um arquivo de ajuda de 20 KB fosse alterado, de modo que as instruções correspondessem à nova interface do usuário. O representante de localização e tradução nos informou que a retradução do arquivo de ajuda modificado no tempo extremamente curto de tempo custaria milhares de dólares.
Para combater a atitude de que os betas não têm validade, a equipe do Windows NT lançou mão de novas classificações. Ainda há lançamentos beta, mas os mais recentes – quando ainda há algum tempo (mas não muito) para fazer ajustes – se tornaram conhecidos como candidatos a lançamento, e os que eram conhecidos como candidatos a lançamento agora são versões “escrow”. Esse termo define muito bem o verdadeiro estado da versão: “Acabou, e agora ela não será modificada, a menos que seja uma emergência real”.

Raymond Chenpossui um site, The Old New Thing (A velha novidade), e escreveu um livro homônimo (Addison-Wesley, 2007) para tratar da história do Windows e da programação Win32. Ele mora aqui perto do nosso escritório.