 TechNet Magazine February 2007
TechNet Magazine February 2007
FEBRUARY 2007
Administração do Windows

Este mês Mark Russinovich penetra no kernel do Windows Vista para explicar o novos algoritmos de medição de desempenho do processo e thread, que oferecem um quadro mais preciso de como é gasto o tempo de CPU. Ele também discute o Multimedia Class Scheduler Service, que oferece aos usuários uma experiência de reprodução mais contínua, gerenciando melhor tarefas de segundo plano, como indexação de conteúdo e antivírus.

Este mês também analisaremos os recursos de delegação no Active Directory e os modelos de diretiva de grupo no Windows Vista, permitindo a você fazer mais do que nunca com a diretiva de grupo. E, naturalmente, todos os nossos personagens conhecidos estão aqui este mês, incluindo The Cable Guy, a Equipe de Scripts e os Segredos do Windows.
RECURSOS
Administração do Windows Dentro do kernel do Windows Vista: Parte 1

Com o Windows Vista, as alterações no kernel do sistema operacional ocasionam avanços em muitas áreas, que vão desde gerenciamento de memória até confiabilidade e segurança. Começamos esta série com uma análise de como o kernel oferece aprimoramentos nas áreas de processos, segmentos e E/S.

Mark Russinovich Delegando autoridade no Active Directory

A implementação de delegação no Active Directory pode aprimorar a segurança e simplificar as tarefas de gerenciamento; e começar é mais fácil do que você imagina. Eis aqui alguns modelos de delegação simples que funcionarão na maioria das infra-estruturas de TI com pouca modificação.

Joel Yoker and Rob Campbell Investigue os novos modelos de Diretiva de Grupo no Windows Vista:

O Windows Vista introduziu alterações significativas nos modelos de Diretiva de Grupo. Descubra tudo o que você precisa saber sobre o novo formato, chamado de ADMX, e como essas alterações irão melhorar a administração de configurações do sistema.

Darren Mar-Elia Seu guia para a solução de problemas de Diretiva de Grupo

Chegar aos fundamentos dos problemas de Diretiva de Grupo pode ser um processo difícil, mas entender como funciona a Diretiva de Grupo e de onde podem surgir os problemas torna as coisas mais fáceis. Esta visão geral o ajudará a solucionar problemas de Diretiva de Grupo como um guru.

Derek Melber Monitorando o Active Directory com o MOM

Os pacotes de gerenciamento do Microsoft Operations Manager 2005 permitem monitorar a sua infra-estrutura de TI de maneira mais eficaz. Veja como esses cinco pacotes de gerenciamento podem ajudá-lo a ficar atento a itens como integridade, segurança e confiabilidade do seu ambiente do Active Directory.

John Hann Jogando em um ambiente seguro

Esteja ocupado no trabalho ou compenetrado em algum jogo em casa, a execução como usuário com acesso limitado traz muitos benefícios à segurança. Infelizmente, alguns jogos não funcionam quando não são executados como administrador. Vejamos alguns problemas comuns e as respectivas soluções.

Matt Clapham
COLUNAS
Do Editor

Nos bastidores

Joshua Trupin Toolbox

Novos produtos para profissionais de TI

Greg Steen P&R do SQL

Tamanho do banco de dados, espelhamento, transações marcadas e muito mais

Editado por Nancy Michell Destaque de utilitário

Estoque de Diretiva de Grupo

Greg Steen The Cable Guy

Suporte de QoS no Windows

Joseph Davies 		Windows PowerShell

Criando scripts uma linha por vez

Don Jones Ei, Equipe de Scripts!

Perseguindo carros... e XML

A Equipe de Scripts da Microsoft Security Watch

Implantando o EFS: Parte 1

John Morello Os arquivos da área de trabalho

Estendendo o Windows PE

Wes Miller Anotações de campo

Simplesmente pára de funcionar

R'ykandar Korra'ti Segredos do Windows

Uma "mistura" abençoada

Raymond Chen


 Administra&#231;&#227;o do Windows: Dentro do kernel do Windows Vista: Parte 1
Administração do Windows Mark Russinovich

Dentro do kernel do Windows Vista: Parte 1
Visão geral:
  • Agendamento e prioridade do thread
  • Links simbólicos baseados em arquivo
  • Cancelando operações de E/S

Esta é a primeira parte de uma série sobre as novidades do kernel do Windows Vista. Nesta edição, veremos as alterações nas áreas de processos, threads e E/S. Edições posteriores tratarão de abordar temas como gerenciamento de memória, inicialização e desligamento, confiabilidade e recuperação, além de segurança.
O escopo deste artigo compreende alterações ao kernel do Windows Vista™ apenas, especificamente o Ntoskrnl.exe e os componentes estreitamente relacionados a ele. Lembre-se de que há muitas outras alterações significativas no Windows Vista que ficam de fora do kernel propriamente dito e que, portanto, não serão abordadas. Isso inclui aprimoramentos ao shell (exemplo: pesquisa de área de trabalho integrada), sistema de rede (como a nova pilha do IPv6 e o firewall bidirecional) e o modelo gráfico de última geração (como o Aero™ Glass, o Windows® Presentation Foundation, o Gerenciador de Janelas da Área de Trabalho e o novo modelo de driver gráfico). Também não são abordadas as novas UMDF e KMDF (Estruturas de Driver do Modo de Usuário do Windows e do Modo Kernel), pois elas são instaláveis em níveis anteriores de versões anteriores do Windows.

Contagem de ciclos da CPU
O Windows Vista inclui vários aprimoramentos na área de processos e threads, que incluem o uso do contador de ciclos da CPU, para obter uma alocação de CPU mais parcial, e o novo MMCSS (Multimedia Class Scheduler Service), que auxilia os aplicativos de mídia a oferecer uma reprodução sem problemas.
Todas as versões do Windows NT® até e incluindo o Windows Vista programam uma rotina de interrupção do timer do intervalo para execução a cada 10 ou 15 ms (milissegundos), aproximadamente, dependendo da plataforma de hardware. A rotina analisa em que thread ocorreu interrupção e atualiza a estatística de uso da CPU do thread como se esse thread tivesse sido executado no intervalo inteiro, quando, na realidade, o thread pode ter iniciado a execução um pouco antes do fim do intervalo. Além disso, o thread poderia ter sido atribuído pela CPU tecnicamente, mas não teve a chance de ser executado porque rotinas de interrupção de hardware e software foram executadas no lugar.
Embora a contabilização de tempo com base no clock possa servir para ferramentas de diagnostico que geram relatório de thread e processam o uso da CPU, o uso desse método pelo agendador de thread pode ocasionar uma alocação parcial de CPU. Por padrão, em versões clientes do Windows, os threads têm permissão para executar até 2 marcações do clock (6 se estiver em primeiro plano). Entretanto, o thread pode não obter quase nenhum tempo na CPU ou até 6 marcações (18 se estiver em primeiro plano), dependendo do próprio comportamento e de outras atividades no sistema.
A Figura 1 mostra a parcialidade que pode ocorrer quando dois threads com a mesma prioridade ficam prontos para execução ao mesmo tempo. O thread A é executado até o próximo vencimento de intervalo de fração de tempo, quando o agendador supõe que ele tenha ficado em execução pelo intervalo inteiro e, então, decide que o giro do thread A foi concluído. Além disso, o Thread A fica não parcialmente carregado devido à interrupção ocorrida durante o seu giro. No intervalo seguinte, o agendador seleciona o Thread B para assumir e ele é executado em um intervalo inteiro.
Figura 1 Agendamento de thread parcial
Figura 1 Agendamento de thread parcial
No Windows Vista, o agendador usa o Registro do contador de ciclos de processadores modernos para rastrear, de maneira precisa, quantos ciclos de CPU um thread pode executar. Estimando-se quantos ciclos a CPU pode executar em um intervalo de clock, ele pode distribuir de modo mais preciso os giros na CPU. Além disso, o agendador do Windows Vista não conta a execução de interrupção em relação ao giro do thread. Isso significa que, no Windows Vista, um thread obterá sempre pelo menos o próprio giro na CPU, e nunca mais de um intervalo de clock extra de execução, o que resulta em maior igualdade e mais comportamento determinístico do aplicativo. A Figura 2 mostra como o Windows Vista responde ao cenário mostrado na Figura 1, concedendo aos dois threads pelo menos um intervalo de execução.
Figura 2 Agendamento com base em ciclos do Windows Vista
Figura 2 Agendamento com base em ciclos do Windows Vista
A barra lateral "Watching Process CPU Usage" ilustra como você pode monitorar o processo de uso do ciclo da CPU para si mesmo, por meio do utilitário Process Explorer.

Multimedia Class Scheduler Service
O usuário espera que aplicativos de multimídia, incluindo players de música e de vídeo, propiciem uma experiência de reprodução contínua. Contudo, a demanda pela CPU por parte de outros aplicativos em execução simultaneamente, como antivírus, indexação de conteúdo ou mesmo o cliente de email, pode resultar em contratempos indesejáveis. Para oferecer uma experiência de reprodução melhor, o Windows Vista apresenta o MMCSS, que gerencia as prioridades da CPU de threads multimídia.
Um aplicativo de multimídia como o Windows Media® Player 11 é registrado com o MMCSS por meio de novas APIs que indicam as respectivas características de multimídia, que devem corresponder a uma das listadas por nome na seguinte chave do Registro:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Figura A Exibindo o tempo de CPU e Ciclos Delta no Process Explorer (Clique na imagem para diminuir a exibição)
Figura A Exibindo o tempo de CPU e Ciclos Delta no Process Explorer
Figura A Exibindo o tempo de CPU e Ciclos Delta no Process Explorer (Clique na imagem para aumentar a exibição)

Figura 3 Definição de tarefa de áudio do Multimedia Class Scheduler
Figura 3 Definição de tarefa de áudio do Multimedia Class Scheduler (Clique na imagem para diminuir a exibição)
Figura 3 Definição de tarefa de áudio do Multimedia Class Scheduler
Figura 3 Definição de tarefa de áudio do Multimedia Class Scheduler (Clique na imagem para aumentar a exibição)
O MMCSS, implementado em %SystemRoot%\System32\Mmcss.dll e executado em um processo de Host de serviço (Svchost.exe), tem um thread de gerenciamento de prioridade que é executado na prioridade 27. (As prioridades do thread no Windows vão de 0 a 31.) Esse thread aumenta a prioridade de threads de multimídia registrados no intervalo associado ao valor Categoria de Agendamento da respectiva chave do Registro da tarefa, conforme listado na Figura 4. No Windows, prioridades do thread 16 e superiores estão no intervalo de prioridade em tempo real e são superiores a todos os demais threads no sistema (com exceção dos threads de trabalho do Gerenciador de memória do kernel, executado nas prioridades 28 e 29). Somente contas administrativas, como a conta Sistema Local em que o MMCSS é executado, têm o privilégio Aumentar Prioridade, requerido para definir prioridades do thread em tempo real.
Figure 4 Prioridades do thread do MMCSS (Close Figure 4)

Categoria de agendamento | Prioridades aumentadas do thread
Alta | 23-26
Média | 16-23
Ao reproduzir um arquivo de áudio, o Windows Media Player registra threads da tarefa de Áudio; ao reproduzir um vídeo, ele registra threads da tarefa de Reprodução. O serviço MMCSS aumenta todos os threads que indicaram estar fornecendo um fluxo ao mesmo tempo em que são executados no processo que pertence à janela do primeiro plano e quando têm o valor BackgroundOnly definido para Verdadeiro na respectiva chave de definição da tarefa.
Mas, embora o MMCSS auxilie threads multimídia a obter o tempo de CPU que desejem, ele também deseja garantir que outros threads obtenham pelo menos algum tempo de CPU, para que o sistema e outros aplicativos permaneçam responsivos. O MMCSS, portanto, reserva um percentual de tempo de CPU para outra atividade, especificada no valor do Registro seguinte:
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
Por padrão, esse percentual é 20%; o MMCSS monitora o uso da CPU para garantir que threads multimídia não serão aumentados mais de 8 ms em um período de 10 ms caso outros threads precisem da CPU. Para que os threads multimídia fiquem fora do caminho pelos 2 ms restantes, o agendador suspende as prioridades desses threads no intervalo de 1 a 7.
Veja como o MMCSS aumenta a prioridade do thread, lendo na barra lateral "Watching MMCSS Priority Boosting".

Links simbólicos baseados em arquivo
As alterações relacionadas a E/S no Windows Vista incluem links simbólicos baseados em arquivo, processamento de conclusão de E/S mais eficiente, suporte abrangente de cancelamento de E/S e E/S priorizada.
Um recurso do sistema de arquivos que muitos consideraram ausente do NTFS, o link de arquivo simbólico (ou, como é chamado no UNIX, soft link), chega finalmente ao Windows Vista. A versão Windows 2000 do NTFS introduziu links de diretório simbólicos, chamados de junções de diretório, que permitem criar um diretório que aponta para um diretório diferente; no entanto, até a versão do Windows Vista, o NTFS só oferecia suporte a links físicos para arquivos.
Uma diferença importante no modo como o Windows resolve links simbólicos e junções de diretório é onde o processamento ocorre. O Windows processa links simbólicos no sistema local, mesmo quando eles fazem referência a um local em um servidor de arquivos remoto. O Windows processa junções de diretório que fazem referência a um servidor de arquivos remoto no próprio servidor. Links simbólicos em um servidor podem, portanto, fazer referência a locais acessíveis apenas no cliente, como outros volumes de cliente, ao passo que as junções de diretório não são capazes disso. Para lidar com isso, o Windows Vista oferece suporte ao novo tipo de link simbólico tanto para arquivos quanto para diretórios.
Muitos comandos do sistema de arquivos foram atualizados para compreender as implicações de links simbólicos. Por exemplo, o comando Excluir não sabe seguir links, o que resultaria na exclusão do destino, mas sabe excluir o link, por outro lado. Contudo, como nem todos os aplicativos podem manipular links simbólicos corretamente, criar um link simbólico requer o novo privilégio Criar Link Simbólico, que, por padrão, só os administradores têm.
Você pode criar um link simbólico em um prompt de comando, usando o comando Mklink. O comando de diretório interno do prompt de comando identifica um link simbólico sinalizando-o com <SYMLINK> e mostrando o destino entre colchetes, como mostra a Figura 5. O Windows Explorer também reconhece links simbólicos e os mostra por meio da seta de atalho. Você pode ver o destino de um link no Explorer adicionando a coluna Destino do Link à janela de navegação.Watching MMCSS Priority Boosting
Você pode observar o aumento de thread que o serviço MMCSS aplica aos threads do Windows Media Player, reproduzindo um clipe de vídeo ou de áudio, executando o Monitor de Desempenho, configurando a escala de gráfico para 31 (a prioridade do thread mais alta do Windows) e adicionando o contador Prioridade atual de todas as instâncias dos objetos de thread do Media Player (Wmplayer.exe) à exibição. Um ou mais threads serão executados na prioridade 21.
Figura B Aumento de prioridade do thread do Windows Media Player
Figura B Aumento de prioridade do thread do Windows Media Player (Clique na imagem para diminuir a exibição)
Figura B Aumento de prioridade do thread do Windows Media Player
Figura B Aumento de prioridade do thread do Windows Media Player (Clique na imagem para aumentar a exibição)

Figura 5 Usando o Mklink para criar um link simbólico
Figura 5 Usando o Mklink para criar um link simbólico (Clique na imagem para diminuir a exibição)
Figura 5 Usando o Mklink para criar um link simbólico
Figura 5 Usando o Mklink para criar um link simbólico (Clique na imagem para aumentar a exibição)

Conclusão e cancelamento de E/S
Existem várias alterações de escopo ao sistema de E/S que podem melhorar o desempenho de aplicativos de servidor. Esses aplicativos geralmente usam um objeto de sincronização chamado porta de conclusão, para aguardar a conclusão de solicitações de E/S assíncronas. Antes do Windows Vista, quando essa E/S era concluída, o thread que emitiu a E/S executaria o trabalho de conclusão de E/S, ocasionando uma alternância no processo a que pertence o thread e interrompendo tudo o mais que estivesse acontecendo. O sistema de E/S, então, atualizaria o status da porta de conclusão para despertar um thread que estivesse à espera da alteração desse status.
No Windows Vista, o processo de conclusão de E/S é executado não necessariamente pelo thread que emitiu a E/S, mas pelo que está à espera da porta de conclusão para despertar. Essa alteração relativamente pequena evita o agendamento desnecessário do thread e de alternâncias de contexto que podem degradar o desempenho geral do aplicativo e do sistema. Para melhorar ainda mais o desempenho, um servidor pode recuperar os resultados de várias operações de E/S de uma conclusão em uma solicitação, evitando transações no modo kernel.
Provavelmente, a alteração mais visível no sistema de E/S da perspectiva de um usuário final é o suporte do Windows Vista para cancelamento de operações de E/S assíncronas. Se você já executou um comando net view ou tentou acessar um compartilhamento em um sistema remoto offline no Windows XP ou no Windows Server® 2003, já teve problemas com operações de I/O que não pudessem ser canceladas: o comando ou navegador de arquivos não responde até que o tempo limite da rede expire. O aplicativo não tem escolha, a não ser aguardar até a falha da operação, porque não há para ele um modo de informar ao driver de dispositivo que está executando a E/S que ele não se importa mais com a E/S.
No Windows Vista a maioria das operações de E/S podem ser canceladas, incluindo a operação open file I/O que o Net View e o Explorer utilizam. No entanto, aplicativos têm que ser atualizados para responder a solicitações do usuário final quanto ao cancelamento da E/S, e vários utilitários do Windows Vista que interagem com dispositivos que têm tempo limite contam com o suporte necessário. As caixas de diálogo abrir arquivo e salvar, usadas por quase todo aplicativo do Windows, incluindo aplicativos de terceiros, por exemplo, agora habilitam o botão Cancelar enquanto tentam exibir o conteúdo de uma pasta. O comando Net também cancela a respectiva E/S síncrona quando Ctrl+C é pressionado.
Você pode conferir os benefícios do cancelamento de E/S abrindo um prompt de comando no Windows Vista e digitando:
net view (\\nonexistentmachine)
O comando hesitará enquanto o Windows tenta contatar o sistema não existente, mas você pode digitar Ctrl+C para encerrá-lo. No Windows XP, digitar Ctrl+C não tem nenhum efeito e o comando não retorna até que a operação de rede atinja o tempo limite.
Outro tipo de E/S que causou problemas ao usuário em versões passadas do Windows são as E/Ss que drivers de dispositivos não cancelavam corretamente, porque não havia nenhum modo fácil de os drivers saberem que deveriam fazê-lo. Se você já encerrou um processo, e, em seguida, viu-o demorando-se em ferramentas de exibição do processo, então você testemunhou um driver de dispositivo falhando em responder a um encerramento de processo e cancelando a E/S emitida pelo processo que não havia sido concluído. O Windows não é capaz de executar a limpeza de processo final até que a E/S do processo termine ou seja cancelada. No Windows Vista, drivers de dispositivo registram-se facilmente para a notificação de finalizações do processo; assim, chega ao fim a maioria dos problemas dos processos sem solução.

Prioridade de E/S
Embora o Windows sempre tenha dado suporte à priorização de uso da CPU, esse recurso não foi incluído no conceito de prioridade de E/S. Sem a prioridade de E/S, atividades de segundo plano como indexação de pesquisa, verificação de vírus e desfragmentação de disco podem causar impactos graves à agilidade de respostas de operações de primeiro plano. Um usuário que abra um aplicativo ou um documento enquanto outro processo executa E/S de disco, por exemplo, experimentará atrasos, pois a tarefa de primeiro plano aguarda o acesso ao disco. A mesma interferência também afeta a reprodução do fluxo contínuo de conteúdo multimídia, como música, em um disco rígido.
O Windows Vista introduz dois tipos de priorização de E/S para ajudar a fazer com que as operações de E/S em primeiro plano tenham a preferência: prioridade em operações de E/S individuais e reservas combinadas de largura de banda de E/S. O sistema de E/S do Windows Vista inclui suporte interno para cinco prioridades de E/S, como mostra a Figura 6, mas apenas 4 prioridades são usadas (versões futuras do Windows poderão oferecer suporte à prioridade Alta).
Figure 6 Prioridades de E/S do Windows Vista (Close Figure 6)

Prioridade de E/S | Uso
Crítico | Gerenciador de memória
Alta | Não usado
Normal | Prioridade padrão
Baixa | Prioridade de tarefa padrão
Muito baixa | Atividade de segundo plano
A E/S tem uma prioridade padrão Média e o Gerenciador de Memória utiliza a Crítica, quando quer gravar os dados “sujos” de memória fora do disco em situações de memória baixa, a título de liberar espaço na RAM para outros dados e códigos. O Agendador de Tarefas do Windows define a prioridade de E/S para Baixa nas tarefas que têm a prioridade de tarefa padrão; já a prioridade especificada por aplicativos gravados do Windows Vista que executam o processamento do segundo plano é Muito Baixa. Todas as operações de segundo plano do Windows Vista, incluindo verificação do Windows Defender e indexação de pesquisa de área de trabalho, utilizam prioridade de E/S Muito Baixa.Analisando a prioridade muito baixa de E/S
O Process Monitor, um sistema de arquivos em tempo real e utilitário de monitoramento do Registro, da Sysinternals, coleta informações detalhadas para operações de gravação e leitura do sistema de arquivos, incluindo as respectivas prioridades de E/S no Windows Vista. A linha realçada mostra o exemplo de uma E/S de prioridade muito baixa, emitida pelo SuperFetch (que discutirei em minha próxima edição).
Figura C Exibindo a prioridade muito baixa de E/S no Process Monitor
Figura C Exibindo a prioridade muito baixa de E/S no Process Monitor (Clique na imagem para diminuir a exibição)
Figura C Exibindo a prioridade muito baixa de E/S no Process Monitor
Figura C Exibindo a prioridade muito baixa de E/S no Process Monitor (Clique na imagem para aumentar a exibição)

O driver de dispositivo de classe de armazenamento do sistema (%SystemRoot%\System32\Classpnp.sys) impõe as prioridades de E/S e elas são aplicadas automaticamente à E/S direcionada à maioria dos dispositivos de armazenamento. A classe e os demais drivers de armazenamento inserem E/Ss Médias à frente das Baixas e Muito Baixas nas respectivas filas, mas emitem pelo menos uma E/S Baixa ou Muito Baixa em espera a cada segundo, para que processos em segundo plano possam avançar. Dados lidos por E/S Muito Baixa também fazem com que o Gerenciador de Cache grave modificações imediatamente no disco, em vez de fazê-lo posteriormente, e desvie a respectiva lógica read-ahead para operações de leitura que, do contrário, lêem preemptivamente do arquivo que está sendo acessado. Dê uma olhada na barra lateral "Seeing Very Low I/O Priority" para ter um exemplo de prioridade de E/S Muito Baixa usando o utilitário Process Monitor.
O suporte da reserva de largura de banda do Windows Vista é útil para aplicativos Media Player, e o Windows Media o utiliza, juntamente com aumentos de prioridade, para propiciar reprodução de conteúdo local praticamente sem falhas. Um aplicativo Media Player solicita ao sistema de E/S para lhe garantir a capacidade de ler dados a uma taxa especificada e, se o dispositivo puder fornecer os dados na taxa solicitada e as reservas existentes o permitirem, ele fornecerá ao aplicativo orientação sobre a velocidade em que ele deverá emitir E/Ss e o tamanho dessas E/Ss. O sistema de E/S não prestará serviço a demais E/Ss, a menos que possa atender aos requisitos de aplicativos que fizeram reserva no dispositivo de armazenamento de destino.
Uma alteração final do sistema de E/S que vale a pena mencionar relaciona-se ao tamanho das operações de E/S. Desde a primeira versão do Windows NT, o Gerenciador de Memória e o sistema de E/S limitaram a 64KB o volume de dados processados por uma solicitação de E/S de armazenamento individual. Portanto, ainda que um aplicativo emita uma solicitação de E/S muito maior, ela será desmembrada em solicitações individuais com um tamanho máximo de 64KB. Cada E/S gera uma sobrecarga em transições para o modo kernel e ao iniciar uma transferência de E/S no dispositivo de armazenamento; assim, os tamanhos de solicitações de E/S de armazenamento do Windows Vista storage não são mais completados. Vários componentes do modo de usuário do Windows Vista foram modificados para aproveitar o suporte a E/Ss maiores, incluindo a funcionalidade de cópia do Explorer e o comando Copiar do prompt de comando, que agora emite E/Ss de 1 MB.

A seguir
Você acabou de ver duas áreas nas quais o kernel do Windows Vista foi aprimorado. Você pode esperar informações adicionais detalhadas na próxima edição do meu livro, Windows Internals (em co-autoria com David Solomon), cuja edição está prevista para ocorrer simultaneamente à próxima versão do Windows Server, com o codinome “Longhorn." Em minha próxima edição, continuarei apresentando o novo kernel, discutindo gerenciamento de memória, juntamente com inicialização e desligamento do sistema.

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 de TI e conferências de desenvolvedores. Russinovich uniu-se à Microsoft com a recente aquisição da empresa de que foi co-fundador, a Winternals Software. Ele criou também a Sysinternals, onde publicou os utilitários 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..


 Administra&#231;&#227;o do Windows: Delegando autoridade no Active Directory
Administração do Windows Joel Yoker and Rob Campbell

Delegando autoridade no Active Directory
Visão geral:
  • Definindo funções administrativas
  • Desenvolvendo uma UO e um modelo de grupo de segurança
  • Usando contas secundárias
  • Ferramentas de delegação de direitos

Os recursos de delegação do Active Directory são muito eficientes e abordam uma série de problemas relacionados à segurança, além de simplificar tarefas de gerenciamento. Quando a delegação de direitos no Active
Directory® é feita corretamente, você pode aplicar funções especificadas ao ambiente, limitar o impacto e a probabilidade de erro administrativo e aplicar o princípio de privilégio mínimo ao longo de toda a sua infra-estrutura. Mesmo assim, muitas das organizações que contam com o Active Directory ainda precisam explorar mais o poder da delegação. Isso ocorre em parte porque, na superfície, o desenvolvimento de um modelo de delegação do Active Directory para o seu negócio parece ser bastante complexo. Embora o maior obstáculo seja desenvolver um modelo de delegação que se adapte às necessidades exclusivas de sua organização, a verdade é que existem modelos muito simples que podem ser aplicados à maioria das infra-estruturas de TI com pouca modificação.
Apesar de todo ambiente ser diferente de algum modo, formato ou forma, a realidade é que a maior parte das grandes empresas se assemelha de várias maneiras e enfrenta os mesmos desafios de TI. Por exemplo, várias organizações estão divididas em regiões geográficas, evoluíram de equipes distintas de engenharia de TI ou suporte operacional e possuem unidades comerciais independentes. E muitas organizações de grande porte devem lidar com assuntos como escalonamento de privilégios, abuso de conta de serviço e "confiança".
Confiança é um termo interessante e geralmente se torna a justificativa para ter várias florestas do Active Directory. Problemas relacionados à confiança geralmente se originam da capacidade de uma divisão ou região para afetar a disponibilidade de sistema de outra divisão ou região. É comum que os níveis de habilidade sejam diferentes em limites organizacionais, daí uma falta de conhecimento aprofundado sobre sistemas específicos requerido para dar suporte a uma região ou unidade comercial específica. Portanto, as divisões geralmente não querem renunciar a seus direitos administrativos e transferi-los a um grupo central.
Enquanto isso, em qualquer implementação do Active Directory, os administradores devem definir as regras de envolvimento para aplicativos que utilizam a infra-estrutura do Active Directory. Infelizmente, uma abordagem comum – mencionada geralmente em guias de instalação de aplicativos – é tornar a conta de serviço um membro do grupo Admins. do Domínio. O problema com essa abordagem é que contas de serviço são, essencialmente, contas genéricas. Concedendo esses direitos de Admins. do Domínio, você oferece uma ameaça significativa ao ambiente de TI. As contas de serviço podem ser vítimas do uso incorreto facilmente, por administradores maliciosos ou descuidados, ou ser aproveitadas por invasores que se valem problemas de segurança de base em um aplicativo.
Embora esses obstáculos possam parecer intransponíveis, eles representam um cenário principal para implementação do modelo de delegação do Active Directory. Desenvolver esse modelo de delegação é um processo de design interativo e sugerimos que você siga estas etapas:
  1. Defina as funções administrativas de TI em sua organização.
  2. Desenvolva uma unidade organizacional e um modelo de grupo de segurança.
  3. Estabeleça contas secundárias para administradores de TI.
  4. Delegue direitos.
Vamos examinar essas etapas mais de perto.

Definir funções
O processo de definição de função tem início com um entendimento meticuloso de administração de serviços e administração de dados. Esses conceitos são o fundamento de qualquer modelo de delegação do Active Directory.
Fundamentalmente, a administração de serviços é o gerenciamento de componentes críticos da infra-estrutura de serviço de diretório, como servidores Exchange e controladores de domínio. Administração de dados é o gerenciamento de objetos, como caixas de correio e contas de usuário, que residem nesses serviços. Dentro do escopo do Active Directory, os administradores de serviço são, em última análise, responsáveis pelo fornecimento e pela disponibilidade de serviços de diretório, enquanto os administradores de dados gerenciam contas de usuário e de servidor, grupos e outros recursos do domínio.
O Active Directory oferece suporte à delegação granular de autoridade por meio de UOs (unidades organizacionais). As UOs freqüentemente podem ser adaptadas para oferecer o mesmo nível de autoridade disponível para administradores nos modelos de serviço de diretório ou de domínio existentes. No entanto, é importante entender que algumas funções simplesmente não podem ser delegadas e devem ser gerenciadas por um grupo ou uma entidade único e confiável.
A análise de tarefas também é fundamental. Você precisa saber quais tarefas do Active Directory são realizadas por administradores e como essas tarefas são mapeadas a funções. Por exemplo, a criação do site do Active Directory é uma tarefa de administração de serviços, ao passo que a modificação de associação de grupo de segurança geralmente recai sob a administração de dados. Cada tarefa deve ser avaliada por freqüência, importância e dificuldade. Esses aspectos são vitais à definição de tarefas, porque definem se um direito deve ser delegado. As tarefas são executadas rotineiramente, têm risco limitado e são de execução trivial, além de serem excelentes candidatas à delegação. Por outro lado, tarefas que são executadas raramente têm um grande impacto na organização e requerem níveis altos de habilidade, além de serem candidatas fracas à delegação. Em vez disso, o escalonamento (que eleva temporariamente uma conta à função requerida ou reatribui a tarefa) é o caminho apropriado para essas tarefas.
Como muitas características de grandes organizações se assemelham, é seguro supor que um modelo de delegação comum possa ser implementado. Para os fins deste artigo, forneceremos um conjunto de amostras de funções que permitem recursos de gerenciamento, respeitando, ao mesmo tempo, limites organizacionais e tentando minimizar problemas relacionados à confiança (exemplo: a disponibilidade de ativos de toda a empresa, como controladores de domínio). Observe que este modelo é apenas um exemplo: trata-se de um ótimo início de discussão sobre funções em sua organização; no entanto, você não deverá planejar usar essa orientação textual.
Algumas funções já são definidas pelo Active Directory e outras precisam ser criadas do zero para refinar o modelo de delegação. Um conjunto de funções de exemplo que se adaptaria a muitos ambientes de grande porte do Active Directory poderia incluir Administração de Empresa, Admins. do Domínio e Administração de Nível 4 para administração de serviços, Administração de Nível 3, Administradores Regionais, Administração de Nível 2 e Administração de Nível 1 para administração de dados. Consulte a Figura 1 para obter uma lista dessas funções e responsabilidades respectivas.
Figure 1 Definir funções e responsabilidades (Close Figure 1)

Administradores de serviço | Descrição
Administração de Empresa | Responsáveis pela administração de serviços de nível superior na empresa. Não deve conter nenhum membro permanente.
Admins. do Domínio | Responsáveis pela administração de serviços de nível superior no domínio. Deve conter apenas um número pequeno e gerenciável de administradores confiáveis.
Administração de Nível 4 | Responsáveis pela administração de serviços no domínio. Recebe apenas os direitos necessários para gerenciamento de serviços necessários. Funciona como um ponto de escalonamento para administradores de dados.
Administradores de dados | Descrição
Administração de Nível 1 | Responsáveis pelo gerenciamento geral de objetos de diretório, executando tarefas como redefinições de senha, modificando propriedades de conta de usuário etc.
Administração de Nível 2 | Responsáveis pela criação e/ou exclusão seletiva de contas de usuário e de computador na localidade ou organização respectiva.
Administradores Regionais | Responsáveis pelo gerenciamento de estrutura da UO local respectiva. Recebe permissões para criar a maioria dos objetos dentro da UO respectiva.
Administração de Nível 3 | Responsáveis pelo gerenciamento de todos os administradores de dados. Funciona como um suporte técnico e ponto de escalonamento de todos os administradores regionais.

Administradores de serviço
Vamos examinar mais de perto as funções do administrador de serviço. Os administradores de serviços gerenciam componentes críticos da infra-estrutura e todos os administradores incluídos nesta categoria são altamente privilegiados. Portanto, uma estratégia de privilégio mínimo, ou seja, só conceder o conjunto mínimo de permissões necessárias para a realização de tarefas requeridas, é altamente recomendada neste caso.
Os Administradores de Domínio e de Empresa do Active Directory definem dois grupos de administradores especiais cujo contexto de segurança é requerido para funções essenciais dentro do diretório. Esses Administradores dos grupos de Domínio e de Empresa são responsáveis pela administração de serviços de nível superior. Para minimizar os riscos inerentes a esses grupos altamente privilegiados, aconselhamos enfaticamente a restrição de associação para esses grupos. Na verdade, o grupo Administração de Empresa não deve possuir membros permanentes e os grupos de Admins. do Domínio devem conter apenas um número pequeno e gerenciável de indivíduos de confiança que trabalhem para a organização em tempo integral.
Quando tarefas de administração de empresa, como autorização de servidor DHCP ou criação de site do Active Directory precisam ser realizadas, a Admins. do Domínio no domínio raiz de floresta do Active Directory pode escalonar privilégios gerenciando a associação do grupo Administração de Empresa. Esses privilégios só devem ser concedidos por períodos curtos, a título de evitar a criação de membros permanentes no grupo Administração de Empresa. Naturalmente, todos os membros de um grupo Admins. de Domínio em uma determinada floresta do Active Directory devem ser igualmente confiáveis.
Uma armadilha comum que ocorre com a maioria das organizações ao desenvolver um modelo de delegação é desabilitar ou enfraquecer essas funções internas. A modificação dessas tarefas padrão pode causar resultados imprevisíveis e não há nenhuma garantia de que revisões de service pack ou atualizações de produto mantenham essas configurações. Além disso, esse tipo de modificação cria um ambiente sem suporte fora da organização. Uma abordagem prática é usar os grupos e as funções internas, limitando, porém, a associação. Para isso, você provavelmente terá que criar novas funções para administradores que anteriormente contavam com associação em grupos como Admins. do Domínio.
Administração de Nível 4 A Administração de Nível 4 deve consistir em administradores de serviços centralizados, que oferecem suporte a todos os serviços empresariais. Como essa é uma função criada, as permissões de acesso ao sistema e ao serviço de diretório podem ser adaptadas aos requisitos específicos da organização. Embora membros desse grupo sejam administradores de serviço, eles também podem executar tarefas ocasionais de gerenciamento de dados em toda a floresta. Como existem várias classes de sistemas e áreas de responsabilidade distintas, as funções de nível 4 são desmembradas em vários subgrupos dentro do diretório. Por exemplo, devem ser criados grupos separados de nível 4 para oferecer gerenciamento distinto de sistemas específicos, como servidores Exchange. Esse grupo também funciona como um ponto de escalonamento para administradores de dados.
Um motivo por que as pessoas freqüentemente desejam receber a associação no grupo Admins. do Domínio é ganhar direitos administrativos sobre todo sistema em um determinado domínio. O truque para fazer com que esses administradores de serviços sejam executados no modo de privilégio mínimo é conceder à Administração de Nível 4 o controle de servidores corporativos, sem torná-los Admins. do Domínio. Para evitar o escalonamento de privilégio, a Administração de Nível 4 não deve receber a associação no grupo BUILTIN\Administrators em controladores de domínio, porque esse grupo tem muitos direitos subjacentes no serviço de diretório que não podem ser separados. Por exemplo, um membro do grupo BUILTIN\Administrators de um determinado domínio pode gerenciar a associação do grupo Admins. do Domínio, permitindo aos membros escalonar privilégios sem nenhuma verificação nem balanço.
Lembrando nossa regra de não enfraquecer permissões padrão, esse risco pode ser minimizado, tornando os grupos do nível 4 membros aninhados dos grupos de operadores do servidor e administradores de DNS de domínio interno. Isso permite o gerenciamento local de controladores de domínio, limitando, ao mesmo tempo, a habilidade da Administração de Nível 4 para escalonar privilégios. Para a maioria dos sistemas (além dos controladores de domínio, servidores de certificados e assim por diante), você deve tornar o grupo Administração de Nível 4 um membro do grupo Administradores local. A automação de uma associação de grupo local aninhado pode ser obtida com a funcionalidade Grupos Restritos em Diretiva de Grupo.

Administradores de dados
Agora vamos nos aprofundar nas funções de administração de dados. Essas funções devem ser criadas com direitos cumulativos, ou seja, uma Administração de Nível 2 deve ter todos os direitos de uma Administração de Nível 1, juntamente com alguns privilégios adicionais e assim por diante. Por essa razão, veremos esses grupos de baixo para cima.
Administração de Nível 1 O grupo Administração de Nível 1 deve oferecer gerenciamento geral de objetos de diretório criados previamente. Esse grupo destina-se ao administrador com um mínimo de treinamento ou ao administrador que executa tarefas isoladas, como redefinição de senha. Conceder direitos a esse grupo, dentro da respectiva unidade organizacional, para modificar propriedades de conta de usuário, redefinir senhas de contas de usuários, desbloquear contas, habilitar/desabilitar contas de usuários, adicionar e redefinir contas de computador de estação de trabalho e modificar associação de objeto de grupo para grupos não administrativos.
Administração de Nível 2: este grupo deve habilitar o gerenciamento e a criação seletivos de objetos, permitindo que eles sejam criados apenas quando puderem ser gerenciados pela Administração de Nível 1. (Por exemplo, grupos de segurança só podem ser criados em UO de Grupos). A Administração de Nível 2 pode adicionar e modificar contas da Administração de Nível 1, adicionar, modificar e excluir contas de usuários de uma UO, excluir objetos de computador de estação de trabalho e adicionar, modificar e excluir objetos Servidor, Contato e Pasta compartilhada.
Administradores Regionais Este grupo recebe direitos exclusivos sobre a respectiva estrutura de UO regional. No entanto, o grupo não é capaz de gerenciar outras estruturas de UOs regionais dentro do diretório. As contas de Administradores Regionais devem ser consideradas altamente privilegiadas e, como conseqüência, as contas são armazenadas em uma hierarquia de UO separada e gerenciadas pelos administradores de serviço da Administração de Nível 4. Os Administradores Regionais pode criar a maior parte dos objetos sem restrições dentro da respectiva estrutura de UO (uma exceção notável é a criação de outras UOs), o que traz o risco adicional de criar objetos que podem não ser gerenciáveis por níveis inferiores.
Administração de Nível 3: muitas organizações têm um suporte técnico de nível superior ou centralizado. Essa função completa a lista de administradores de dados, oferecendo um grupo de administradores de dados em todos os Administradores Regionais. Não são delegados direitos a esses grupos especificamente dentro do diretório; em vez disso, eles são feitos por associação aninhada em cada grupo Administradores Regionais. Isso oferece um ponto de escalonamento de nível superior para todos os administradores de dados, bem como um ponto de entrada de problemas a serem escalonados aos grupos de administração de serviços.

Desenvolver uma UO e um modelo de grupo de segurança
Depois que as funções estiverem definidas na organização, devem ser definidos uma UO e um modelo de grupo de segurança. Existem dois motivos principais para se criar uma UO no Active Directory: delegação de direitos e criação de um ponto onde Objetos de Diretiva de Grupo podem ser vinculados. As UOs definem um SOM (escopo de gerenciamento) dentro do diretório, e isso pode ser usado para restringir direitos a objetos em vários níveis. Como resultado, a forma como você escolhe delegar a autoridade deve ser o fator principal de como você implementa a sua estrutura de UO.
Com isso em mente, uma UO de nível superior (ou uma série delas) deve ser criada abaixo do domínio para abrigar todos os objetos. Essa UO atende à finalidade específica de definir o SOM de nível mais alto para a Administração de Nível 4. Criando uma UO de nível superior, os direitos sobre o serviço de diretório podem iniciar explicitamente no nível da UO, em vez de iniciar no nível do domínio. A delegação a partir de uma UO de nível superior, em vez de a partir do domínio, minimiza o risco de o usuário ter a possibilidade de escalonar privilégios através da manipulação de grupos de domínio internos já mencionados anteriormente.
Abaixo das Uos de nível superior você deve criar hierarquias de sub-UO para representar cada região ou unidade de negócios que tenha uma equipe de gerenciamento de dados distinta. Cada sub-UO regional deve ter uma hierarquia de UO comum e não extensível para gerenciamento de objetos de diretório. A uniformidade é essencial ao gerenciamento contínuo, uma vez que grande parte dos direitos de delegação será automatizada. Trata-se de um pedido exigente, porque cada região pode desejar UOs exclusivas. Administradores de TI, entretanto, devem usar suas próprias armas e, se for necessária uma extensão para uma região, a estrutura da sub-UO deverá ser estendida a todas as regiões. Isso pode parecer difícil no início, mas se a organização oferecer abrigo genérico para objetos, situações remotas tendem a se ajustar com o tempo.
Finalmente, crie grupos de subadministradores e contas para remover a capacidade dos administradores de escalonar os respectivos privilégios a grupos Administração de Nível 1, Administração de Nível 2 e Administradores Regionais a cada hierarquia de sub-UO. Colocar essas contas em UOs separadas permite a restrição de gerenciamento nos respectivos níveis ou abaixo deles. Portanto, se todas as contas de Administração de Nível 1 e o grupo de segurança associado residirem em uma UO em que não tenham direitos, os administradores não poderão seqüestrar outras contas de administradores nem escalonar os privilégios de outros administradores a seus níveis. Qualquer membro do grupo Admins. do Domínio, por exemplo, pode tornar qualquer outra conta de usuário no domínio um Admin. do Domínio. No entanto, com esse modelo de UO em vigor, esse risco é minimizado. Um exemplo de estrutura de UO com grupos de segurança associados é mostrado na Figura 2.
Figura 2 Estrutura de UO e grupos de segurança associados
Figura 2 Estrutura de UO e grupos de segurança associados

Estabelecer contas secundárias
A chave para um modelo de delegação bem-sucedido é aplicar o princípio do privilégio mínimo. Na prática, isso significa que uma entidade de segurança deve ter apenas a capacidade de executar as tarefas requeridas para a sua função determinada e nada mais. Infelizmente, muitos administradores de TI usam a mesma entidade de segurança para administração de diretório e tarefas diárias, como navegação na Web e leitura de email. Manter contas separadas diminui a probabilidade de um administrador em camadas danificar o serviço de diretório por engano ou ser vítima de um ataque que ocorre por meio de aplicativos diários, mas que se destina ao administrador de diretórios.
Para realizar isso sem requerer que o usuário faça logoff e volte a fazer logon, use o serviço Logon secundário (Runas.exe). Isso permite ao usuário elevar os próprios privilégios, fornecendo um conjunto alternativo de credenciais ao executar scripts ou executáveis em servidores e estação de trabalho.
Embora o conceito de uso de contas com privilégios mínimos seja relativamente simples, as organizações às vezes consideram difícil a sua aplicação, pois antigos hábitos de TI podem ser difíceis de modificar. Uma abordagem objetiva para se evitar o uso de contas privilegiadas em tarefas diárias é não oferecer acesso a email a essas contas no Exchange Server, aplicando essa restrição por meio de diretiva administrativa na organização. Essa abordagem relativamente simples reduz em muito a probabilidade de que tais contas sejam usadas em tarefas rotineiras e não administrativas.

Delegar direitos
A etapa final do desenvolvimento de um modelo de delegação é a delegação efetiva de direitos dentro do Active Directory. Isso exige a manipulação de ACEs (entradas de controle de acesso) e ACLs (listas de controle de acesso) em dados armazenados no diretório. As ACLs em contêineres do Active Directory definem os objetos que podem ser criados e o modo como esses objetos são gerenciados. A delegação de direitos envolve operações básicas em objetos, como a capacidade de exibir um objeto, criar um objeto filho de uma classe especificada ou ler informações de atributo e segurança em objetos de uma classe determinada. Além dessas operações básicas, o Active Directory define direitos estendidos, o que permite operações como Send as e Manage Replication Topology.
Nas etapas anteriores, discutimos a criação de grupos de segurança que são mapeados para funções organizacionais definidas. Isso significa que para toda função existe um grupo de segurança associado por estrutura de sub-UO. Para implementar o modelo de delegação, esses grupos precisam receber permissões sobre os objetos no diretório. Nesse ponto do processo, reinventar a roda e criar um ambiente altamente personalizado não é o que se deseja. Em vez disso, tente aproveitar grupos e direitos internos quando possível. Digamos que uma função específica precise gerenciar registros DNS da floresta. Não tente delegar direitos sobre os contêineres e contextos de nomeação relacionados ao DNS integrado ao Active Directory; no lugar disso, basta utilizar o grupo BUILTIN\DNS Admins no domínio. Além disso, direitos do usuário e outras permissões podem ser estendidos por meio de Diretiva de grupo, para fornecer os direitos adicionais requeridos ao gerenciamento de uma classe específica de sistema por uma determinada função.
Quando acessar permissões usando delegação, limite ou até elimine completamente o uso de Deny ACEs no diretório. Essas ACEs podem ser confusas quando se trata de solucionar problemas. Uma abordagem melhor é fazer uso de Allow ACEs explícitas, para conceder direitos aos grupos personalizados que representam suas funções. Lembre-se de que funções definidas pelo usuário, como Administração de Nível 4, só terão os direitos explícitos definidos por essa função.
A herança é essencial à segurança do Active Directory e define o modo pelo qual uma ACL específica se aplica a objetos filho em um dado contêiner ou subcontêiner. Seja sempre específico sobre o escopo de herança, garantindo que ACEs herdáveis sejam aplicadas a objetos de destino o mais próximo possível. As permissões de negação herdáveis aplicadas ao objeto pai terão precedência sobre qualquer permissão de negação aplicada ao objeto avô, o que constitui um dos principais motivos por que Deny ACEs não são recomendadas na delegação prática. Além disso, permissões herdáveis não podem substituir uma ACE explícita em um objeto. Por essa razão, recomenda-se que você limite ou elimine a capacidade de administradores em camadas para modificar a lista de controle de acesso discricionária (removendo o privilégio de gravação DACL) em objetos de diretório. (Observe que o criador do objeto tem esses direitos implicitamente). A regra geral é que, se um administrador tem a capacidade de alterar a DACL em um objeto, ele provavelmente o fará. Não permita que o trabalho árduo que a sua organização colocou em seu modelo de delegação vá para o lixo, introduzindo a opção e o erro administrativo potencial.
Existem várias ferramentas que você precisará usar para implementar corretamente um modelo de delegação do Active Directory. Para a maior parte das grandes organizações, o uso do Assistente de Delegação para atribuição de permissões no diretório é uma tarefa intimidadora comum, com possibilidade de erro administrativo. Em vez disso, deve-se sempre usar a automação, para garantir que o modelo de delegação fique bem documentado, que tenha suporte e forneça uma opção de recuperação, caso as configurações sejam de alguma forma perdidas ou alteradas acidentalmente.
A principal ferramenta requerida para implementação de delegação é o DSACLS.EXE, uma ferramenta de linha de comando usada para manipular ACLs de serviço de diretório em objetos. Essa ferramenta também permite que os sinalizadores de herança em uma DACL sejam especificados no objeto pai. (Os sinalizadores de herança incluem esse objeto e subobjetos e apenas subobjetos, e propagam permissões herdáveis em apenas um nível). Ocorrerá falha dos comandos DSACLS, no final das contas, se um sinalizador de herança for configurado incorretamente; portanto, é crucial fazer um teste ao usar essa ferramenta. Eis um exemplo da sintaxe DSACLS para delegar a capacidade de criar objetos de computador na UO de demonstração de destino:
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
O DSACLS faz distinção entre maiúsculas e minúsculas em relação a tipos de objeto. Isso significa que tentar delegar permissões para a classe de objeto "cn=Computer" sobre a "cn=computer" não irá funcionar (consulte a Figura 3).
Figura 3 Erro devido à diferenciação entre maiúsculas e minúsculas
Figura 3 Erro devido à diferenciação entre maiúsculas e minúsculas (Clique na imagem para diminuir a exibição)
Figura 3 Erro devido à diferenciação entre maiúsculas e minúsculas
Figura 3 Erro devido à diferenciação entre maiúsculas e minúsculas (Clique na imagem para aumentar a exibição)
Um conjunto específico de direitos é necessário para criação de alguns objetos. Isso se relaciona a atributos "must contain" ("deve conter") e "may contain" ("pode conter") em objetos. A melhor metáfora que eu já ouvi para explicar esse conceito é o modelo de hambúrguer. O hambúrguer deve conter carne e pão de hambúrguer para ser considerado um hambúrguer. São esses os atributos must-contain da classe de objeto hambúrguer. Itens como conservas, molho de tomates, alface etc são atributos may-contain. Se estendermos a classe de objeto para definir um cheeseburguer, adicionaremos queijo à lista de atributos must-contain.
Objetos do usuário funcionam da mesma forma. Digamos que precisássemos seguir este modelo para criar objetos do usuário, utilizando a seguinte sintaxe DSACLS:
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
O administrador se depararia com vários erros durante a criação do objeto do usuário. Precisamos conceder os privilégios necessários para definir atributos requeridos no objeto do usuário, incluindo a definição da senha. Isso é descrito na sintaxe DSACLS adicional seguinte:
Na primeira etapa, conceda o privilégio para gravar atributos must-contain, concedendo leitura genérica/gravação genérica a todos os atributos da classe de usuário.
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
Na etapa seguinte, conceda o direito estendido para alterar a senha:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
Na etapa final, conceda os privilégios Propriedade de Leitura e Propriedade de Gravação ao atributo Password Last Set (Última Definição de Senha).
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
Depois de delegados os direitos adequados, as funções definidas serão limitadas apenas ao gerenciamento de classes de objeto definidas na DACL do contêiner. Usando o exemplo do objeto de computador anterior, o menu de contexto em Usuários e Computadores do Active Directory restringe a lista de novos objetos que podem ser criados pelo usuário a quem esses direitos foram delegados (consulte a lista na Figura 4).
Figura 4 Lista restrita de novos objetos
Figura 4 Lista restrita de novos objetos
Os DSACLS também podem ser automatizados para oferecer uma implantação complexa de direitos. Aqui estão alguns dos comandos DSACLS que podem ser usados para delegar direitos com o fim de manipular atributos de endereços comuns sobre objetos do usuário em um determinado contêiner.
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
Exemplos como esses são comuns para a maioria dos modelos de delegação e podem ser usados juntamente com as funções definidas previamente.
Outra ferramenta usada para implementar a delegação é o DSREVOKE.EXE, que permite aos administradores localizar e remover direitos delegados de entidades de segurança específicas dentro do diretório. Embora essa ferramenta seja bastante útil, ela é específica de uma entidade de segurança e não avalia a associação aninhada dentro de grupos de segurança.
Para além dessas ferramentas de linha de comando, também recomendamos enfaticamente o uso de Atribuição de Direitos de Usuário e Grupos Restritos com Diretiva de Grupo. Como discutido anteriormente, a Atribuição de direitos de usuário permite aos administradores de TI estender ou remover direitos de nível inferior (como o direito de acessar e reiniciar um sistema remotamente) para vários grupos de usuários em sistemas de destino específicos. Grupos restritos podem ser usados para especificar e aplicar a associação de grupo local e de domínio na floresta. Juntas, essas ferramentas fornecem todo o necessário para automatizar e implementar um modelo de delegação do Active Directory.

Resumo
Embora a tarefa de desenvolver um modelo de delegação do Active Directory possa parecer complexa, a verdade é que existem modelos muito simples que podem ser aplicados à maioria das infra-estruturas de TI. Uma das etapas mais importantes na implantação de um modelo de delegação prática é definir funções claras. Limite as funções definidas a um número pequeno e gerenciável. O equilíbrio é difícil, pois muitas funções resultarão em funções que não estão sendo usadas, enquanto muito poucas funções não permitirão a separação de função.
Lembre-se: ao definir tarefas, categorize-as por freqüência, importância e dificuldade. Após definir as funções, desenvolva um conjunto de casos de uso para ajudá-lo a identificar que função pode ou não realizar e automatizar o processo de teste. Casos de uso bem preparados o ajudarão a explicar essas funções às partes interessadas de sua organização, além de minimizar qualquer surpresa em razão de erros de automação.
Finalmente, é sempre aconselhável lançar mão de uma abordagem prática ao desenvolver um modelo de delegação. Lembre-se de que simplicidade equivale a flexibilidade de suporte e um modelo de delegação sustentável pagará dividendos imensos no controle de direitos administrativos dentro do seu ambiente do Active Directory.
Recursos adicionais
  • Design Considerations for Delegation of Administration in Active Directory
  • Best Practices for Delegating Active Directory Administration

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


 Administra&#231;&#227;o do Windows: Investigue os novos modelos de Diretiva de Grupo no Windows Vista:
Administração do Windows Darren Mar-Elia

Investigue os novos modelos de Diretiva de Grupo no Windows Vista:
Visão geral:
  • Dentro do ADMX
  • Editando arquivos ADMX
  • Como diferem os arquivos ADM e ADMX
  • Criando um armazenamento central
O

Antes do Windows Vista, os valores do Registro que você poderia definir na Diretiva de Grupo eram regidos por arquivos ADM, cuja sintaxe era misteriosa e proprietária. Se precisasse controlar valores adicionais do Registro além dos enviados pela Microsoft com os arquivos ADM padrão, você teria que aprender essa
sintaxe e criar um arquivo ADM personalizado. Além disso, esses arquivos ADM eram armazenados com cada GPO (Objeto de Diretiva de Grupo) no ambiente do Active Directory®, e cada um desses GPOs com os arquivos ADM associados eram replicados em todos os controladores de domínio no domínio.
Com o lançamento do Windows Vista™, a Microsoft dá um passo importante na área de modelos do Registro baseados em Diretiva de Grupo. O Windows Vista introduziu alterações significativas tanto no formato do arquivo ADM, chamado agora de ADMX, quanto no modo como esses arquivos são armazenados. Neste artigo, darei uma olhada dentro do novo formato do ADMX e discutirei como esses arquivos são diferentes do ADM. Também analisarei de que modo o armazenamento desses arquivos é tratado em um ambiente do Windows Vista.

Diferenças do ADMX
A maior diferença entre os formatos do novo arquivo ADMX e o antigo ADM que existe desde o Windows NT® 4.0 é que o ADMX adotou o padrão XML para descrever configurações de diretiva do Registro. Isso é bom por vários motivos. O primeiro deles é que há muito mais ferramentas de edição XML do que de sintaxe do ADM. O segundo é que, como o XML é esquematizado, ele acabará sendo mais fácil para criar ferramentas que lhe ajudam a saber as marcas certas para colocação nos lugares certos, com o fim de criar um arquivo ADMX bem formado. Esquematizado significa que, em um determinado aplicativo de XML, como o formato ADMX, existe um esquema documentado que descreve os elementos e os atributos possíveis, além do modo como são organizados. Veremos um exemplo mais adiante no artigo.
A outra diferença chave entre o ADMX e o ADM é a separação da seção de seqüências do arquivo ADMX principal em um arquivo ADML de linguagem específica. Se estiver familiarizado com arquivos ADM, você saberá que, no final de cada arquivo, existe uma seção delimitada por uma marca "[strings]" onde é possível atribuir valores a seqüências de texto que você desejar exibir ao usar o Editor de Diretiva de Grupo e os Modelos Administrativos. Por exemplo, o texto exibido quando você clicou na guia Explicação em uma determinada diretiva foi armazenado na seção dessa seqüência. O problema nesse caso é que as seqüências foram armazenadas dentro do arquivo ADM, portanto, se você quisesse usar esse ADM em um sistema Windows® que estivesse sendo executado em um idioma diferente, seria preciso criar um novo arquivo ADM com uma seção de seqüências para esse idioma.
Seria ainda mais complicado se um usuário, digamos, da versão francesa do Windows, desejasse editar um GPO existente que usasse ADMs ingleses. O administrador francês só veria o inglês no editor de Diretiva de Grupo. O Windows Vista contorna esse problema, separando a seção [strings] em um arquivo de Linguagem ADM (ou arquivo ADML) baseado em XML. O arquivo ADML pode ser fornecido em qualquer idioma para o qual exista suporte, e pode ser alterado facilmente, para oferecer suporte a qualquer novo idioma sem ter que tocar no arquivo ADMX principal que armazena as diretivas. Mais importante: quando o administrador francês edita um GPO na respectiva estação de trabalho do Windows Vista, o Editor de Diretiva de Grupo detecta que a versão francesa do Windows está sendo usada e carrega os arquivos ADML franceses para esse GPO, automaticamente.
Você pode ver todos os arquivos ADMX e ADML que vêm com a sua instalação do Windows Vista, abrindo a pasta em c:\windows\policydefinitions (consulte a Figura 1).
Figura 1 Arquivos ADMX no Windows Vista
Figura 1 Arquivos ADMX no Windows Vista (Clique na imagem para diminuir a exibição)
Figura 1 Arquivos ADMX no Windows Vista
Figura 1 Arquivos ADMX no Windows Vista (Clique na imagem para aumentar a exibição)
Observe que no alto da listagem de arquivos, na Figura 1, há uma pasta chamada en-us. Trata-se da pasta específica do idioma que contém os arquivos ADML dos arquivos ADMX que você vê nessa pasta PolicyDefinitions, nesse caso para inglês americano. Há um arquivo ADM para cada ADMX. No momento da elaboração deste artigo, o Windows Vista contava com 132 arquivos ADMX/ADML por padrão. Esta é outra grande diferença entre o Windows Vista e as versões anteriores: Os GPOs criados pelo Windows XP geralmente mantinham cinco arquivos ADM, sendo o System.adm o maior deles, que mantinha itens de diretiva para a maioria dos componentes do Windows sob controle da diretiva. No Windows Vista, a Microsoft decidiu dividir os arquivos ADMX por função, por isso o número muito maior de arquivos ADMX. Cada ADMX normalmente cobre um único componente do Windows (como Painel de Controle, Cliente DNS Client, Windows Explorer etc).

Dentro do ADMX
O fato de ADMXs serem gravados em XML representa uma melhora significativa, como mencionei anteriormente. Contudo, muitos administradores não sabem como escrever XML, muito menos entender o esquema usado pelo ADMX para criar extensões de diretivas. Embora um tutorial sobre criação personalizada de ADMX esteja além do escopo deste artigo, vamos dar uma olhada em como os ADMXs são formados.
Você pode abrir um arquivo ADMX ou ADML em qualquer editor de texto, até no Bloco de Notas, mas, a menos que o seu editor entenda a sintaxe XML, isso pode não ser muito significativo. Eu uso o Visual Studio® porque o respectivo recurso IntelliSense® auxilia a preencher elementos específicos. A Figura 2 mostra as primeiras linhas de um dos ADMXs fornecidos com o Windows Vista.
Figure 2 Alguns XML em um arquivo ADMX (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
Isso pode parecer estranho se você não estiver familiarizado com XML, mas muitos desses elementos XML podem ser encontrados em qualquer arquivo ADMX. O elemento policyNamespaces, por exemplo, identifica de forma única esse arquivo ADMX dentro do universo de todos os arquivos ADMX.
Se você criava arquivos ADM personalizados em versões anteriores do Windows, sabe que havia um conjunto de marcas, como Category, Policy, ListBox e ActionList, empregado para definir configurações de diretivas que apareceriam no Editor de Diretiva de Grupo. Várias dessas marcas não foram alteradas ou foram apenas levemente alteradas no formato ADMX, mas parecem muito diferentes porque estão representadas como XML. Por exemplo, escrevi um arquivo ADM personalizado que habilitou vários tipos de log dentro do Windows para a solução de problemas de Diretiva de Grupo. Uma seção desse ADM personalizado é mostrada na Figura 3. Transportei esse arquivo para o novo formato ADMX, como mostra a Figura 4.
Figure 4 O arquivo ADM convertido em arquivo ADMX (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 Um arquivo ADM personalizado (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
Em vários aspectos, esse trecho do ADMX é muito mais simples de entender do que o primo ADM, por ser mais concentrado. O elemento de diretiva especifica o que essa política estiver fazendo (Log de Redirecionamento de Pasta). Os atributos com prefixo $(string. são referências ao elemento de seqüência ADML correspondente. Os atributos key e valuename, obviamente, especificam a chave do Registro e o valor que essa diretiva afeta. O elemento parentCategory controla onde essa diretiva aparece na hierarquia Modelo Administrativo do Editor de Diretiva de Grupo. O elemento supportedOn indica a versão do sistema operacional que respeita essa diretiva e, finalmente, os elementos enabledvalue e disabledvalue especificam os valores que são colocados no Registro quando essa diretiva é definida para habilitada e desabilitada.
Trata-se de uma diretiva liga/desliga bem simples. Como na sintaxe do ADM, é possível criar elementos mais complexos da interface do usuário dentro do Editor de Diretiva de Grupo. Quando você faz isso no ADMX, a sintaxe fica um pouco mais complexa e inclui um atributo de apresentação que faz referência a uma parte do arquivo ADML onde podem ser encontradas as legendas do elemento da interface do usuário. Mas, além disso, a sintaxe do ADMX realmente não é muito complicada. Uma coisa a se ter em mente é que alguns dos nomes de marca foram alterados entre o ADM e o ADMX. Assim, por exemplo, na linguagem do ADM temos as marcas "edittext" e "listbox" Na ADMX, você encontra essas marcas chamadas de "text" e "list" no arquivo ADMX. Esses elementos terão entradas correspondentes no arquivo ADML que especifica o texto exibido juntamente com eles.
Como você já deve saber, um administrador pode carregar um arquivo ADM personalizado (herdado) no Editor do Objeto de Diretiva de Grupo do Windows Vista. As pessoas geralmente me perguntam se a Microsoft irá fornecer um utilitário para conversão de arquivos ADM personalizados na sintaxe do ADMX. Na verdade, a Microsoft se uniu à FullArmor Corp. para lançar uma ferramenta gratuita chamada ADMX Migrator. Essa ferramenta faz duas coisas. Primeiro, ela converte seus arquivos ADM personalizados antigos no formato ADMX (consulte a Figura 5 para ver um exemplo de uso da ferramenta para converter meu gpolog.adm).
Figura 5 ADMX Migrator
Figura 5 ADMX Migrator (Clique na imagem para diminuir a exibição)
Figura 5 ADMX Migrator
Figura 5 ADMX Migrator (Clique na imagem para aumentar a exibição)
Segundo, ela fornece um Editor ADMX que lhe permite criar novos arquivos ADMX a partir do zero. Você pode baixar essa ferramenta em go.microsoft.com/fwlink/?LinkID=77409.

Armazenamento do ADMX
A outra alteração notável que desejo discutir é como os arquivos ADMX e ADML são armazenados para uso. Em versões do Windows anteriores ao Windows Vista, quando você editava um novo GPO, os arquivos ADM eram automaticamente copiados da estação de trabalho local onde você executasse as tarefas de edição, na parte SYSVOL do GPO, em um controlador de domínio dentro do domínio do Active Directory. Esses ADMs eram então replicados para todo DC em um domínio, para cada GPO que fosse criado. Isso desperdiçava muita largura de banda da rede e armazenamento em disco, especialmente em ambientes de grande porte com dúzias ou centenas de GPOs. O Windows Vista modificou esse processo radicalmente. Por padrão, quando você cria um GPO baseado no Active Directory em uma estação de trabalho do Windows Vista, as diretivas do Modelo Administrativo exibidas no Editor de Diretiva de Grupo são carregadas da pasta c:\windows\policydefinitions no computador em que você estiver editando o GPO.
Os arquivos ADMX e ADML não são copiados no SYSVOL; eles só são mencionados localmente. Isso elimina a carga de armazenamento e rede que os ADMs colocam no ambiente de Diretiva de Grupo. Mas pode ficar ainda melhor. O Windows Vista também dá suporte a um armazenamento central, um repositório de Modelos Administrativos. Isso aborda o modo como você efetivamente controla os arquivos ADMX usados para editar GPOs, independentemente de quem os edita. Isso é feito copiando-se todos os arquivos ADMX e ADML oficiais (e todos os personalizados que você criar) em um local de rede e, em seguida, todas as Diretivas de Grupo que estiverem editando de estações de trabalho do Windows Vista fazem referência a essas versões baseadas em rede, em vez de cada uma das respectivas versões locais individuais. Configurar um armazenamento central é uma tarefa fácil e única por domínio. Basta seguir as etapas da barra lateral "Creating a Central Store"

Resumo
O novo formato ADMX do Windows Vista é um aprimoramento nítido dos arquivos ADM usados em versões anteriores de sistemas operacionais. O uso de XML oferece uma estrutura mais clara para a edição e a pesquisa desses arquivos. A mudança de seqüências específicas do idioma em arquivos separados torna contínua a edição da Diretiva de Grupo, e o armazenamento central elimina a necessidade de armazenar e atualizar todos os seus GPOs com cópias de arquivos ADM. Tudo isso torna o aprendizado de ADMX uma atitude inteligente.
Criando um armazenamento central
A criação do armazenamento central é relativamente simples. Siga estas etapas simples para criar um em seu domínio do Active Directory.
Etapa 1: Abra o Explorer e navegue até o compartilhamento de SYSVOL no controlador de domínio do emulador de PDC do seu ambiente (você pode usar qualquer controlador de domínio, mas o proprietário de função PDC geralmente se encontra onde qualquer alteração de Diretiva de Grupo estiver focada).
Etapa 2: Examine de perto a pasta Diretivas, em SYSVOL, e crie uma nova pasta, chamada PolicyDefinitions.
Etapa 3: Copie o conteúdo da pasta C:\windows\policydefinitions da estação de trabalho do Windows Vista na nova pasta PolicyDefinitions, incluindo a pasta ADML dependente de idioma (por exemplo, en-us em computadores com o idioma inglês americano).
Depois que os arquivos ADMX e ADML são copiados para a pasta Armazenamento Central, o Editor de Objeto de Diretiva de Grupo no Windows Vista começa a fazer referência aos arquivos que lá se encontram e ignora os arquivos armazenados localmente.

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


 Administra&#231;&#227;o do Windows: Seu guia para a solu&#231;&#227;o de problemas de Diretiva de Grupo
Administração do Windows Derek Melber

Seu guia para a solução de problemas de Diretiva de Grupo
Visão geral:
  • Problemas comuns de GPO
  • Regras de Diretiva de Grupo
  • Solucionando problemas de GPO
  • Ferramentas de solução de problemas

O Microsoft Active Directory tornou-se um componente crítico de muitas infra-estruturas de TI. Um dos recursos mais importantes do Active Directory é a Diretiva de Grupo, que permite aos administradores centralizar o gerenciamento de controladores de domínio, servidores membro e áreas de trabalho.
Embora a Diretiva de Grupo ofereça nitidamente muitos benefícios, ela apresenta uma pequena falha: pode ser complexa de se criar e implementar em uma empresa de grande porte, e ainda mais problemática para solucionar problemas quando alguma coisa sai errada. Neste artigo investigarei como a Diretiva de Grupo é estruturada e mostrarei como solucionar os problemas respectivos. No final, você terá toda a munição de que necessita para atacar quase qualquer problema relacionado à Diretiva de Grupo.

Configurações problemáticas
Há muitas partes móveis na Diretiva de Grupo, especialmente em relação ao modo como ela faz interface com o design e a implementação gerais do Active Directory ®. Ao solucionar problemas de acesso e de rede de vários tipos, você deve incluir sempre o Active Directory e as noções básicas da implementação da Diretiva de Grupo em sua busca por uma solução. Para iniciar o processo de solução de problemas, vamos dar uma olhada nas configurações de Diretiva de Grupo que podem ser definidas incorretamente e, então, passaremos aos problemas mais complexos que podem fazer com que a Diretiva de Grupo funcione incorretamente.
As configurações de Diretiva de Grupo são exibidas pelos administradores do Active Directory usando arquivos administrativos de modelo (arquivos ADM ou ADMX) e o Editor de objeto de diretiva de grupo, ou GPEdit (iniciado pela execução do gpedit.msc). Com o GPEdit, o administrador cria arquivos de objeto de diretiva de grupo, ou GPOs. Os GPOs são configurados para serem aplicados (ou não) a computadores e usuários na estrutura do Active Directory. Existem várias regras que os GPOs devem seguir para funcionar corretamente. Vejamos essas regras agora:
O GPO deve ser anexado Quando um novo GPO é criado, ele não pode ser anexado a nenhum nó no Active Directory. Embora o GPO possa ser editado e modificado, ele não afetará nenhum objeto até ser anexado a um nó. Para garantir que o GPO é anexado corretamente, você pode exibir a janela de informações no GPMC (Console de gerenciamento de Diretiva de grupo), mostrado na Figura 1.
Figura 1 Os links do GPO são mostrados com clareza
Figura 1 Os links do GPO são mostrados com clareza (Clique na imagem para diminuir a exibição)
Figura 1 Os links do GPO são mostrados com clareza
Figura 1 Os links do GPO são mostrados com clareza (Clique na imagem para aumentar a exibição)
O GPO deve apontar o objeto correto Como você sabe, a Diretiva de Grupo deve apontar para objetos corretos no Active Directory. No entanto, isso às vezes passa despercebido no meio de um exercício de solução de problemas. Há duas categorias principais no GPO: computador e usuário. Ao configurar um GPO, certifique-se de observar se ele se destina a um computador ou a um objeto de usuário. Então você poderá verificar se os tipos corretos de objeto são colocados na UO (unidade organizacional) onde o GPO está anexado.
Os GPOs não são aplicados a grupos Embora você talvez desejasse que assim fosse, um GPO não pode ser aplicado a um objeto do grupo de segurança do Active Directory. Os dois únicos objetos que uma configuração GPO pode definir são computadores e usuários. Os GPOs não configuram objetos pela associação de grupo. Por exemplo, se houver um GPO anexado à UO Finance, como mostrado na Figura 2, os únicos objetos afetados pela configuração serão Derek e Frank. As configurações no GPO não afetarão os membros do grupo de Marketing, independentemente de quem tiver associação nesse grupo.
Figura 2 UO Finance e os objetos dentro dela
Figura 2 UO Finance e os objetos dentro dela (Clique na imagem para diminuir a exibição)
Figura 2 UO Finance e os objetos dentro dela
Figura 2 UO Finance e os objetos dentro dela (Clique na imagem para aumentar a exibição)
O objeto de destino deve estar no caminho do GPO Quando você notar que uma configuração de GPO não está afetando um objeto como deveria, existirá uma configuração mais importante: o objeto deve estar no SOM (Escopo de Gerenciamento) do GPO. Isso significa que o objeto deve estar localizado abaixo do nó onde o GPO está anexado (até um nó filho será suficiente). Por exemplo, nenhum dos objetos na UO Marketing será afetado por um GPO que esteja anexado à UO Finance, como mostra a Figura 3. O SOM de um GPO é do nó onde ele está anexado, abaixo na estrutura do Active Directory.
Figura 3 Quando as UOs encontram-se no mesmo nível, os GPOs aplicam-se apenas à UO onde ele estiver anexado
Figura 3 Quando as UOs encontram-se no mesmo nível, os GPOs aplicam-se apenas à UO onde ele estiver anexado (Clique na imagem para diminuir a exibição)
Figura 3 Quando as UOs encontram-se no mesmo nível, os GPOs aplicam-se apenas à UO onde ele estiver anexado
Figura 3 Quando as UOs encontram-se no mesmo nível, os GPOs aplicam-se apenas à UO onde ele estiver anexado (Clique na imagem para aumentar a exibição)
O GPO precisa ser habilitado Quando o GPO é criado, ele não é configurado para fazer nenhuma modificação em objetos de destino. Entretanto, ele é habilitado para as partes de computador e de usuário. Se alguma dessas partes for desabilitada, poderá ser difícil rastreá-la. Portanto, quando estiver solucionando problemas em um GPO que não será aplicado, convém verificar se alguma parte do GPO ou todo o GPO está desabilitado. Isso pode ser feito olhando-se em Objetos de Diretiva de Grupo | Diretiva de Conta, no GMPC, e verificando-se o status do GPO.
Algumas configurações precisam de reinicialização Quando uma configuração do GPO não estiver funcionando corretamente, pode ser devido ao processamento inerente de GPOs. Quando a atualização periódica de segundo plano é disparada, ela só é capaz de processar algumas configurações do GPO, mas não todas. Assim, embora você possa ter criado uma configuração, talvez ela ainda não tenha tido efeito. Há algumas configurações categorizadas como Diretivas de Primeiro Plano, e elas só são aplicadas quando o computador é reiniciado ou quando o usuário faz logoff e faz login em seguida. Exemplos de configurações que se comportam dessa forma incluem instalação de software, redirecionamento de pastas e aplicação de script.

Aplicações síncronas e assíncronas de configurações
Em um GPO você pode configurar o modo como ocorre a aplicação da diretiva, na inicialização e no logon. As alterações que você puder fazer darão acesso imediato à área de trabalho enquanto as diretivas ainda estiverem sendo aplicadas, ou garantirão que todas as diretivas sejam aplicadas antes que o usuário tenha acesso à área de trabalho. A Figura 4 mostra como se comporta cada sistema operacional, por padrão. Se desejar alterar esse comportamento, modifique a configuração de diretiva a seguir:
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 Processamento padrão no cliente (Close Figure 4)

Sistema operacional | Inicialização | Logon | Atualização de diretiva
Windows 2000 | Em sincronia | Em sincronia | Sem sincronia
Windows XP Professional | Sem sincronia | Sem sincronia | Sem sincronia
Windows Server 2003 | Em sincronia | Em sincronia | Sem sincronia
A maioria dos administradores prefere a aplicação síncrona de diretiva, para garantir que todas as diretivas sejam aplicadas antes que o usuário possa acessar a área de trabalho. Isso assegura que todas as definições de segurança e configuração sejam aplicadas antes que qualquer trabalho possa ser realizado pelo usuário. Esse não é o estado padrão no Windows® XP Professional, que foi otimizado para propiciar velocidade de logon aprimorada.

Alterando a herança padrão
Existem quatro métodos diferentes que podem ser usados para alterar a herança padrão de processamento do GPO. Essas opções são eficientes e devem ser usadas de maneira comedida, pois podem causar alterações significativas ao comportamento do processamento de Diretiva de Grupo. Além disso, a solução de problemas dessas opções pode ser muito difícil de se executar. As opções para alteração de herança padrão incluem as quatro definições e configurações a seguir:
  • Bloquear herança de diretiva
  • Aplicação de GPO
  • Filtragem de GPO da ACL (lista de controle de acesso
  • Filtros WMI (Instrumentação de Gerenciamento do Windows)
Como essas configurações devem ser usadas de forma comedida, deve ser fácil documentar quando elas estiverem sendo usadas. Para saber se essas opções estão em uso, procure no GPMC. O bloqueio de herança é executado no nó do domínio ou da UO no GPMC. A aplicação de GPO, a filtragem da ACL e a filtragem WMI são definidas em cada GPO.
Você também pode executar o comando Gpresult no computador de destino para ter uma idéia quanto a alguma dessas configurações estar proibindo as diretivas de serem aplicadas ou não. Para ter uma visão mais aprofundada do conjunto resultante de diretivas que estão sendo aplicadas, adicione a opção /v ao comando Gpresult, que fornecerá a saída detalhada.

Problemas do modelo ADM
Quando você tenta definir configurações em um GPO na seção Modelos Administrativos, você trabalha com modelos ADM. Além dos modelos ADM fornecidos com o sistema operacional, você pode personalizar o seu próprio para uso em um GPO. O código no modelo ADM cria as pastas e diretivas no Editor de Diretiva de Grupo, do nó Modelos Administrativos. Entretanto, se o modelo ADM estiver corrompido, ausente ou configurado incorretamente, é bem possível que você não veja algumas ou todas as configurações no editor. Eis alguns outros problemas em relação aos quais você deve se resguardar quando usar os modelos ADM:
Modelos ADM ausentes Quando você edita um GPO e descobre que existem configurações no modelo ADM que não são exibidas no editor, é preciso importar o modelo ADM para o GPO. Para isso, basta clicar com o botão direito do mouse no nó Modelos Administrativos, no editor, e selecionar Adicionar ou remover modelos.
Preferências ausentes Há dois tipos de configurações que podem ser criadas em um GPO personalizado: preferências e diretivas. Diretivas são as configurações padrão da Microsoft incluídas todas em uma das quatro subchaves no Registro, cada uma delas terminando com o texto "Policies". Preferências são modificações no “estilo antigo” ao Registro; essas modificações não se incluem em uma das quatro subchaves, e são difíceis de se reverter depois de configuradas. Por padrão, essas preferências não são exibidas no editor. Você precisa habilitá-las para que apareçam; para isso, vá até o menu Exibir, na barra de ferramentas. Nesse menu, selecione Filtragem, marque a caixa de seleção "Só mostrar configurações de diretiva que podem ser 100% gerenciadas". Isso exibirá imediatamente as preferências configuradas em seus modelos ADM personalizados que foram importados.

Ferramentas úteis
Existem várias ferramentas disponíveis para ajudá-lo a rastrear seus problemas de Diretiva de Grupo. Algumas são internas do sistema operacional e outras podem ser baixadas e instaladas. Em seguida discutirei as ferramentas adequadas para que você possa escolher a ferramenta correta para a sua tarefa.
Dcgpofix Pode acontecer de você ter um problema com um dos dois GPOs padrão: Diretiva de Domínio Padrão e Diretiva Padrão de Controladores de Domínio. Se um ou os dois GPOs ficar corrompido, altamente fora da configuração onde você não possa corrigi-lo, ou algum outro problema desconhecido, use a ferramenta dcgpofix para revertê-los ao estado padrão. Essa ferramenta está incluída no Windows Server® 2003. Você não deve executá-la em um controlador de domínio do Windows 2000; em vez disso, use a ferramenta Recreatedefpol. E lembre-se: ao usar essa ferramenta, você perderá todas as configurações personalizadas.
Recreatedefpol Essa ferramenta é semelhante ao Dcgpofix, mas em servidores do Windows 2000. Ela pode retornar dois GPOs padrão ao respectivo estado de recém-instalado. Essa ferramenta só deve ser usada em uma situação de recuperação de desastres e não na manutenção de rotina de GPOs. Você pode baixar esta ferramenta.
Visualizar eventos O comando Visualizar eventos tem uma profusão de informações relacionadas à Diretiva de Grupo. Infelizmente, ele requer que você examine todos os arquivos de log diferentes para localizar entradas da Diretiva de Grupo. Lá você encontrará entradas relacionadas à aplicação da diretiva, replicação de diretiva e atualização de diretiva, todas úteis quando se procura rastrear um problema. Nem sempre há muitas informações sobre erros específicos de Diretiva de Grupo nos logs de eventos, mas lembre-se de que você pode sempre procurar no TechNet se encontrar erros que não puder identificar.
Gpresult Essa ferramenta só pode ser executada localmente no computador de destino, mas ela fornece informações sobre o RSoP (Conjunto de Diretivas Resultante), GPOs bloqueados, permissões em GPOs etc. Usar o comando com a opção /v mostrará uma boa dose de informações sobre os GPOs que estão afetando o computador e sobre contas de usuário associadas à sessão de logon atual.
Gpupdate Se estiver implementando novas configurações do GPO ou tentando garantir que todo o processamento do GPO ocorreu, use a ferramenta Gpupdate. Trata-se de uma ferramenta de linha de comando que vem com o sistema operacional (Windows XP e posteriores). Quando você a executa, ela dispara uma atualização em segundo plano que aplica todas as configurações do GPO que aderirem a esse tipo de atualização. Se você adicionar a opção /force, ela aplicará novamente todas as configurações do GPO, mesmo que não tenha havido nenhuma alteração a ele desde a última atualização. Executar esse comando antes de executar o comando Gpresult é um método muito eficiente para rastrear problemas de GPO.
Gpotool Como os GPOs são replicados do controlador de domínio onde ocorrem inicialmente as alterações do GPO para todos os demais controladores de domínio, existe uma chance de ocorrer falha ou não convergência eficiente da replicação. O resultado disso é a inconsistência ou falha das alterações a serem aplicadas corretamente aos computadores de destino. Ferramentas como Gpresult e RSOP podem ajudar a determinar que GPOs foram aplicados; mas essa ferramenta, a Gpotool, pode ajudá-lo a determinar se os GPOs em cada controlador de domínio estão consistentes. A ferramenta faz parte do Windows Server 2003 Resource Kit, disponível em go.microsoft.com/fwlink/?LinkId=77613.
Replmon Quando solucionar problemas de replicação de GPO de um controlador de domínio para outro, é importante saber que ferramentas você pode usar para ajudá-lo a fazer a replicação funcionar. Como existem duas partes de um GPO que devem ser replicadas, existem duas partes que precisam ser abordadas: A primeira, que vem a ser o conteúdo de SYSVOL em cada controlador de domínio, é controlada pelo FRS (Serviço de Duplicação de Arquivos) Não há realmente muito que se possa fazer para controlar essa replicação, exceto desabilitar e habilitar o serviço para ajudá-lo a disparar um intervalo de replicação. A outra parte do GPO, armazenada no Active Directory, é controlada pela replicação do Active Directory. Essa replicação pode ser controlada entre controladores de domínio no mesmo site do Active Directory, por meio do Sites e Serviços do Active Directory. Contudo, quando você precisar disparar uma replicação entre controladores de domínio em sites diferentes do Active Directory, precisará usar uma ferramenta como a Replmon. A Replmon pode forçar a replicação do banco de dados do Active Directory em fronteiras do site, ao passo que o Sites e Serviços do Active Directory não pode. Portanto, quando você tiver uma divergência de informações da Diretiva de Grupo, informações essas que são armazenadas no Active Directory, use a ferramenta Replmon para disparar um processo de replicação e obter essas informações convergidas em cada controlador de domínio. A ferramenta Replmon faz parte do Resource Kit e das ferramentas de suporte do Windows XP. Você pode baixá-la em go.microsoft.com/fwlink/?LinkId=77614.
RSOP Assim como a ferramenta de linha de comando Gpresult, a RSOP oferece uma interface gráfica para análise das configurações que foram aplicadas por todos os GPOs. O RSOP.MSC é uma ferramenta interna do Windows XP Professional e do Windows Server 2003. A ferramenta oferece um resultado de todas as configurações de diretiva aplicadas em um formato semelhante ao do Editor de Objeto de Diretiva de Grupo, como mostrado na Figura 5.
Figura 5 Ferramenta Conjunto de Diretivas Resultante
Figura 5 Ferramenta Conjunto de Diretivas Resultante

Conclusão
A solução de problemas de Diretiva de Grupo não é a tarefa mais fácil que você já tentou realizar. Na verdade, como mostra este artigo, a Diretiva de Grupo pode ser bem complexa. Quando você a aborda para solucionar problemas, é necessário compreender a arquitetura básica e o processamento geral típico de Diretiva de Grupo. Você também precisa entender como um GPO é atualizado, replicado, processado e aplicado. Se você tem um bom entendimento de todos esses conceitos, solucionar qualquer problema específico de Diretiva de Grupo é muito mais fácil. Seguindo as diretrizes deste artigo e usando suas ferramentas de maneira adequada, você estará pronto para enfrentar os problemas de Diretiva de Grupo que encontrar.

Derek Melber é diretor de educação, certificação e conformidade da DesktopStandard, uma subsidiária de propriedade integral da Microsoft. Derek foi co-autor do livro Microsoft Windows Group Policy Guide (Microsoft Press, 2005). Ele também escreveu uma série de livros sobre auditoria de segurança no Windows (www.theiia.org). Entre em contato com Derek em derekm@desktopstandard.com.


 Administra&#231;&#227;o do Windows: Monitorando o Active Directory com o MOM
Administração do Windows John Hann

Monitorando o Active Directory com o MOM
Visão geral:
  • Pacotes de gerenciamento do Active Directory
  • Dicas de personalização do MOM
  • Ajuste de alerta

Os pacotes de gerenciamento são a alma do MOM 2005 (Microsoft Operations Manager) e é o que diferencia o MOM de outros produtos de gerenciamento. O MOM usa pacotes de gerenciamento para reunir regras, relatórios, tarefas e exibições e pode ter escopo limitado a um aplicativo
ou serviço específico, como o Active Directory. As equipes de produtos da Microsoft criaram os pacotes de gerenciamento para os aplicativos por elas desenvolvidos, assegurando que o MOM reflita o conhecimento profundo das equipes em relação ao produto. Além disso, os pacotes de gerenciamento podem ser personalizados para se ajustar ao seu ambiente de TI. Você então tem regras que monitoram e gerenciam o produto com base no seu servidor e no seu ambiente de aplicativo específicos.
Não só existe um pacote de gerenciamento específico para o Active Directory®, mas muitos pacotes de gerenciamento para medir a integridade dos serviços de diretório, desde os sistemas operacionais de base do Windows Server® até Protocolo DHCP, DNS e FRS (Serviço de Duplicação de Arquivos). Vamos examinar esses pacotes de gerenciamento em detalhes, assim você terá uma compreensão melhor sobre a possibilidade de gerenciamento ponta a ponta do Active Directory pelo MOM.

Pacote de gerenciamento do DHCP
O pacote de gerenciamento do DHCP Service monitora o serviço do DHCP em execução no Windows NT®, Windows® 2000 e Windows Server 2003. Monitorar o DHCP é uma boa idéia, pois você fica sabendo se clientes estão tendo problemas para se conectar à rede. Você também será alertado sobre servidores DHCP não autorizados em execução no seu ambiente. O pacote de download desse pacote de gerenciamento contém um guia que documenta as regras e os relatórios, além de monitorar os cenários e implantação. Um tesouro de documentações e orientações adicionais pode ser encontrado no site do MOM 2005 da TechNet (microsoft.com/technet/prodtechnol/mom/mom2005).
Quanto mais recente for a versão do Windows em que você executar o serviço DHCP, mais instrumentação e funcionalidade o MOM 2005 fornecerá para gerenciá-lo. Portanto, você obterá mais informações sobre um servidor DHCP do Windows Server 2003, do que de um servidor DHCP do Windows NT. Por exemplo, um servidor DHCP em execução no Windows Server 2003 pode ter os respectivos superescopos monitorados, ao passo que o pacote de gerenciamento DHCP monitora apenas os escopos normais em um servidor DHCP do Windows 2000. Você pode impedir que escopos sejam monitorados, colocando-os como um parâmetro do script de monitoramento.
Como mencionado anteriormente, o pacote de gerenciamento DHCP oferece suporte a servidores DHCP em execução no Windows NT, no Windows 2000 Server e no Windows Server 2003. Os grupos de computadores são preenchidos por meio de fórmulas que usam a versão do sistema operacional, e se o servidor hospedar o serviço do servidor DHCP.
O pacote de gerenciamento DHCP não oferece suporte a configurações de baixo privilégio. A Conta de Ação agente deve ser um membro do grupo Administradores local. Há suporte para o monitoramento sem agente, porém tarefas não têm suporte na configuração sem agente. A Figura 1 lista os relatórios disponíveis no pacote de gerenciamento DHCP.
Figure 1 Relatórios do serviço DHCP (Close Figure 1)

Todos os servidores DHCP
Todos os servidores DHCP autorizados
Histórico de desempenho - comprimento de fila ativa
Histórico de desempenho - comprimento da fila de verificação de conflito
Histórico de desempenho – recusas por segundo
Histórico de desempenho - descobertas por segundo
Histórico de desempenho- milissegundos por pacote (Méd)
Histórico de desempenho - NACKs por segundo
Histórico de desempenho- endereços sem escopo
Histórico de desempenho - endereços do escopo em uso
Histórico de desempenho - endereço sem de superescopo
Histórico de desempenho - endereços de superescopo em uso
O download do pacote de gerenciamento DHCP pode ser feito em go.microsoft.com/fwlink/?LinkId=79527.

Pacote de gerenciamento do DNS
O pacote de gerenciamento do Domain Name Service monitora o serviço DNS em execução no Windows 2000 Server e no Windows Server 2003. Como se trata de uma parte fundamental da integridade geral de uma implementação do Active Directory, o monitoramento do DNS com o MOM 2005 é essencial. O pacote de gerenciamento do DNS monitora problemas de resolução de nome, problemas de banco de dados, problemas do Registro, eventos e erros de tempo de execução, bem como contadores de desempenho relacionados.
No caso do Windows 2000 Server, um provedor de DNS WMI (Windows Management Instrumentation) precisa ser instalado. Especificamente, isso permite que o pacote de gerenciamento do DNS consulte o namespace DNS do WMI para informações e testes.
Os grupos de computadores são todos preenchidos por fórmulas que usam a versão do sistema operacional e se o servidor hospedar o serviço do servidor DNS para determinar a associação de grupo. O pacote de gerenciamento do DNS oferece suporte a baixo privilégio apenas no Windows Server 2003. No Windows 2000, a Conta de Ação deve ser um membro do grupo Administradores local. No Windows Server 2003, a Conta de Ação deve ser um membro dos grupos locais Usuários e Usuários de Monitor de Desempenho. Além disso, a Conta de Ação deve ter permissões Gerenciar auditoria e log de segurança (SeSecurityPrivilege) e Permitir logon local (SeInteractiveLogonRight). A Figura 2 lista os relatórios disponíveis no pacote de gerenciamento do DNS.
Figure 2 Relatórios do serviço DNS (Close Figure 2)

Todos os servidores DNS do Windows
Todos os servidores DNS do Windows por zona
Todas as zonas DNS do Windows por servidor
Marcus Oh, um MVP de SMS (Systems Management Server) da Microsoft®, desenvolveu um script que testa um servidor DNS, chamando o nslookup para verificar a capacidade do servidor DNS para resolver os nomes. Reserve um tempo para analisar a postagem de Marcus no blog, em marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html, você vai querer integrar esse script ao seu pacote de gerenciamento do DNS.
Você pode fazer download do pacote de gerenciamento do DNS em go.microsoft.com/fwlink/?LinkId=79528.

Pacote de gerenciamento do FRS
O pacote de gerenciamento do Serviço de Replicação de Arquivos do Windows monitora o serviço FRS em execução no Windows 2000 e no Windows Server 2003. O FRS é usado pelos controladores de domínio para replicar scripts de logon e informações de Diretiva de Grupo. O pacote de gerenciamento do FRS detalhará a integridade do serviço FRS em cada controlador de domínio.
O pacote de gerenciamento do FRS utiliza a ferramenta Ultrasound, disponível em go.microsoft.com/fwlink/?LinkId=79529. O Ultrasound cria um namespace WMI para FRS em cada controlador de domínio. Observe que o Ultrasound requer um banco de dados e armazenará as informações do namespace WMI em cada controlador de domínio, para monitoramento de integridade. Usando as informações do Ultrasound, o pacote de gerenciamento do FRS oferece monitoramento de conjuntos de réplica, de membros, de conexões, do próprio serviço FRS e do serviço controlador Ultrasound.
Na verdade, você deve instalar o Ultrasound em um servidor separado do servidor de gerenciamento. As regras do Ultrasound geram eventos e alertas em nome de outros computadores. Para que as regras do Ultrasound processem os dados corretamente, você deve habilitar o proxy agente no console de administração do MOM em cada servidor com o Ultrasound em execução. A Figura 3 lista os quatro relatórios de serviço disponíveis no pacote de gerenciamento do FRS.
Figure 3 Relatórios do serviço FRS (Close Figure 3)

Ultrasound - problemas detectados com freqüência: conexões mais problemáticas
Ultrasound - problemas detectados com freqüência: membros mais problemáticos
Ultrasound - problemas detectados com freqüência: conjunto de réplicas mais problemáticas
Ultrasound - problemas detectados com freqüência: resumo
Os grupos de computadores associados a esse pacote de gerenciamento incluem os servidores Microsoft Ultrasound 1.0 e servidores FRS executados no Windows 2000 Server e no Windows Server 2003. Os grupos de computadores são todos preenchidos por fórmulas que usam a versão do sistema operacional e se o servidor hospedar o serviço FRS para determinar a associação de grupo. O grupo de servidores Ultrasound será preenchido quando um servidor tiver o Ultrasound instalado.
Quando você configura o pacote de gerenciamento do FRS para baixo privilégio, as tarefas não funcionam, mas há suporte para o restante das funcionalidades do pacote de gerenciamento. A Conta de Ação deve ter acesso de leitura ao banco de dados Ultrasound e permissão de execução do procedimento armazenado GetControllerStatusForMOM001. O pacote de gerenciamento do FRS inclui suporte para monitoramento sem agente, bem como computadores gerenciados por agente.
O download do pacote de gerenciamento do FRS pode ser feito em go.microsoft.com/fwlink/?LinkId=79530.

Pacote de gerenciamento do Windows Server
O pacote de gerenciamento do Windows Base Operating System monitora o Windows NT 4.0 Server, o Windows 2000 Server e o Windows Server 2003. O pacote de gerenciamento do SO Base reportará a integridade do sistema operacional aos seus controladores de domínio, além de monitorar os serviços de raiz no sistema. O pacote de gerenciamento apresenta o status dos serviços principais do Windows, desempenho de memória e processador, bem como o espaço livre em disco e a latência em disco. Existe alguma sobreposição entre as regras de monitoramento desse pacote de gerenciamento e as demais regras abordadas neste artigo, mas ela oferece uma visão bem detalhada da integridade do controlador de domínio.
A Figura 4 mostra os relatórios disponíveis no pacote de gerenciamento do SO Base. Como nos outros pacotes de gerenciamento, os grupos de computadores são todos preenchidos por fórmulas que usam a versão do sistema operacional.
Figure 4 Relatórios do sistema operacional de base (Close Figure 4)

Análise de desempenho de disco
Configuração do sistema operacional
Desempenho do sistema operacional
Desligamento do sistema operacional por evento
Desligamento do sistema operacional por servidor
Configuração de armazenamento do sistema operacional
Instalações de software e aplicativos por aplicativo
Instalação de software e aplicativos por instância
Instalações de software e aplicativos por servidor
Confiabilidade - falhas de aplicativo por aplicativo
Confiabilidade - falhas de aplicativo por computador
Confiabilidade - falhas de aplicativo por evento
Confiabilidade - falhas do sistema operacional por computador
Confiabilidade - falhas do sistema operacional por evento
Confiabilidade - falhas do sistema operacional por código de interrupção
Histórico de desempenho - histórico de desempenho
Histórico de desempenho - relatórios adicionais
Ao configurar o pacote de gerenciamento do SO Base para operações com baixo privilégio, o Windows 2000 requer que a Conta de Ação seja um membro do grupo Administradores local. O Windows Server 2003 requer que a Conta de Ação seja um membro dos grupos locais Usuários e Usuários de Monitor de Desempenho, além de possuir permissões Gerenciar auditoria e log de segurança (SeSecurityPrivilege) e Permitir logon local (SeInteractiveLog-onRight). A maior parte do pacote de gerenciamento do SO Base, com exceção das tarefas, tem suporte em computadores monitorados sem agente.
O download do pacote de gerenciamento do SO Base pode ser feito em go.microsoft.com/fwlink/?LinkId=79531.

Pacote de gerenciamento do Active Directory
O pacote de gerenciamento do Active Directory é muito amplo e as respectivas regras abordam o Windows 2000 Server e o Windows Server 2003. O pacote de gerenciamento do Active Directory abrange cinco áreas de regras: monitoramento do lado cliente, monitoramento de confiança, monitoração da replicação e descoberta de topologia, além das regras que abordam os sistemas operacionais Windows 2000 Server e Windows Server 2003. Como já vimos antes, as versões mais recentes do Windows permitem mais instrumentação e, portanto, mais monitoramento. Por exemplo, o pacote de gerenciamento oferece suporte a monitoramento de confiança no Windows Server 2003, mas não no Windows 2000.
O pacote de gerenciamento do Active Directory cria uma série de grupos que são usados para aplicar regras a computadores específicos. As regras de monitoramento do lado do cliente usam um grupo chamado Active Directory Client Side Monitoring. Você colocaria os computadores que tivessem o agente MOM instalado nesse grupo para monitorar e gerenciar essas regras. Eu coloquei alguns computadores desktop licenciados com o agente nesse grupo, bem como alguns servidores Exchange. O Exchange Server usa muito o Active Directory e pode ser o indicador de um problema de desenvolvimento. Os computadores desktop no grupo podem ajudá-lo a avaliar a experiência do usuário final. As regras de monitoramento do lado cliente utilizam scripts para testar a conectividade em controladores de domínio, consultando-os por LDAP e reportando falhas. É importante observar que as regras de monitoramento do lado do cliente só podem ser aplicadas a computadores gerenciados por agente com proxy habilitado, mas que não sejam controladores de domínio.
As regras de monitoramento de confiança usam um grupo chamado Active Directory Trust Monitoring. Os computadores Windows Servers 2003 devem ser colocados nesse grupo para testar confianças. O Windows Servers 2003 tem um namespace WMI para monitoramento de confiança. Essas regras empregam um script para consultas ao namespace WMI. Quando forem detectados erros em confianças com outros domínios, essas regras irão alertá-lo.
Há muitas regras do pacote de gerenciamento do Active Directory que se aplicam ao Windows 2000 Server ou ao Windows Server 2003. Essas regras delineiam as diferenças na forma como o Active Directory é implementado entre os dois sistemas operacionais. No entanto, a maior parte do pacote de gerenciamento do Active Directory está nas regras combinadas de ambos os sistemas operacionais. Algumas dessas regras incluem scripts para testar a conectividade entre controladores de domínio, execução de função FSMO (função de operação flutuante de mestre único), tamanho do banco de dados de DIT (árvore de informações de diretórios), validação de processamento de Diretiva de Grupo, inspeção KCC (Knowledge Consistency Checker) e teste do serviço de mensagens entre sites.
A monitoração da replicação é a parte central do pacote de gerenciamento do Active directory. Dois grupos, Active Directory Replication Latency Data Collection - Sources e Active Directory Replication Latency Data Collection – Target, Active Directory Replication Latency Data Collection (Sources and Active Directory Replication Latency Data Collection) Targets estão em vigor para permitir que você configure os controladores de domínio usados apenas para gerar relatório de monitoração da replicação. A latência de replicação é calculada para cada membro dos grupos de coleta de dados. Os contadores de desempenho são preenchidos com o tempo de replicação gasto pelas atualizações para cada um dos membros do grupo. A latência de replicação por toda a empresa é calculada e reportada (e alertas são gerados) se ela exceder os limites definidos. Observe que um namespace do WMI para monitoração da replicação precisa ser instalado no Windows 2000 Server.
No pacote de gerenciamento do Active Directory, a descoberta de topologia é usada para criar diagramas da sua implementação. Esses diagramas úteis podem ser exportados para o Microsoft Office Visio®. Os diagramas são criados em tempo real pelo MOM, portanto, você pode criar uma versão atualizada em poucos segundos.
Nas Exibições de Diagrama do MOM 2005 Operator Console existem três diagramas do pacote de gerenciamento do Active Directory. O diagrama Objetos de Conexão Interrompidos (veja a Figura 5) mostrará todas as conexões que estejam em estado de erro. Esse diagrama pode estar em branco se não houver nenhum erro de conexão.
Figura 5 As conexões interrompidas estão realçadas na Exibição de diagrama.
Figura 5 As conexões interrompidas estão realçadas na Exibição de diagrama.
O diagrama Objetos de Conexão realça as conexões entre controladores de domínio. O diagrama Links de Sites mostra cada site do Active Directory, encapsulando os controladores de domínio apropriados nesse site e os links de site de conexão.
Como os diagramas criados pelo MOM para essas exibições são dinâmicos, você pode exportá-los para o Visio para editá-los e personalizá-los facilmente. Por exemplo, a Figura 6 mostra o diagrama Links de Sites sendo editado no Visio.
Figura 6 Editando um diagrama Links de Sites no Visio
Figura 6 Editando um diagrama Links de Sites no Visio (Clique na imagem para diminuir a exibição)
Figura 6 Editando um diagrama Links de Sites no Visio
Figura 6 Editando um diagrama Links de Sites no Visio (Clique na imagem para aumentar a exibição)
A Figura 7lista os relatórios disponíveis no pacote de gerenciamento do Active Directory. Os grupos de computadores associados a esse pacote de gerenciamento são mostrados na Figura 8. Como se pode observar, os grupos de computadores do Active Directory são preenchidos pela associação explícita. Os grupos de computadores do Windows são preenchidos de acordo com a versão do sistema operacional e se a máquina for um controlador de domínio.
Figure 8 Grupos de computadores (Close Figure 8)

Monitoramento do lado cliente do Active Directory
Dados da latência de replicação do Active Directory
Coleção - fontes
Dados da latência de replicação do Active Directory
Coleção - destinos
Monitoramento de confiança do Active Directory
Controladores de domínio do Windows 2000 Server
Controladores de domínio do Windows Server 2003
Figure 7 Relatórios do Active Directory (Close Figure 7)

Controlador de domínio do AD
Execução de função do AD
Objetos de conexão para replicação do AD
Links de sites para replicação do AD
Espaço em disco do controlador de domínio do AD
Alterações de domínio do AD
Falhas de autenticação de conta da máquina do AD
Largura de banda de replicação do AD
Latência de replicação do AD
O pacote de gerenciamento do Active Directory pode ser configurado para baixo privilégio nos controladores de domínio do Windows Server 2003. O pacote de gerenciamento não oferece suporte ao monitoramento sem agente. No Windows 2000 Server, a Conta de Ação agente deve estar no grupo Admins. do Domínio ou Administradores local. A Conta de Ação agente nos controladores de domínio do Windows Server 2003 deve ter permissões adicionais para ser configurada para baixo privilégio, incluindo associação nos grupos Usuários e Usuários de Monitor de Desempenho, acesso aos Logs de Eventos e os privilégios SeSecurityPrivilege, SeAuditPrivilege e SeInteractiveLogonRight. Além disso, o seguinte acesso é requerido: acesso completo ao Contêiner CN=MomLatencyMonitors no Active Directory para monitoração da replicação, acesso de leitura aos diretórios que contêm o banco de dados NTDS.dit e arquivos de log, bem como acesso de leitura à seguinte chave do Registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
Se você estiver monitorando confianças no Windows Server 2003, observe que o script AD Monitor Trusts requer que a Conta de Ação agente tenha associação de grupo Admin. do Domínio ou Administradores.
O download do pacote de gerenciamento do Active Directory pode ser feito em go.microsoft.com/fwlink/?LinkId=79540.

Personalizando o MOM para o Active Directory
O pacote de gerenciamento do Active Directory deve ser configurado, do contrário os alertas manterão seu console cheio. O momento de mais ruído para o pacote de gerenciamento do Active Directory ocorre quando um controlador de domínio é reiniciado – todos os alertas possíveis parecem ter sido disparados. A má noticia é que não é fácil fazê-los parar. O melhor que você tem a fazer é utilizar o Modo de Manutenção do MOM para controlar os alertas durante as janelas de manutenção antecipada. A finalidade do Modo de Manutenção é resolver automaticamente os alertas dos controladores de domínio, de modo que o console não será preenchido.
Certifique-se de configurar o grupo Active Directory Client Side Monitoring, colocando os computadores cliente e os servidores apropriados dentro do grupo. As regras associadas a esse grupo ajudarão a determinar a integridade dos seus FSMOs e a conectividade com eles.
Existem regras de desempenho que usam limites de ligação com os FSMOs, por meio de LDAP, PING e DNS para verificar a conectividade. Essas regras estão localizadas nas regras de desempenho de Disponibilidade do Active Directory. Você deve personalizar os limites usados por essas regras, configurando a severidade do alerta. Por exemplo, as ligações FSMO usam valores de atributos que estejam em segundos. As regras de desempenho em relação a cada uma das funções FSMO usam essa metodologia de criação de alerta.
É importante entender como funcionam as configurações de Cálculo de Severidade de Alerta da Regra de Estado. A caixa de dialogo usa as condições If-Else do valor de atributo e configura a severidade do alerta adequadamente (veja a Figura 9). Quando a regra coleta o contador de desempenho da Última Ligação,criado pelo script AD Op Master Response, ela os verifica com os limites condicionais configurados por essas regras. É necessário configurar esses níveis de alerta diferentes para o seu ambiente.
Figura 9 Configurando regras de severidade de alerta
Figura 9 Configurando regras de severidade de alerta (Clique na imagem para diminuir a exibição)
Figura 9 Configurando regras de severidade de alerta
Figura 9 Configurando regras de severidade de alerta (Clique na imagem para aumentar a exibição)
Lembre-se do agendamento da replicação de cada controlador de domínio. Se um determinado controlador de domínio tiver um agendamento diferente dos demais, ele distorcerá os resultados de latência da replicação e fará com que você configure limites mais altos. Você precisará configurar os parâmetros dos scripts de replicação para se adequar às necessidades do seu ambiente específico. É importante observar que, quando algum controlador de domínio estiver inativo ou com problemas de replicação, todos os demais controladores de domínio desse grupo poderão reportar uma falha de replicação desse controlador de domínio, mesmo que não seja um parceiro de replicação direto. Portanto, ainda que você coloque o controlador de domínio problemático no Modo de Manutenção, os demais controladores de domínio podem reportar falhas de replicação.
A monitoração da replicação é onde você deve gastar a maioria do seu esforço no ajuste do pacote de gerenciamento do Active Directory. Você precisará executar o pacote de gerenciamento no seu ambiente por duas semanas, para observar de que modo ele emite alertas. Quando você observar algumas tendências se desenvolvendo, use os relatórios para descrever as latências e ajustar os limites adequadamente.
Finalmente, aproveite as orientações fornecidas em Alert Tuning Solution Accelerator.

Olhando para o futuro
O MOM 2005 e o pacote de gerenciamento do Active Directory permitem que você monitore de maneira eficiente e eficaz a implementação do Active Directory em sua organização. Com os pacotes de gerenciamento do Active Directory, DHCP, DNS, FRS e Windows Server Base OS, você será capaz de monitorar a maioria dos aspectos de sua infra-estrutura, protegendo a integridade e o bem estar da infra-estrutura do Active Directory e, também, dos seus usuários. Usando os dados coletados no relatório do data warehouse, você pode analisar o desempenho e os dados de evento para auxiliá-lo no planejamento de capacidade e na tendência de desempenho.
Para encontrar os pacotes de gerenciamento abordados neste artigo, juntamente com vários outros, veja o Management Pack Catalog (Catálogo de pacotes de gerenciamento).
A próxima atualização do pacote de gerenciamento do Active Directory conterá a coleção usual de correções e ajustes para alguns limites. Mais interessantes são os novos recursos planejados para a próxima versão do produto, conhecida como System Center Operations Manager 2007, que inclui a capacidade de monitorar várias florestas de um único grupo de configuração para definir grupos de controladores de domínio (cada um com a sua própria latência de replicação esperada entre outros grupos) e monitorar controladores de domínio executados na próxima versão do Windows Server. Passe no site do MOM em Microsoft.com/mom para saber detalhes.

John Hanntrabalha com o MOM desde a versão 2000 e é MVP do MOM desde 2004. John contribui para MyITForum.com, MOMCommunity.com, e LearnMOM.com. Você pode entrar em contato com ele pelo blog.


 Administra&#231;&#227;o do Windows: Jogando em um ambiente seguro
Administração do Windows Matt Clapham

Jogando em um ambiente seguro
Visão geral:
  • Gravando em chaves do Registro e pastas protegidas
  • Falhas de proteção contra cópia
  • Problemas de Firewall
  • Problemas com clientes corporativos

De dia, trabalho como gerente do programa de segurança na Microsoft. Também escrevo freqüentemente sobre segurança para a TechNet Magazine. Não é necessário dizer que levo segurança muito a sério. Mas também tenho outros
interesses. Nas horas vagas, adoro jogar jogos baseados no Windows®. Gosto especialmente de jogos de atiradores em primeira pessoa, simuladores, RPG e estratégia em tempo real. Entretanto, há um problema. Como meus amigos Jesper Johansson e Aaron Margosis, eu me recuso a executar com privilégio administrativo, a exceto quando absolutamente necessário. Faço isso em parte para garantir que vou obter apenas 0wnd3d em um jogo de rede devido à minha falta de habilidade, e não como resultado de alguém me bombardear com um rootkit para retardar a minha mira (consulte Quake 3 Buffer Overflow Advisory, listado na barra lateral "Recursos").
Meu entusiasmo a esse respeito é tão grande que, com freqüência, não consigo jogar um título novo e interessante (consulte a Figura 1). Se não consigo executar o jogo com minha Conta de Usuário Limitada (LUA) em um cliente associado a um domínio do Small Business Server (SBS) após instalá-lo e atualizá-lo em uma conta de administrador, eu o removo no mesmo instante. Não há desculpa para esse tipo de engenharia deficiente e não me faltam opções de jogos. Admito que minha posição possa parecer radical, mas sou inflexível nesse ponto. Mesmo assim, não sou contra abrir mão de alguns pontos fracos de menor importância em prol de algum tempo de jogo de qualidade, e é sobre isso que tratarei aqui. Assim, permita-me compartilhar alguns dos problemas relacionados a jogos com que me deparei e as soluções que descobri serem eficazes. Para obter um resumo rápido das práticas recomendadas, dê uma olhada na barra lateral"Tips for Gaming as a Limited User".
Figura 1 Problemas de acesso ao arquivo na execução da atualização manual
Figura 1 Problemas de acesso ao arquivo na execução da atualização manual (Clique na imagem para diminuir a exibição)
Figura 1 Problemas de acesso ao arquivo na execução da atualização manual
Figura 1 Problemas de acesso ao arquivo na execução da atualização manual (Clique na imagem para aumentar a exibição)

Problemas comuns
Esse problema de privilégio não é novidade. Existem inúmeros jogos e outros tipos de programas que requerem privilégio administrativo para serem executados corretamente. Dê uma olhada no artigo da Base de Dados de Conhecimento "Certain Programs Do Not Work Correctly if You Log On Using a Limited User Account" ("Determinados programas não funcionam corretamente se você fizer logon usando uma conta de usuário limitada" (consulte support.microsoft.com/kb/307091). O artigo lista aproximadamente 200 jogos e aplicativos que experimentam dificuldades quando executados por um usuário limitado, incluindo alguns programas da Microsoft.
Quero deixar claro que não considero um problema a necessidade de privilégio administrativo para instalar ou atualizar (manualmente) um jogo. Isso geralmente é requerido até termos a habilidade de realizar a rotina de instalações por usuário no Windows. Esse dia vai chegar em breve, mas ainda não estamos lá. Entretanto, depois que um jogo é instalado e atualizado, ele tem que estar pronto para ser jogado por qualquer usuário do sistema, até por alguém que tenha apenas privilégio limitado.
Tentando gravar em chaves do Registro e pastas protegidas O único problema mais comum que observei é quando ocorre falha na inicialização ou durante o jogo, porque ele tenta gravar em chaves do Registro ou em pastas protegidas (comum em muitos aplicativos baseados no Windows). Por padrão, apenas administradores (e os Usuários avançados preteridos) podem gravar em certas pastas (como %PROGRAMFILES%) e em hives do Registro (como HKEY_LOCAL_MACHINE). Os erros decorrentes podem ser relativamente óbvios: "Erro 42: Não foi possível gravar arquivos de log em C:\Program Files\CoolGamesInc\NewestFPS\Logs\" ou "Jogo não instalado corretamente, reinstale e reinicie." Também já vi exemplos em jogo médio, como mensagens de erro exibidas quando salvo meu progresso. Às vezes os criadores de jogos ao menos alertam o usuário de que o jogo necessita de privilégio administrativo, no momento, para funcionar, que foi o que experimentei com o Age of Mythology®. Os MMOGs (jogos online com grande quantidade de participantes) muitas vezes esbarram em problemas de privilégio, pois freqüentemente atualizam a si próprios e o ângulo de auto-atualização é um pouco mais complicado de se resolver tecnologicamente. Quando executei a versão de avaliação do EVE Online, percebi que ela saiu prejudicada não apenas com a colocação arquivos de log em locais inadequados, mas também com a tentativa de auto-atualização dos dados de conteúdo do jogo na pasta de instalação.
Falhas na proteção contra cópia O segundo motivo mais comum que observei em jogos com falha na inicialização é quando a proteção interna contra cópia do jogo (ou outro recurso antipirataria) não funciona com um usuário limitado. Pode ser que o driver não tenha sido iniciado corretamente ou que algum serviço de segundo plano não esteja sendo executado. A representação mais comum que já vi para esse problema é o jogo solicitar que o usuário insira um disco, mesmo quando a mídia solicitada já está na unidade. Também já vi jogos afirmarem que os privilégios de administrador são necessários, na crença ilegítima de que apenas administradores podem executar adequadamente a verificação de proteção contra cópia. Os piores casos apresentam uma mensagem de erro absurda e malformada sem nenhuma referência no site de suporte do jogo.
Falha na solicitação de exceção do firewall Jogos com vários participantes que podem ser jogados em uma rede local ou na Internet são muito comuns, e o Windows XP Service Pack 2 (SP2) adicionou uma mensagem de aviso que informa ao usuário quando os aplicativos estão tentando escutar a rede. Isso me traz ao próximo problema comum que observei: jogos que precisam de uma exceção de firewall, mas não solicitam a adição dessa exceção na hora da configuração. Como usuários limitados não podem alterar a configuração do firewall, esse aviso (veja a Figura 2) não pode ser solucionado sem o trabalho de configuração de um administrador. Pior ainda, algumas vezes o problema não é óbvio, uma vez que o aviso aparece no shell do Windows e não na interface do jogo. Na verdade, normalmente eu nem vejo a mensagem de erro até sair do jogo.
Figura 2 Quando as configurações do firewall acabam com a diversão
Figura 2 Quando as configurações do firewall acabam com a diversão (Clique na imagem para diminuir a exibição)
Figura 2 Quando as configurações do firewall acabam com a diversão
Figura 2 Quando as configurações do firewall acabam com a diversão (Clique na imagem para aumentar a exibição)
Problemas com clientes corporativos Encontrei outro problema não relacionado diretamente à execução como usuário limitado, mas que, apesar disso, vale ser discutido. Executo meu ambiente de computação doméstico como uma pequena empresa (não entrarei em detalhes, mas você poderá ler sobre isso neste artigo"Master Your Domain (Controle seu Domínio): Build a Corporate Network at Home (Construa uma rede corporativa em casa)", que eu e Jesper Johansson escrevemos em outubro de 2006 para uma matéria da TechNet Magazine. Usando o SBS 2003 (R2), configurei um domínio completo do Windows com uma pasta Meus Documentos que é redirecionada para um compartilhamento de servidor. Foi desta forma que descobri os problemas mais comuns de que iremos tratar: jogos que não conseguem lidar com clientes corporativos.
Observei um empecilho duplo no Age of Empires® III (AoE3). Para crédito da equipe de desenvolvimento, o jogo inicia e funciona adequadamente como usuário limitado. Contudo, percebi que os cenários eram carregados lentamente, devido à grande quantidade de dados de log que eram gravados na rede. Além disso, o AoE3 perdeu minhas configurações, meus jogos salvos e o progresso, sempre que eu saia do jogo. Os arquivos estavam nitidamente na pasta Meus Documentos, mas o jogo simplesmente não os carregava. Isso foi uma verdadeira decepção, especialmente considerando-se o quanto mais o AoE3 se tornou amigável ao LUA, comparado aos títulos anteriores da série.
Vi um jogo que pelo menos reconhece esses problemas de clientes corporativos. Quando tentei o Fable®: The Lost Chapters™, o jogo foi suficiente para eu saber que as pastas remotas Meus Documentos não tinham suporte e, depois, saí do jogo normalmente. Elogio a equipe de desenvolvimento por reconhecer um cenário sem suporte e rejeitá-lo. Entretanto, pareceu-me um tanto estranho que o jogo saísse dessa forma para interromper o usuário, considerando-se que ele colocaria apenas alguns megabytes de dados na pasta Meus Documentos.

Soluções simples
Passei por esses problemas várias vezes, em mais jogos do que consigo lembrar. Felizmente, a maioria desses problemas possui soluções alternativas convenientes. Minha solução favorita é descartar o jogo de uma vez e mudar para um título do mesmo gênero compatível com o LUA, mas de um outro editor. Mais uma vez, isso parece um pouco radical. E não se trata de uma solução ideal, já que gastei 60 dólares em um novo título e não posso devolvê-lo, porque a caixa já está aberta. Vejamos então algumas maneiras de corrigir os jogos que eu já possuo.Dicas para jogar como usuário limitado
  • Atualize para o Windows Vista.
  • Tente a demonstração antes de comprar. Ela provavelmente apresentará todos os problemas de LUA que a versão completa tem.
  • Confira a lista de programas conhecidos por apresentarem problemas, executados em uma LUA ().
  • Procure os jogos que levam o logotipo Designed for Windows.
  • Atualize o jogo após a instalação e antes de executá-lo como usuário limitado.
  • Quando encontrar um jogo que não funcione como usuário limitado, informe sua preocupação ao editor e ao suporte técnico da empresa.
  • Se for necessário, use uma conta de usuário avançado local do sistema.

Solucionando problemas de proteção contra cópia Primeiro, vamos atacar o problema do driver de proteção contra cópia. Os sistemas de proteção contra cópia chegaram para ficar, mas isso não quer dizer que eles devam impedir os não-administradores de executar jogos! A maioria dos jogos usa o mecanismo SafeDisc de proteção contra cópia, da Macrovision; esse mecanismo instala um driver que verifica a existência de um disco de jogo original. Por padrão, o driver está configurado para iniciar por demanda (uma função limitada não permitida a usuários limitados). A Microsoft e a Macrovision distribuíram correções, mas eu encontrei outra solução alternativa:
  1. Abra o Gerenciador de Dispositivos usando uma conta de administrador.
  2. Vá até o menu Exibir e selecione Mostrar dispositivos ocultos.
  3. Expanda o nó dos drivers que não são plug and play.
  4. Abra as propriedades do driver Segurança ou SecDrv (consulte a
    Figura 3 Permitindo que a proteção contra cópia seja executada adequadamente (Clique na imagem para diminuir a exibição)
Figura 3 Permitindo que a proteção contra cópia seja executada adequadamente
Figura 3 Permitindo que a proteção contra cópia seja executada adequadamente (Clique na imagem para aumentar a exibição)
Como o driver agora tem início juntamente com o computador, ele já estará pronto quando o usuário inserir o disco para executar o jogo.
Solucionando problemas de acesso ao sistema de arquivos e ao Registro A suposição de que o acesso irrestrito a qualquer parte do sistema de arquivos ou do Registro é um problema comum em muitos programas herdados e atuais, não apenas em jogos. O artigo de Aaron Margosis"Problems of Privilege: Find and Fix LUA Bugs ("Problemas de privilégio: localize e corrija bugs de LUA" aprofunda-se nos detalhes de soluções dos diversos problemas que levam à necessidade de privilégios de administrador.
Problemas de acesso são um pouco difíceis de se rastrear, mas assim que o conjunto de requisitos de arquivos, pastas e chaves do Registro são assimilados, torna-se bastante óbvia a flexibilização das ACLs (listas de controle de acesso) para permitir que os usuários limitados participem do jogo. Tive sucesso total com o seguinte método:
  1. Obtenha as versões mais recentes de Filemon e Regmon em microsoft.com/technet/sysinternals.
  2. Execute as ferramentas como administrador e faça com que comecem a coleta dos logs.
  3. Jogue por alguns minutos como administrador, executando a maioria das tarefas comuns (start a new campaign, save a game, host a network game e assim por diante).
  4. Filtre os resultados de Filemon e Regmon para focar nos acessos do jogo que está sendo testado.
  5. Flexibilize as ACLs conforme necessário nas pastas e chaves do Registro em questão.
  6. Execute o jogo como não-administrador, para verificar se ele funciona agora.
Uma advertência sobre flexibilizar as ACLs: não as abra amplamente (por exemplo: Everyone£Full Control) nem em um nível muito alto (como HKEY_CLASSES_ROOT). Também é melhor evitar alterar qualquer permissão em pastas de sistema, como %SYSTEMROOT% e %PROGRAMFILES%, para evitar expor o Windows completamente ou deixar o sistema sem segurança.
Outra solução alternativa em potencial é executar o jogo como Usuário Avançado local do sistema. Esta não é a minha primeira opção, mas, ao usar uma conta que seja local para esse sistema, o escopo do impacto pelo menos se limita a uma única estação de trabalho, caso algo saia errado. Descobri que essa solução funciona para a maioria dos jogos que parecem só funcionar adequadamente como administrador.
Eu mesmo considero que executar um jogo rapidamente como administrador é um modo prático de tê-lo auto-atualizado. Normalmente executo o jogo como administrador, invoco a opção de atualização respectiva e saio do jogo; então, retorno à minha conta de usuário limitado para jogar de verdade. (Vale a pena mencionar que o Windows Vista™ permite que usuários limitados atualizem os aplicativos, supondo que o patch seja assinado pelo editor original.)
O Windows Vista também ajuda jogos e outros aplicativos a lidar com problemas de arquivo e acesso do Registro. Por padrão, programas executados por usuários limitados têm correções de virtualização ativadas que redirecionam os acessos equivocados de arquivo e do Registro para um cachê de usuário específico. Vi jogos projetados para a era Windows 9x, (The Neverhood, por exemplo) que não são executados corretamente noWindows XP (devido a problemas de permissão) funcionarem no Windows Vista com as correções padrão. Estou ansioso para testar outros jogos problemáticos no Windows Vista, mas desconfio que terei dificuldades em encontrar um jogo que o Windows Vista não possa corrigir adequadamente.
Solucionando problemas de firewall Os problemas de firewall são melhor solucionados na primeira instalação do jogo. No entanto, quando a configuração do jogo não é inteligente o suficiente para solicitar e configurar os ajustes de firewall necessários, eis um método que eu encontrei e que funciona bem:
  1. Faça logon como administrador.
  2. Abra o Painel de Controle do Firewall do Windows.
  3. Escolha adicionar um programa à lista de exceções do firewall.
  4. Selecione o jogo na lista ou procure pelo executável do jogo quando for solicitado.
Adicione o executável do jogo à exceção do firewall. Asseguro que o jogo terá permissão de acesso a toda e qualquer porta necessária para que ele funcione corretamente. Resultado: massacre!
Solucionando problemas com clientes corporativos Os problemas que os jogos encontram em clientes corporativos desaparecerão na hora. O número de computadores domésticos com banda larga está aumentando e existe uma comunidade crescente de usuários que executam o SBS em casa. Por enquanto, contudo, uma solução é ainda necessária.
No meu caso especificamente, descobri que um LUA local de sistema contornou o problema de redirecionamento da pasta Meus Documentos. O Age of Empires III e o Fable: The Lost Chapters funcionam muito bem como usuário limitado, desde que a pasta Meus Documentos não seja redirecionada para uma pasta de rede. Recursos
  • Quake 3 Buffer Overflow Advisory
  • Windows Vista Application Development Requirements for User Account Control Compatibility
  • Applying the Principle of Least Privilege to User Accounts on Windows XP
  • Aaron Margosis’ LUA Buglight tool
  • Standard User Analyzer
  • Master Your Own Domain: (“Controle seu domínio:) Build a Corporate Network at Home (construa uma rede corporativa em casa”)
  • Problems of Privilege: (Problemas de privilégio:) Find and Fix LUA Bugs (“Localize e corrija bugs de LUA”)
  • Certain Programs Do Not Work Correctly if You Log On Using a Limited User Account ("Determinados programas não funcionam corretamente se você fizer logon usando uma conta de usuário limitada")

Conclusão
Recomendo enfaticamente a execução como usuário limitado, assim você poderá aproveitar os benefícios associados à não execução como administrador. Nem sempre é fácil jogar em um mundo corporativo e de privilégios mínimos, mas isso está longe de ser impossível. Ao longo dos anos eu encontrei muitos jogos de todos os gêneros que funcionavam corretamente como usuário limitado. Encontrei também algumas soluções que fazem muitos outros títulos funcionarem. Enquanto isso, com a virtualização do Windows Vista, os jogos impossíveis de serem jogados como usuário limitado no Windows XP, voltaram a funcionar.

Matt Clapham, gerente do programa de segurança da Microsoft, é participante ativo da comunidade Segurança de TI de Seattle e membro da equipe de gerenciamento de risco em um projeto de TI em incubação.


 Do Editor: Nos bastidores
Do Editor
Nos bastidores

WINDOWS VISTA ESTÁ AJUSTADO para ter um grande impacto em departamentos de TI corporativos em 2007. Como informado na InformationWeek, um relatório IDC recente estima a criação de 100.000 empregos de TI nos Estados Unidos este ano, como resultado direto da "repercussão" do Windows Vista. Cerca de 90 milhões de novos computadores em todo o mundo virão com o Windows Vista instalado este ano e, até o ano que vem, 80 por cento dos novos computadores fornecidos para empresas terão o Windows Vista pré-instalado. Enquanto isso, você precisa decidir se é hora de implantar o sistema operacional em sua organização. Nós podemos ajuda-lo.
A edição deste mês da TechNet Magazine dá início a uma série que analisará em profundidade o que faz o Windows Vista funcionar: o kernel. É verdade, o Windows Vista tem alguns novos recursos interessantes para a experiência do usuário, mas se esse fosse o motivo principal para migrar, seriamos cautelosos. O kernel representa o coração do sistema operacional, e há aprimoramentos significativos na forma como o kernel do Windows Vista funciona.
Quem mais indicado para escrever sobre essas alterações do que Mark Russinovich, que conhece mais do kernel do Windows do que qualquer um na face da terra? O livro Windows Internals, de Mark em co-autoria com David Solomon, tornou-se o principal recurso para qualquer um que esteja procurando entender o que está acontecendo nos bastidores.
Este mês, Mark nos conta sobre as melhorias na alocação de CPU, que tornará os aplicativos da área de trabalho mais responsivos, e descreve como o Windows Vista aumenta o desempenho de multimídia no nível do kernel. O artigo também analisa alterações importantes no modelo de E/S do Windows Vista, incluindo links simbólicos baseados em arquivo, a nova capacidade de cancelar operações de E/S síncronas (a principal alteração, na minha opinião), além do conceito de prioridade de E/S. Lembre-se de ler o artigo completo de Mark quando avaliar o Windows Vista para a sua empresa.
É claro, ainda existem as tarefas diárias a percorrer e nós também podemos ajudar nesse sentido. Esta edição aborda muito do território da administração do Windows, com artigos sobre delegação de autoridade no Active Directory, novos modelos de Diretiva de Grupo no Windows Vista, solução de problemas de Diretiva de Grupo e monitoramento do Active Directory com o MOM.
Por fim, se você gosta de jogos e de se manter seguro, desejará dar uma olhada em nosso recurso sobre jogos em um ambiente seguro. Você sabe o que eles dizem sobre só trabalho e nenhum jogo. - JOSHUA TRUPIN

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Matt Ayers, Eugene Bak, Vijay Bharadwaj, Michael Fortin, David Hicks, Khushru Irani, Mehmet Iyigun, Arun Kishan, Mark Lawrence, Pavel Lebedynskiy, Ben Mickle, Michael Murgolo, John Orefice, Ravisankar Pudipeddi, Jeffrey Richter, David Solomon, Jim Truher, Landy Wang e Andy Zeigler.


 Caixa de Ferramentas: Novos produtos para os profissionais de TI
Caixa de Ferramentas
Novos produtos para os profissionais de TI
Greg Steen

Mova seus dados
SQL Examiner Bundle
www.sqlaccessories.com
Seja qual for a sua função em uma organização: administrador de banco de dados, desenvolvedor, especialista operacional ou um curinga, se você trabalha com o SQL Server™, provavelmente precisou mover dados entre ambientes e assegurar que a integridade desses dados e das estruturas de dados permanecesse intacta. Naturalmente, o SQL Server tem muitos recursos internos de replicação e sincronização, mas se você estiver verificado se o seu banco de dados de QA corresponde exatamente ao banco de dados de desenvolvimento, uma ferramenta como o SQL Examiner Bundle, da TulaSoft, pode ser inestimável, economizando tempo e esforços.
Com alguns cliques do mouse, o aplicativo pode detectar discrepâncias na estrutura do banco de dados ou nos próprios dados entre duas instâncias de bancos de dados. Basta apontar o aplicativo para os bancos de dados que você deseja verificar, e continuar. Como o nome sugere, o SQL Examiner Bundle agrupa dois aplicativos: SQL Examiner e SQL Data Examiner. O SQL Examiner analisa a estrutura dos seus bancos de dados e o SQL Data Examiner analisa todos os dados e realça as diferenças.
O SQL Examiner irá analisar e comparar tudo nas instâncias de bancos, desdetabelas e procedimentos armazenados a catálogos de texto completo e coleções de esquema XML. Para aqueles que utilizam o SQL Server 2005, também é possível comparar assemblies CLR (Common Language Runtime). Depois que você compara os bancos de dados, o SQL Examiner permite escolher que objetos de banco de dados devem ser sincronizados, bem como a direção da sincronização.
Analise e compare bancos de dados com o SQL Examiner
Analise e compare bancos de dados com o SQL Examiner (Clique na imagem para diminuir a exibição)
Analise e compare bancos de dados com o SQL Examiner
Analise e compare bancos de dados com o SQL Examiner (Clique na imagem para aumentar a exibição)
Um recurso realmente interessante é que o aplicativo gera o script SQL que cria um objeto e realça a diferença nesse script gerado entre os seus bancos de dados. Trata-se de uma excelente maneira de realçar erros depois que um script de criação ou um script de migração apresenta falha ao criar a estrutura do seu banco de dados de destino. ("Ah...foi aqui que eu deixei de fora o meu índice agrupado!") Você pode executar os scripts gerados individualmente, salvar esses scripts para executar posteriormente ou apenas clicar no botão Sincronizar e deixar que o aplicativo faça todo o trabalho por você.
Outro recurso interessante é a opção de adicionar exclusões à comparação, por exemplo: ignorar comentários, disparadores, índices ou propriedades estendidas de um objeto. Após analisar a comparação da estrutura, o SQL Data Examiner permite examinar os dados e ver as discrepâncias. Você pode selecionar as tabelas que desejar comparar, além de selecionar as colunas dessas tabelas especificadas que devem ser comparadas. Após concluir a comparação das tabelas de dados, você poderá ver quais as linhas idênticas e quais as linhas diferentes, bem como as linhas que residem em apenas um ou outro banco de dados.
Como ocorre com o SQL Examiner, o SQL Data Examiner permite clicar em um botão para sincronizar as tabelas, ou escolher de forma seletiva os dados que devem ser transferidos, além da direção dessa transferência. Os dois aplicativos permitem salvar a sua configuração como um projeto, para que você não tenha que recriar as tarefas a cada vez. Cada aplicativo pode ser adquirido separadamente, mas, com base em minha experiência, aposto que você desejará os dois.
Preço: U$ 299,95 por licença de usuário.

Procurar por arquivos duplicados
zsDuplicateHunter (Professional Edition)
Zizasoft
Se você está envolvido em gerenciamento de desktop, sem dúvida já se deparou com o usuário que “ficou sem espaço" na máquina. Uma investigação revela que ele copiava os respectivos documentos toda vez que fazia uma edição, embora vocês disponham de um sistema NAS (Armazenamento Conectado à Rede) com cópia de backup em sua base de usuários para armazenar arquivos. Ou, vocês têm um servidor de log com processos em lotes que trataram de duplicar logs imensos, tomando todo o espaço alocado do servidor. Uma solução possível para esses problemas é o DuplicateHunter Professional Edition, um localizador duplicado baseado em Java, que pode ser executado no Windows®, no Linux, ou no Mac OS X.
O aplicativo permite pesquisar unidades, diretórios ou compartilhamentos de rede facilmente, além de detectar possíveis duplicatas. Indo além de comparações com o nome, o aplicativo permite que você agrupe arquivos por tamanho de arquivo, soma de comprovação de arquivo e até mesmo cálculo de síntese do arquivo, para garantir que os arquivos que você está limpando são de fato diferentes. Além disso, você não precisa excluir permanentemente as suas duplicatas. Como precaução, o aplicativo permite mover todas as duplicatas marcadas para uma pasta especificada.
Outro bom recurso é a opção "Keep Files in this Folder, Delete Duplicates Elsewhere", que permite que você selecione o seu diretório de origem limpo e apague todos os demais que possa haver no disco. Nos resultados da pesquisa, você também pode clicar duas vezes em qualquer arquivo para abri-lo com um visualizador de arquivos associado, classificar esses resultados e selecioná-los, para obter os resultados exatos de que necessita. Um bom recurso "profissional de TI" permite que você ajuste o quanto de memória o arquivo terá permissão para ocupar enquanto procura duplicatas. Como proteção adicional, também é possível desabilitar a pesquisa em arquivos ocultos ou do sistema, para garantir que você não venha a excluir nada que não deva ser excluído nem exclua nenhum arquivo que seja gerenciado pelo sistema operacional ou por outro aplicativo.
A Professional Edition também oferece um filtro granular de seus conjuntos de resultados da pesquisa, permitindo aplicar uma Expressão Regular para localizar os arquivos exatos que devem ser eliminados.
Preço: U$ 39,95 por licença de usuário.

Leve seus aplicativos com você
MojoPac
www.mojopac.com
Se você estiver viajando de ambiente em ambiente e sentir falta de seus aplicativos e configurações de área de trabalho favoritos, ou se, simplesmente, não gosta de deixar suas pegadas na área de trabalho de alguma pessoa, convém dar uma olhada no MojoPac, da RingCube Technologies.
Nomes tolos à parte, o MojoPac permite que você leve suas configurações e seus aplicativos para qualquer sistema Windows XP (Home, Professional, Media Center ou Tablet) em um dispositivo de mídia pessoal de unidade rígida USB, que pode ser conectado ao sistema host por USB 2.0, como um Zune ou iPod, ou mesmo um telefone celular com espaço de armazenamento suficiente. No momento em que escrevi este artigo, não havia suporte para hosts do Windows Vista™ e do Windows 2000, mas a documentação no site do produto informa que, em breve, uma atualização com suporte para esses sistemas operacionais estará disponível.
Leve suas configurações com o MojoPac
Leve suas configurações com o MojoPac (Clique na imagem para diminuir a exibição)
Leve suas configurações com o MojoPac
Leve suas configurações com o MojoPac (Clique na imagem para aumentar a exibição)
Atualmente, o MojoPac requer privilégios de Administrador no sistema host, mas a versão 2.0 em desenvolvimento terá suporte para modo de usuário limitado. A ferramenta basicamente executa a interferência entre o SO host e os dispositivos de armazenamento e, na primeira vez que você inicia após instalar o aplicativo no dispositivo portátil, o MojoPac dispara a conta inicial do Windows configurada para execução, definindo suas configurações pessoais para o MojoPac no dispositivo MojoPac.
Quando estiver em funcionamento, será fácil alternar entre o sistema host e o sistema Mojo: basta clicar na barra de ferramentas (que pode ser minimizada), no alto da tela. Você instala aplicativos no dispositivo Mojo como normalmente o faria, enquanto o MojoPAc estiver ativo. E, desde que você tenha dado importância à importante advertência nos documentos leiame sobre a instalação no diretório padrão, sua configuração estará pronta para funcionar.
Enfim, o MojoPac tem potencial para ser um excelente ativo para qualquer profissional de TI que se encontre em viagem e, ainda assim, deseje a sua própria configuração. Por exemplo, você pode ter todos os utilitários do seu sistema, farejadores de pacote e monitores de tráfego em seu MojoPac, e solucionar problemas em qualquer PC na organização, sem deixar pegadas atrás de si.
Preço: U$ 49,99 por licença de usuário.

Revisão do livro
Administrator’s Guide to SQL Server 2005
www.aw-bc.com
Cada vez mais grupos de TI estão percebendo a eficácia e a amplitude de funcionalidade oferecida pelo SQL Server 2005. Desde o amplo suporte a dados XML, até o SSIS (SQL Server Integration Services), o SQL Server 2005 Service Broker, o aplicativo adiciona milhares de aprimoramentos úteis. Para auxiliá-lo a resolver o seu próprio caminho de atualização ou a administrar a sua recém-lançada instância do SQL Server 2005, Buck Woody escreveu um excelente guia de referência: Administrator’s Guide to SQL Server 2005 (“Guia do Administrador para o SQL Server 2005”) (Addison-Wesley Professional, 2006).
O livro oferece uma visão geral de práticas de administração eficientes, conforme aplicadas à nova plataforma de servidor e, ao contrário de outras referências que encontramos por aí, faz isso de maneira concisa. O livro começa com uma seção sobre dimensionar corretamente a infra-estrutura para adequação às necessidades do seu aplicativo, além de um guia sobre a versão apropriada do SQL Server em cenários diversos. Aqui você também terá uma idéia de como arquitetar a sua infra-estrutura para ter a garantia de não terminar com gargalos de desempenho que podem ser evitados ao fazer a instalação.
O guia então parte para esboços das diferentes ferramentas fornecidas com o SQL Server, como o SQL Server Profiler aprimorado e o novo SQL Server Management Studio. Você também se aprofundará em tarefas de manutenção e automação e verá como pode se planejar para o crescimento com base na criação de perfil de servidor, além de como descobrir um plano de manutenção apropriado para a sua implementação.
No capítulo sobre segurança você também irá explorar como proteger a sua instalação, desde a rede e o hardware até o sistema operacional e a instância do SQL Server. Aqui, igualmente, você dará uma espiada nos serviços adicionados de criptografia, certificados e gerenciamento de chaves fornecidos pela nova plataforma.
Outro capítulo explica os mecanismos existentes para assegurar a alta disponibilidade do seu sistema, baseado em suas necessidades de implementação. Você investigará assuntos como agrupamento, espelhamento de banco de dados, replicação e envio de log como métodos de obtenção dos seus requisitos de duração. E, com a virtualização tornando-se uma excelente maneira de obter alta disponibilidade sem a sobrecarga de infra-estruturas fisicamente distintas, o livro oferece um guia passo-a-passo para configuração de um cluster de dois nós usando o Microsoft Virtual Server.
O capítulo sobre SSIS mostra como usar a nova ferramenta (adeus DTS!) não só para desenvolver e implantar funções ETL (extração, transformação e carga), mas também para mostrar como usar os serviços de criação de tarefas de monitoramento, notificação por email e backup.
Finalmente, os últimos capítulos se aprofundam no Reporting and Analysis Services, fornecido pela nova plataforma do SQL Server. Neles você terá contato com design e criação de relatório, gerenciamento de sistemas de relatório e o que está envolvido na manutenção da implantação de serviços de análise.
Enfim, o Administrator’s Guide to SQL Server 2005 é uma ótima maneira de se adaptar com a administração, o monitoramento e a atualização para o SQL Server 2005.
Preço: $49.99.


 Perguntas&amp;respostas do SQL: Tamanho do banco de dados, espelhamento, transa&#231;&#245;es marcadas e muito mais
Perguntas&respostas do SQL
Tamanho do banco de dados, espelhamento, transações marcadas e muito mais
Editado por Nancy Michell

Movendo um cluster
P. Preciso mover um cluster do SQL Server 2000 para novos endereços IP de ambos os servidores físicos abaixo dele, além do cluster do Windows® e do cluster do SQL Server™. Terei que recriar a solução inteira?
R. Não, tudo o que você tem a fazer é executar a instalação do SQL Server e modificar os endereços IP. Aqui está um artigo da Base de Dados de Conhecimento que explica como fazer isso.

Tamanho do banco de dados
P. Tenho o SQL Server 2000 SP4 em produção com um banco de dados essencial de quase 10 GB, um modelo de recuperação SIMPLES, um arquivo primário de 9,850 MB e um arquivo de log de transações de 88 MB. O backup do banco de dados também tem quase 10 GB. Devo reduzir o tamanho do banco de dados para obter um desempenho melhor? Em caso positivo, devo usar o DBCC SHRINKDATABASE ou o DBCC SHRINKFILE? (Infelizmente não tenho um horário fora do pico disponível para essa manutenção).
R. O DBCC SHRINKDATABASE ou o DBCC SHRINKFILE só ajudará se o banco de dados tiver muitas exclusões e atualizações que resultem em menor volume de dados. Mas a pergunta real é: o que isso importa? Um espaço de 10 GB em disco vale hoje, talvez, uns US$ 20. Não faria mais sentido adicionar outros 100 GB ou mais de espaço em disco e deixar executar? O desempenho ficará prejudicado conforme o espaço se tornar mais fragmentado, mas se você não puder fazer nenhuma manutenção, terá pouca opção. Às vezes as pessoas usam uma segunda cópia do banco de dados em situações como essa. Elas mantêm uma cópia de backup atualizada com replicação, fazem a manutenção da cópia de backup e, então, alternam os aplicativos para o backup. Isso obviamente requer algumas alterações ao código e à mudança do modelo de recuperação SIMPLES (para FULL ou BULK_LOGGED), mas pode ser uma boa solução de longo prazo.

Atualização e desempenho
P. Preciso mover dois aplicativos do SQL Server 2000 para o SQL Server 2005. Como posso evitar problemas de desempenho durante a atualização?
R. As armadilhas a seguir geralmente podem causar problemas de desempenho durante a atualização, portanto, procure evitá-las:
  1. Você não recriou as estatísticas depois de atualizar para o SQL Server 2005.
  2. Você tem cláusulas JOINS e WHERE que comparam dois tipos diferentes de dados, resultando em um desempenho ruim, sobretudo se o servidor havia executado o SQL Server 2000 SP3 ou anterior (consulte support.microsoft.com/kb/271566/).
  3. A instância do SQL Server 2005 não está configurada corretamente; a memória, as extensões AWE, os drivers etc estão configurados incorretamente. A caixa que executava o SQL Server 2000 foi ajustada, a pessoa que fez o ajuste saiu e não o documentou, portanto, ele não foi feito à instância do SQL Server 2005.
  4. O hardware está com defeito. Geralmente, um novo hardware é adquirido, porque parece bom no papel, mas isso não se mantém na prática.
Antes de colocar uma instância do SQL Server em produção, deve-se estabelecer uma linha de base de desempenho para confirmar se o desempenho esperado ocorrerá. Isso poderá, então, excluir a infra-estrutura como um possível problema. Você precisa observar os Contadores de desempenho, como Disco, E/S e memória, e compará-los entre instâncias.

Espelhamento do banco de dados
P. Estou usando espelhamento de banco de dados e desejo habilitar a opção de banco de dados READ_COMMITTED_SNAPSHOT. Quando tento habilitá-la depois que o espelhamento foi configurado, obtenho uma exceção informando que o banco de dados está em uma sessão de espelhamento e o comando não pode ser executado.
R. Isso acontece porque a configuração da opção READ_COMMITTED_SNAPSHOT requer que o banco de dados seja reiniciado para ter efeito. Você precisa, portanto, dividir a sessão de espelhamento, configurar a opção e reiniciar o banco de dados. Depois de concluir essas etapas, você poderá restabelecer o espelhamento. O banco de dados de espelhamento selecionará a opção depois que a sessão for restabelecida e a utilizará, se ocorrer failover.

P. Estou tentando configurar o espelhamento assíncrono mas obtenho o erro 1418. A execução do Netstat-ano mostra que o SQL Server está escutando na porta correta em todos os servidores. O erro é exibido quanto tento iniciar o espelhamento. O que pode estar acontecendo?
R. Uma possibilidade é o seu firewall estar bloqueando a comunicação; trata-se de um problema relativamente comum que você deverá investigar. Confira os seguintes white papers para obter ajuda: Troubleshooting Database Mirroring Setup (“Solucionando problemas de configuração de espelhamento de banco de dados”) e em MSSQLSERVER_1418.
Observe que esse problema não é específico do espelhamento assíncrono. Na verdade, ele pode ocorrer também com o espelhamento síncrono.
O erro que você está obtendo ("O endereço de rede do servidor "%.*ls" não pode ser acessado ou não existe. Verifique o nome do endereço de rede e envie o comando novamente") está correto. Geralmente, o que ocorre não é que o parceiro remoto não exista, mas que o parceiro remoto simplesmente não pode ser acessado.
Isso poderia acontecer se o parceiro remoto estivesse inoperante, não escutasse a porta ou mesmo se o ponto de extremidade estivesse inoperante (o que pode ocorrer se os parceiros não conseguirem negociar o mesmo mecanismo de criptografia ou se tiverem algum problema de autenticação). Também pode acontecer se o parceiro estiver bloqueado, o que pode ser o resultado do firewall no parceiro que inicia o comando.
Outros problemas que você poderia descartar incluem questões de DSN (nome da fonte de dados) e resolução de nomes. A recomendação genérica é usar nomes de domínio totalmente qualificados. Portanto, embora o seu firewall geralmente possa ser o problema, lembre-se de que existem muitas causas potenciais.

P. Quero usar o espelhamento do SQL Server 2005; entretanto, ouvi dizer que o espelhamento não é recomendado quando vários aplicativos conectam-se a vários bancos de dados na mesma instância do SQL Server. Está correto?
R. A resposta depende na verdade de cada aplicativo ter o seu próprio banco de dados ou de os aplicativos usarem transações em todos os bancos de dados ou transações DTC (Distributed Transaction Coordinator). Se forem usadas transações em todos os bancos de dados, o espelhamento poderá introduzir inconsistências lógicas nas quais as transações não são confirmadas como o esperado. Uma boa explicação sobre o que acontece nessas circunstâncias pode ser encontrada aqui.
Em uma situação de vários bancos de dados usados por vários aplicativos, onde cada aplicativo tem o próprio banco de dados, o espelhamento não causa esses problemas.

Transações marcadas
P. O que são exatamente Transações Marcadas? São alguma coisa que possa ser usada se um banco de dados for SQL Server e outro for Oracle?
R. Marcar uma transação é algo que o administrador de banco de dados faz periodicamente para colocar uma marca no mesmo local em todos os logs. Essa ação, combinada com a habilidade de restaurar uma tabela em uma marca de transação, permite que você restaure todos os bancos de dados ao mesmo ponto. Fazer isso pode ser muito doloroso porque você terá que restaurar todos os bancos de dados envolvidos e os dados serão perdidos em todos os bancos de dados, portanto, você deve evitar isso, assegurando-se de não perder os arquivos de log. As transações marcadas são específicas do SQL Server, assim, se suas transações distribuídas incluírem bancos de dados diferentes do SQL Server, elas não poderão participar da marcação de transação. Em geral, muito poucos sistemas de bancos de dados distribuídos usam marcas de transação. Eles só tratam a perda de um dos logs de transação quando um evento catastrófico requer muito trabalho manual para se recuperar.

Acesso à ferramenta de conversão T-SQL
P. Existe um ferramenta automatizada de conversão Access™-SQL para T-SQL disponível para procedimentos armazenados?
R. Tente o SSMA (Assistente de Migração do SQL Server) para Access que você pode baixar. Lá você também encontrará o Assistente de Migração do SQL Server para Oracle, o Assistente de Migração do SQL Server para Sysbase e o Migrating Informix Databases para Microsoft® SQL Server 2000.
Para fazer upsize do Access para o SQL Server, você pode usar o Assistente de Upsizing do Office; no entanto, o SSMA para Access, mostrado na Figura 1, tem mais recursos, incluindo relatórios de avaliação de conversão e verificação de rede. O SSMA para Access também corrige vários problemas não tratados corretamente pelo Assistente de Upsizing do Office.
Figura 1 Assistente de Migração do SQL Server para Access
Figura 1 Assistente de Migração do SQL Server para Access (Clique na imagem para diminuir a exibição)
Figura 1 Assistente de Migração do SQL Server para Access
Figura 1 Assistente de Migração do SQL Server para Access (Clique na imagem para aumentar a exibição)

Índices não agrupados
P. Tenho uma tabela em que a chave primária é feita de dois GUIDs (digamos, GUID1 e GUID2). Já tive meu índice agrupado exclusivo em GUID1 e GUID2. Agora, por motivos de desempenho, quero criar o segundo índice não agrupado em GUID2 e GUID1. Haverá alguma sobrecarga de desempenho se eu declarar o índice como exclusivo?
R. Não há nenhuma penalidade para o desempenho na declaração do índice não agrupado como exclusivo. Na verdade, fazer isso pode resultar em menos níveis na árvore de índice.
Quando um índice não agrupado é declarado como não exclusivo, o localizador de linha é anexado à parte de chave das entradas de índice, nas páginas raiz e não-folha. Isso é feito para facilitar a exclusão e atualizar as entradas de índice, o que evita a verificação de uma cadeia de sinônimos quando existirem duplicatas de uma chave: a entrada específica a ser alterada pode ser localizada por uma operação de pesquisa no sistema, relacionada à chave e ao localizador. Resultado: essas entradas são maiores (consideravelmente maiores com a chave do cluster que você escolheu). Como resultado, as páginas raiz e não-folha serão naturalmente lotadas de forma mais rápida. Se o índice for exclusivo, você deverá declará-lo como tal.
A questão é que, independentemente de a tabela ter um índice agrupado, qualquer índice não agrupado na tabela que não seja declarado como exclusivo terá o localizador anexado às entradas de índice nas páginas raiz e não-folha.
Além disso, se você usar uma coluna de identificador int como uma chave substituta e, em seguida, adicionar dois índices exclusivos (GUID1, GUID2) e (GUID2, GUID1), isso provavelmente melhorará o desempenho, pois os índices terão uma chave de cluster de 4 bytes, e não de 32 bytes.

Atualizar bloqueios
P. Tenho procedimentos armazenados com a seguinte estrutura:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
Esse procedimento permite que apenas um chamador assuma o bloqueio e faça todos os demais chamadores esperar. Posso obter o mesmo comportamento reduzindo o nível de isolamento?
Parece que READ COMMITTED é o nível de isolamento correto, pois essa transação tem apenas uma consulta e, se alguma outra transação estiver em processo de atualização do mesmo registro, essa transação aguardará a outra. Está correto?
R. Não é a configuração serializável no seu exemplo que faz outros chamadores aguardar, é a própria atualização. Sim, você pode configurar o isolamento em READ COMMITTED e a atualização naturalmente assumirá um bloqueio de atualização de qualquer índice que utilizar. Isso causará problemas a outros processos que estejam executando a mesma instrução; eles, portanto, serão bloqueados até a atualização estar concluída. (Você também não precisa da transação explícita aqui, se a atualização for a única instrução; cada instrução estará implicitamente na própria transação, se não se tratar de uma transação explícita).
Entretanto, se não houver linhas que correspondam à cláusula WHERE na instrução UPDATE, o uso do nível de isolamento serializável impediria que essas linhas fossem inseridas ou modificadas nas demais transações. Se você fosse executar o UPDATE em isolamento READ COMMITTED, isso não aconteceria, e outras transações estariam aptas a introduzir linhas que se qualificariam para a atualização. Se o código de procedimento armazenado for semelhante ao código que você mostrou, pode não fazer sentido empreender nenhuma dessas ações (serializável ou transação); basta executar a atualização

Meus agradecimentos aos seguintes profissionais de TI da Microsoft por seus conhecimentos técnicos: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip e Frankie Yuen.


 Destaque de utilit&#225;rio: Estoque de Diretiva de Grupo
Destaque de utilitário
Estoque de Diretiva de Grupo
Greg Steen
Faça download do código deste artigo: GPInventory.exe (150KB)

COMO VOCÊ sabe o que tem se não tem o controlo sobre isso? Ter os detalhes do estoque na ponta dos dedos pode economizar muita dor de cabeça quando reuniões de alocação de orçamento e auditorias anuais acontecem. E, naturalmente, as autoridades constituintes parecem sempre querer saber quem tem o que e por que, e o que é preciso fazer para realizar uma atualização importante.
Uma ferramenta que pode ajudá-lo em tudo isso é o Estoque de Diretiva de Grupo (GPInventory.exe), incluído no Windows Server® 2003 Resource Kit. Esse programa permite que você consulte e recupere informações do sistema com consultas RSOP (Diretiva de Conjunto de Usuário Resultante) e/ou WMI (Windows® Management Instrumentation) em vários hosts remotos, como mostra a figura. Não surpreende que o programa recupere facilmente as informações de Diretiva de Grupo, mas é também um meio eficaz de obter informações detalhadas do sistema, como, por exemplo, aplicativos que foram instalados, o nome e a velocidade do processador ou a lista de hotfixes instalados. Mas, espere, tem mais! Como faz parte do Windows Server 2003 Resource Kit, ela é 100% grátis.
Figura 1 Usando o GPInventory para reunir informações
Figura 1 Usando o GPInventory para reunir informações (Clique na imagem para diminuir a exibição)
Figura 1 Usando o GPInventory para reunir informações
Figura 1 Usando o GPInventory para reunir informações (Clique na imagem para aumentar a exibição)
Há muitas maneiras diferentes de colocar o GPInventory.exe em uso. Por exemplo, se você precisa verificar o status da garantia, pode coletar os números de série ou do serviço dos PCs na rede sem ter que to revirar toda caixa. Ou, se você tem um ambiente de laboratório e deseja ver se um computador está em uso no momento, é possível consultar os usuários conectados ao sistema nesse momento, sem ter que sair de sua cadeira. Se você tem uma configuração de servidor blade onde as imagens são varridas para os blades rotineiramente (para limpar e restaurar o ambiente de QA, por exemplo), você pode consultar a data de instalação do PC para verificar quando a última imagem foi aplicada.
O GPInventory também é bem fácil de usar. Aponte-o para um arquivo que tenha uma lista de computadores que você deseje relacionar em estoque, selecione as consultas a serem executadas e processe a lista. A ferramenta tenta se comunicar e conecta-se a cada computador da lista e consulta essa lista. Se você estiver fazendo uma consulta rápida, também poderá selecionar as máquinas de destino diretamente no Active Directory® e as ações de consulta a serem executadas no menu Consulta.
Para executar uma consulta RSOP em uma máquina, você precisará ter a permissão Gerar conjunto de diretivas resultante (log) (que administradores do domínio e administradores delegados têm, por padrão). Consultas WMI requerem direitos administrativos na máquina remota, exceto se você usa o snap-in WMI Control MMC para conceder direitos Habilitar Conta e Ativação Remota no namespace root\cimv2 para um usuário alternativo.
Após executar sua consulta, você pode salvar os resultados como um arquivo de texto separado por tabulações ou um XML. As duas variedades podem ser importadas para o Microsoft® Excel® para realizar uma análise. Você pode classificar e depois aplicar um filtro automático para localizar todos os detalhes.
O GPInventory também dá suporte à execução de linha de comando, assim, você pode facilmente configurar uma tarefa agendada para consulta às informações do sistema e salvá-la em um arquivo XML diretamente, sem intervenção da interface gráfica do usuário. Isso pode ser muito útil para consultas de longa execução, mais adequadas para execução em horários extraordinários.
A ferramenta vem com um conjunto padrão de consultas RSOP e WMI, mas você pode adicionar, editar e atualizar o arquivo de consulta com sua própria lista personalizada, se o que procura não estiver lá. O documento de ajuda incluído mostra como definir uma nova consulta no arquivo XML de lista de consultas.
O GPInventory.exe é uma ótima maneira de reunir informações sobre as máquinas com o Windows em execução na sua rede, seja para informações de estoque, diretiva de grupo ou de status. Você encontrará um link para o Estoque de Diretiva de Grupo na seção de downloads de nosso site.

Greg Steen é profissional de tecnologia, empresário e entusiasta. Ele está sempre buscando novos métodos e ferramentas para facilitar as operações e o desenvolvimento para os profissionais de TI.


 The Cable Guy: Suporte QoS no Windows
The Cable Guy
Suporte QoS no Windows
Joseph Davies
Este artigo se baseia, em parte, em uma versão de pré-lançamento do Windows Server “Longhorn.”. Todas as informações deste artigo estão sujeitas a alterações.

A QoS (Qualidade do Serviço) abrange um conjunto de tecnologias para gerenciamento de tráfego de rede de maneira econômica para aprimorar as experiências do usuário em ambientes domésticos e empresariais. As tecnologias de QoS permitem medir a largura de banda, detectar alterações nas condições de rede (como congestionamento ou disponibilidade de largura de banda)
e priorizar ou acelerar o tráfego. Por exemplo, a QoS pode ser aplicada para priorizar a entrega de tráfego sensível à latência (como aplicativos de vídeo ou voz) e para controlar o impacto do tráfego insensível à latência, como transferências de dados em massa. Fornecer entrega priorizada de tráfego TCP/IP requer suporte de dispositivos de infra-estrutura de rede e hosts. Esta coluna descreve os métodos para uso da QoS com os hosts baseados no Microsoft® Windows®.
O problema central de definir a QoS para as redes TCP/IP é como especificar e fornecer a entrega priorizada de tráfego IP. Embora o RFC 791 original de IP tenha definido o campo Tipo de Serviço (TOS) com a capacidade de especificar a precedência, o atraso, a taxa de transferência, a confiabilidade e as características de custo, o IP é basicamente uma tecnologia de melhor esforço de comutação de pacotes baseada em datagrama, que normalmente trata cada pacote da mesma forma e pelo método “first-come”, first-served”, ordem de preferência de chegada.

Configurando a entrega priorizada
Existem algumas coisas que você pode fazer para oferecer o serviço de entrega priorizada. Você pode configurar a infra-estrutura de rede para oferecer tratamento especial ao tráfego marcado e, então, fazer com que os hosts de envio marquem o respectivo tráfego de saída. Como alternativa, você pode fazer com que os hosts de envio programem dinamicamente a infra-estrutura da rede para oferecer tratamento especial baseado nas características do respectivo tráfego de saída (como endereços e números de porta).
Para o tráfego TCP/IP, você pode usar alguns métodos diferentes de oferecer a entrega priorizada. Por exemplo, na camada Interface de Rede para Ethernet, a marcação IEEE 802.1p marcará os quadros enviados por um host para entrega priorizada, usando um campo Prioridade de 3 bits no cabeçalho da VLAN (rede local virtual) do quadro Ethernet. O cabeçalho da VLAN é colocado dentro do cabeçalho Ethernet, entre o campo Endereço de Origem e o campo Comprimento (para um quadro IEEE 802.3) ou o campo EtherType (para um quadro Ethernet II)
Implementar a marcação 802.1p em um host de envio requer que o adaptador de rede e o driver de dispositivo ofereçam suporte à 802.1p e que o adaptador de rede tenha suporte habilitado para a 802.1p. Você pode habilitar normalmente o fornecimento de suporte à marcação 802.1p na guia Avançadas das propriedades de um driver de adaptador de rede. Os comutadores Ethernet também devem ter o suporte para a 802.1p habilitado.
Na camada Interface de Rede da IEEE802.11 sem fio, a certificação da Wi-Fi Alliance para o WMM (Multimídia Wi-Fi) define quatro categorias de acesso para priorização do tráfego de rede. Essas categorias de acesso são (em ordem de prioridade, da mais alta para a mais baixa): voz, vídeo, melhor esforço e segundo plano. O suporte de host para a priorização WMM requer que os adaptadores de rede sem fio e drivers respectivos dêem suporte ao WMM. Os APs (Pontos de acesso) sem fio devem ter o WMM habilitado.
Na camada de Internet, você pode usar os Serviços Diferenciados e configurar o valor do DSCP (Ponto de Código de Serviços Diferenciados) no cabeçalho IP. Como definido na RFC 2472, o valor DSCP é de 6 bits de ordem superior do campo TOS de IP versão 4 (IP4) e o campo Traffic Class de IP versão 6 (IPv6).
A maioria dos roteadores corporativos modernos dá suporte à diferenciação de tráfego DSCP, mas por padrão ela fica, normalmente, desabilitada. Durante o encaminhamento, os roteadores compatíveis com DSCP lêem o valor DSCP e colocam o pacote em uma fila específica. Por exemplo, você pode configurar seus roteadores para colocar os pacotes encaminhados em filas de alta prioridade, de melhor esforço ou de baixo esforço com base nos valores DSCP definidos. Mediante a configuração de filas e valores DSCP, o tráfego marcado para DSCP pode ter níveis de serviço diferenciados. Por exemplo, o tráfego de rede de missão crítica obtém preferência de encaminhamento e não é atrasado por outro tráfego de dados em massa de baixa prioridade. A especificação WMM define como o WMM acessa o mapa de categorias para valores DSCP. Um AP sem fio compatível com WMM lê o valor DSCP e administra o tráfego com base na categoria de acesso respectiva.
Na camada de Internet, você também pode usar o RSVP (Protocolo de Reserva de Recursos), um protocolo de sinalização definido na RFC 2205. Os hosts podem usar esse protocolo para tentar reservar largura de banda em uma rede para um ponto de extremidade. O RSVP, no entanto, não é implantado amplamente nas redes e atualmente não tem suporte no Windows XP, no Windows Server® 2003, no Windows Vista™ nem na próxima versão do Windows Server de codinome “Longhorn” (atualmente em beta).
Para enviar pacotes marcados para entrega priorizada, os aplicativos ou os componentes do sistema operacional devem ser capazes de especificar os valores da prioridade 802.1p ou o valor DSCP. As seções a seguir descrevem como os componentes do Windows ou os aplicativos baseados no Windows podem especificar a prioridade 802.1p para quadros Ethernet ou valor DSCP para o tráfego TCP/IP.

QoS no Windows XP e no Windows Server 2003
O Windows XP e o Windows Server 2003 fornecem APIs para atribuir os parâmetros de QoS ao tráfego. Os desenvolvedores de aplicativos podem usar o Windows Sockets (Winsock) e APIs de GQoS (QoS genéricas) para aplicar os parâmetros de QoS no nível do aplicativo, por soquete. Os administradores de rede podem usar as ferramentas de gerenciamento de tráfego escritas para chamar a API de TC (controle de tráfego) para aplicar os parâmetros de QoS no nível do host.
Você pode usar o Winsock e a opção IP_TOS para configurar o valor DSCP de pacotes de saída em relação a um soquete. No entanto, por padrão, a pilha do TCP/IP ignora a opção de soquete IP_TOS. Para usar a opção de soquete IP_TOS, você deve primeiro criar e configurar o valor do Registro DWORD DisableUserTOSSetting=0, na seguinte chave do Registro (veja a Figura 1):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Figura 1 Configurando o valor de Registro de DisableUserTOSetting
Figura 1 Configurando o valor de Registro de DisableUserTOSetting
Você deve reiniciar o computador para que essa configuração do Registro tenha efeito.
Para especificar o valor DSCP do tráfego sem ter que usar a opção de soquete IP_TOS, você pode usar as APIs de GQoS. A GQoS faz parte do Windows Sockets 2.0 (Winsock2). A maioria dos aplicativos habilitados para QoS usam a API de GQoS para invocar os recursos de QoS no Windows. A GQoS no Windows XP Service Pack 2 (SP2) permite que um aplicativo configure um valor DSCP e acelera o respectivo tráfego de saída. Para configurar as prioridades 802.1p em computadores que executam o Windows XP SP2, você deve usar a API de TC.
A API de TC oferece acesso aos mecanismos de controle de tráfego que regulam o tráfego de rede no host local. Isso permite o controle direto de valores DSCP, marcas 802.1p e taxa de otimização. Os administradores de rede podem usar programas de gerenciamento de tráfego para invocar a API de TC diretamente em nome dos aplicativos que não reconhecem QoS. Por se tratar de uma API de nível inferior à API de GQoS, a API de TC requer privilégios de nível de administrador.
Ao contrário da API de GQoS, a API de TC permite que o tráfego de vários aplicativos no mesmo host de envio seja agregado em um único fluxo QoS. Como parte desta agregação, o tráfego pode ser identificado por uma combinação de seus endereços IP de origem e de destino, portas de origem e de destino e protocolo (TCP ou UDP).Por exemplo, todo o tráfego em um endereço IP de destino específico pode ser incluído em um único fluxo QoS de qualquer porta de origem e de destino, independentemente do aplicativo de envio no host. A API de GQoS, por outro lado, permite que um aplicativo defina seu próprio tratamento de QoS nos dados que envia em um soquete.
Para dar suporte ao recurso QoS, os computadores baseados no Windows XP e no Windows Server 2003 devem ter o componente Agendador de Pacotes QoS instalado e habilitado nas propriedades de conexões de rede, da pasta Conexões de Rede (veja a Figura 2). O componente Psched.sys (Agendador de Pacotes QoS) é instalado, e por padrão, habilitado, para computadores com o Windows XP em execução. O componente Agendador de Pacotes pode ser instalado no Windows Server 2003.
Figura 2 Configurando o agendador de pacotes QoS
Figura 2 Configurando o agendador de pacotes QoS

A QoS no Windows Vista e no Windows Server “Longhorn”
O suporte de QoS no Windows Vista e no Windows Server “Longhorn” foi aprimorado e simplificado. Para a equipe de TI, agora é possível usar a QoS com base em diretivas para configurar valores DSCP e controlar as taxas de envio de aplicativo sem ter que usar APIs nem modificar aplicativos existentes. Para os desenvolvedores, a GQoS e as APIs de TC têm suporte, embora o suporte a essas APIs não esteja planejado para versões futuras do Windows. Além disso, a opção IP_TOS Winsock foi removida. Para substituir as APIs de GQoS e TC e simplificar o suporte de QoS a aplicativos futuros ou atualizados, o Windows Vista e o Windows Server "Longhorn" oferecem suporte à nova API de QoS2, também conhecida como qWAVE (Quality Windows Audio-Video Experience).
A QoS baseada em diretivas no Windows Server "Longhorn" e no Windows Vista permite que você ofereça experiências melhores ao usuário final, controle custos de largura de banda ou negocie níveis de serviço mais interessantes com provedores de largura de banda ou departamentos comerciais. Você pode gerenciar centralmente a largura de banda de computadores que executam o Windows Vista ou o Windows Server “Longhorn”, não importando qual o aplicativo e em uma infra-estrutura inteira do Active Directory ®. Como o gerenciamento de tráfego ocorre abaixo da camada do aplicativo, não é necessário modificar os aplicativos existentes de gerenciamento de tráfego da QoS baseada em diretivas.
As configurações da QoS baseada em diretivas no Windows Server "Longhorn" e no Windows Vista permitem priorizar ou gerenciar a taxa de envio do tráfego de saída com base nas seguintes condições:
  • Aplicativo de envio (nome do pathand executável)
  • Endereços Ipv4 ou Ipv6 de origem ou de destino ou prefixos de endereços
  • Protocolo (TCP, UDP ou os dois)
  • Portas de origem ou de destino ou intervalos de portas (TCP ou UDP)
As diretivas de QoS são aplicadas a uma sessão de logon de usuário ou a um computador como parte de um GPO (Objeto de Diretiva de Grupo) vinculado a um contêiner do Active Directory, como um domínio, site ou UO (unidade organizacional), ou deverão ser aplicadas a um grupo de segurança. Como parte da Diretiva de Grupo, as diretivas de QoS usam como base a sua infra-estrutura de gerenciamento existente do Active Directory.
A QoS baseada em diretivas permite definir a prioridade de tráfego. Você pode configurar uma diretiva de QoS para marcar o tráfego IPv4 e IPv6 de saída com um valor DSCP específico. Você também pode gerenciar o uso de largura de banda do tráfego de saída. Você pode configurar uma diretiva de QoS com uma taxa de otimização para o tráfego de saída. Com a otimização, os componentes de QoS limitam o tráfego de rede de saída agregado a uma taxa específica. Em computadores, você pode gerenciar o uso da largura de banda do tráfego de entrada, definindo as configurações avançadas para especificar a taxa de transferência de entrada do tráfego TCP, configurando um valor máximo para o tamanho da janela de recepção TCP.
No Windows Vista e no Windows Server "Longhorn", o Agendador de Pacotes QoS é instalado e, por padrão, habilitado. O componente Pacer.sys é um novo driver de filtro simples NDIS 6.0 (Network Device Interface Specification) que controla o agendamento de pacotes da QoS baseada em diretivas e do tráfego de aplicativos habilitados para QoS. O Pacer.sys substitui o Psched.sys no Windows XP e no Windows Server 2003.
Para implantar a QoS baseada em diretivas em sua intranet, configure as diretivas de QoS com base em computador ou usuário e aplique-as ao contêiner apropriado do Active Directory. Os computadores baseados no Windows Vista ou no Windows Server "Longhorn" fazem download e aplicam as respectivas configurações de QoS baseada em diretivas quando atualizam a Diretiva de Grupo Configuração do Usuário ou Configuração do Computador.
Como as redes estão sendo cada vez mais compartilhadas por aplicativos de dados e de AV (áudio/vídeo), uma solução de QoS é necessária para que o tráfego de AV dependente de tempo possa receber tratamento preferencial sobre o tráfego de dados. Além disso, as redes estão cada vez mais se tornando sem fio, o que introduz complicações adicionais para aplicativos que levam em conta a largura de banda e a latência.
O recurso qWAVE no Windows Vista fornece uma coleção de módulos de software relacionados à QoS que lidam com desafios da rede introduzidos por aplicativos de AV e redes sem fio. O qWave está integrado no subsistema de QoS e funciona com várias tecnologias de prioridade de pacotes da camada de Interface de Rede e Internet. O qWave oferece suporte a vários fluxos de AV (fluxos em tempo real que exigem a QoS) e fluxos de dados (fluxos de melhor esforço, como e-mail ou transferências de arquivos) simultaneamente.
A coleção de tecnologias do qWAVE detecta e monitora a largura de banda da LAN, descobre o recurso de QoS da rede e oferece controle de admissão distribuído para uma utilização uniforme e consistente da largura de banda da rede. Essas tecnologias habilitam técnicas avançadas de transmissão de AV para que os aplicativos possam adaptar-se dinamicamente às condições de alterações de redes e estão disponíveis apenas para desenvolvedores por meio da API de QoS2.
A API de QoS2 no Windows Vista e no Windows Server "Longhorn" substitui a opção Winsock IP_TOS e a API de GQoS e você o considerará mais fácil de usar do que a API de GQoS.

Para obter mais informações
Para saber mais sobre a QoS, existem várias fontes excelentes disponíveis na TechNet. Comece com o Microsoft Quality of Service Web site. Verifique também a seção de QoS do Windows Core Networking blog.

Joseph Davies é redator técnico da Microsoft e vem ensinando e escrevendo sobre tópicos de sistema de redes Windows desde 1992. Ele escreveu cinco livros para a Microsoft Press ® e é autor da coluna mensal Cable Guy da Technet.


 Windows PowerShell: Criando scripts uma linha por vez
Windows PowerShell
Criando scripts uma linha por vez
Don Jones

Nas colunas anteriores, eu analisei o fato de o Windows PowerShell ser um shell. Ele é indicado para ser usado interativamente – em nada diferente do shell cmd.exe (ou prompt de comando) com que você provavelmente já está familiarizado. Ainda assim, o Windows PowerShell oferece suporte a uma linguagem de script – uma mais robusta que a linguagem em lotes do cmd.exe. E ela
é tão potente quanto, se não mais potente que linguagens como o VBScript. Entretanto, o fato de o Windows PowerShell™ ser um shell interativo torna o script consideravelmente fácil de se aprender. Na verdade, você pode desenvolver os scripts interativamente no shell, tornando possível escrever scripts uma linha por vez e observando imediatamente os resultados de seus esforços.
Essa técnica de criação de scripts interativa torna também a depuração mais fácil. Como você vê os resultados do seu script imediatamente, poderá rapidamente revisá-lo quando as coisas não forem como o esperado.
Nesta coluna, eu o orientarei em um exemplo de script interativo do Windows PowerShell. Criarei um script que leia os nomes de serviço de um arquivo de texto e configure cada modo de inicialização do serviço como Desabilitado.
O que desejo que você retire dessa orientação é o conceito de criar scripts do WindowsPowerShell em pequenas partes, em vez de tentar atacar um script inteiro em um grande bloco. Você pode pegar qualquer tarefa administrativa que precisa realizar e dividi-la em partes do componente e, em seguida, descobrir como fazer com que cada parte funcione independentemente.O Windows PowerShell fornece maneiras excelentes de unir essas partes, como você verá. E você descobrirá que, trabalhando em pequenas partes por vez, você terá mais conforto no desenvolvimento do script final.

Lendo nomes de um arquivo
Descobrir como ler arquivos de texto no Windows PowerShell pode ser frustrante. Se eu executar o *arquivo* Ajuda, tudo o que obtenho é ajuda para o cmdlet Out-File, que envia o texto a um arquivo em vez de ler dele. Sem ajuda nenhuma! Entretanto, os nomes de cmdlet do Windows PowerShell seguem um tipo de lógica que eu posso usar a meu favor. Quando o Windows PowerShell recupera alguma coisa, o nome do cmdlet normalmente começa com Get. Então executo o Help Get* para exibir esses cmdlets e, em seguida, rolo pela lista e visualizo o Get-Content. Parece promissor! Então executo o Help Get-Content para ver mais informações sobre o que ele faz (consulte a Figura 1) e parece que terei minhas necessidades atendidas.
Figura 1 Executando o Help Get-Content para obter mais informações
Figura 1 Executando o Help Get-Content para obter mais informações (Clique na imagem para diminuir a exibição)
Figura 1 Executando o Help Get-Content para obter mais informações
Figura 1 Executando o Help Get-Content para obter mais informações (Clique na imagem para aumentar a exibição)
O Windows PowerShell trata praticamente tudo como objeto e os arquivos de texto não são exceção. Um arquivo de texto é tecnicamente uma coleção de linhas em que cada linha do arquivo funciona como uma espécie de objeto independente. Assim, se eu criei um arquivo de texto chamado C:\services.txt e preenchido o arquivo com nomes de serviço (colocando cada nome em sua própria linha dentro do arquivo), o Windows PowerShell pode ler os nomes individualmente, usando o cmdlet Get-Content. Como a idéia desse passo a passo é mostrar como os scripts podem ser desenvolvidos interativamente, começarei executando apenas o Get-Content, dando a ele o nome do meu arquivo de texto e observando o que acontece:
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
Como esperado, o Windows PowerShell lê o arquivo e exibe o nome. É claro, exibir simplesmente os nomes não é realmente o que desejo, mas agora eu sei que o Get-Content funciona da maneira como eu esperava que funcionasse.

Alterando um serviço
A próxima coisa que eu quero fazer é alterar o modo de inicialização do serviço. Mais uma vez, começo tentando encontrar o cmdlet correto. Então executo o Help *Service*. Isso retorna uma lista pequena e o cmdlet Set-Service parece ser o único que se ajusta às minhas necessidades. Desejo testar este cmdlet para me certificar de ter entendido como ele funciona antes de tentar incorporá-lo em um script. Executar o Help Set-Service mostra como o cmdlet deve funcionar, e um teste rápido confirma isso:
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

Combinando as partes
Agora preciso combinar a habilidade de ler nomes de serviço de um arquivo com o cmdlet Set-Service e é aí que os recursos eficientes de pipeline do Windows PowerShell entram em ação. Com o pipeline, a saída de um cmdlet pode ser passada como a entrada para um segundo cmdlet. O pipeline passa objetos inteiros. Caso uma coleção de objetos seja colocada no pipeline, cada objeto é passado pelo pipeline individualmente. Isso significa que a saída do Get-Content – que, lembre-se, é uma coleção de objetos – pode ser enviada por pipe para o Set-Service. Como o Get-Content está passando uma coleção, cada objeto ou linha do texto na coleção é enviada por pipe para o Set-Service individualmente. O resultado é que o Set-Service é executado uma vez para cada linha do meu arquivo de texto. O comando se parece com o seguinte:
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
Aqui está o que acontece:
  1. O cmdlet Get-Content é executado e lê o arquivo inteiro. Cada linha do arquivo é tratada como um objeto exclusivo e, juntas, são uma coleção de objetos.
  2. A coleção de objetos é enviada por pipe para o Set-Service.
  3. O pipeline executa o cmdlet Set-Service uma vez para cada objeto de entrada. Para cada execução, o objeto de entrada é passado para o Set-Service como o primeiro parâmetro do cmdlet, que é o nome do serviço.
  4. O Set-Service é executado, usando o objeto de entrada do primeiro parâmetro e todos os demais parâmetros sejam especificados, o parâmetro -statuptype, neste caso.
O mais interessante é que, na verdade, eu realizei minha tarefa nesse ponto - e eu nem sequer escrevi um script ainda. Essa mesma ação seria difícil de se obter no shell do Cmd.exe e ela tomaria uma dúzia de linhas de código no VBScript. Mas o Windows PowerShell cuida de tudo isso em uma linha. Ainda assim, eu não terminei. Como você pode ver, meu comando não fornece grande quantidade de comentário nem saída de status. À parte a falta de erros, é difícil ver se alguma coisa na verdade aconteceu. Agora que já domino a funcionalidade necessária para realizar minha tarefa, posso começar a torná-la com uma aparência melhor, entrando no script de verdade.
Windows PowerShell Prompt Here, por Michael Murgolo
Um dos mais populares Microsoft® PowerToys for Windows® (e um dos meus favoritos) é a ferramenta Open Command Window Here. Disponível como parte do Microsoft PowerToys for Windows XP ou no Windows Server® 2003 Resource Kit Tools, o Open Command Window Here permite que você clique com o botão direito do mouse em uma pasta ou unidade do Windows Explorer para abrir uma janela de comando que aponte para a pasta selecionada.
Como eu estava aprendendo o Windows PowerShell, eu me vi desejando que ele tivesse a mesma funcionalidade. Então peguei o arquivo .inf de configuração do Open Command Window Here e o cmdhere.inf nas ferramentas do Windows Server 2003 Resource Kit e o modifiquei para criar o menu de contexto do Windows PowerShell Prompt Here. Esse arquivo .inf é incluído na postagem original do blog em que se baseia essa barra lateral (disponível em leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx).Para instalar a ferramenta, basta clicar com o botão direito do mouse no arquivo .inf e selecionar Install.
Ao criar a versão dessa ferramenta do Windows PowerShell, descobri que a original tinha um bug - se o Open Command Windows Here fosse desinstalado, ele deixaria para trás uma entrada inativa de menu de contexto. Como resultado, forneci uma versão atualizada do cmdhere.inf, disponível também na postagem original do blog.
Esses PowerToys aproveitam o fato que essas entradas de menu de contexto são configuradas no Registro em chaves associadas aos tipos de objeto Directory e Drive. Isso é feito da mesma maneira com que as ações do menu de contexto são associadas a tipos de arquivo. Por exemplo, quando você clica com o botão direito do mouse em um arquivo .txt no Windows Explorer, obtém diversas ações (como Abrir, Imprimir e Editar) na parte superior da lista. Para entender como esses itens são configurados, vamos dar uma olhada no hive do Registro HKEY_CLASSES_ROOT.
Se você abrir o Editor do Registro e expandir a ramificação HKEY_CLASSES_ROOT, verá chaves nomeadas de tipos de arquivo, como .doc, .txt e assim por diante. Se você clicar na chave .txt, verá que o valor (padrão) é txtfile (veja a Figura A). Esse é o tipo de objeto associado a um arquivo txt. Se você rolar para baixo e expandir a chave txtfile e, em seguida expandir, a chave do shell debaixo dela, verá chaves nomeadas para algumas das entradas do menu de contexto de um arquivo .txt. (Você não verá todos eles porque existem outros métodos para criação de menus de contexto). Em cada um deles está uma chave de comando. O valor (padrão) sob a chave de comando é a linha de comando que o Windows executa quando você seleciona esse item do menu de contexto.
As ferramentas do prompt do cmd e do Windows PowerShell usam essa técnica para configurar as entradas do menu de contexto Open Command Window Here e Windows PowerShell Prompt Here. Não existem tipos de arquivo associados às unidades e aos diretórios, mas existem chaves Drive e Directory em HKEY_CLASSES_ROOT associadas a esses objetos.
Figura A As entradas do menu de contexto são configuradas no Registro
Figura A As entradas do menu de contexto são configuradas no Registro (Clique na imagem para diminuir a exibição)
Figura A As entradas do menu de contexto são configuradas no Registro
Figura A As entradas do menu de contexto são configuradas no Registro (Clique na imagem para aumentar a exibição)

Michael Murgolo é consultor sênior de infra-estrutura da Microsoft Consulting Services. Ele está focado nas áreas de sistemas operacionais, implantação, serviços de rede, Active Directory, gerenciamento de sistemas, automação e gerenciamento de patches.

Criando scripts interativamente
Uma coisa que preciso fazer é ter vários cmdlets executados para cada serviço listado em C:\services.txt. Dessa forma, posso dar saída ao nome do serviço e a qualquer outra informação que eu desejar para poder controlar o progresso do script.
Antes eu usei o pipeline para passar objetos de um cmdlet para outro. Dessa vez, contudo, usarei uma técnica mais parecida com script, chamada construção Foreach (que apresentei na coluna do último mês). A construção Foreach pode aceitar uma coleção de objetos e ela executará vários cmdlets para cada objeto da coleção. Designo uma variável que representa o objeto atual a cada vez pelo loop. Por exemplo, a construção pode começar da seguinte maneira:
foreach ($service in get-content c:\services.txt)
Ainda estou executando aquele mesmo cmdlet Get-Content para recuperar o conteúdo do arquivo de texto. Dessa vez, estou pedindo para que a construção Foreach passe por uma coleção de objetos retornados pelo Get-Content. O loop é executado uma vez em cada objeto e o objeto atual é colocado na variável $service. Agora eu só preciso especificar o código que desejo que seja executado no loop. Começarei tentando duplicar meu comando original de uma linha (isso minimizará a complexidade e assegurará que eu não perca nenhuma funcionalidade):
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
Há algo interessante acontecendo aqui. Observe que eu terminei a primeira linha da construção Foreach com uma chave de abertura. Tudo dentro da chave de abertura e de fechamento é considerado como dentro do loop Foreach e será executado uma vez para cada objeto na coleção de entrada. Após ter digitado { e pressionado Enter, observe que o Windows PowerShell altera o prompt para >> (veja a Figura 2). Isto indica que ele sabe que iniciei uma construção de algum tipo e que está esperando que eu termine. Em seguida, digitei o meu cmdlet Set-Service. Desta vez, usei $service como o primeiro parâmetro, pois $service representa a leitura do nome do serviço atual do meu arquivo de texto. Na próxima linha, concluo a construção com uma chave de fechamento. Após pressionar Enter duas vezes, o Windows PowerShell executa imediatamente o meu código.
Figura 2 O Windows PowerShell sabe que uma construção foi iniciada
Figura 2 O Windows PowerShell sabe que uma construção foi iniciada (Clique na imagem para diminuir a exibição)
Figura 2 O Windows PowerShell sabe que uma construção foi iniciada
Figura 2 O Windows PowerShell sabe que uma construção foi iniciada (Clique na imagem para aumentar a exibição)
É isso mesmo, imediatamente. O que eu digitei parece um script, mas o Windows PowerShell o está executando, na verdade, ao vivo, e ele não está armazenado em um arquivo de texto de lugar nenhum. Agora digitarei tudo novamente, adicionando uma linha de código para dar saída ao nome do serviço atual:
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
Observe que estou pedindo que ele exiba algo e coloquei esse algo entre aspas duplas. As aspas informam ao Windows PowerShell que se trata de uma seqüência de texto e não de outro comando. Entretanto, quando você usa aspas duplas em vez de aspas simples, o Windows PowerShell examina a seqüência de texto em busca de variáveis. Se ele encontrar alguma, substitui o valor verdadeiro dela pelo nome da variável. Assim, quando ele executa esse código, você pode ver que o nome do serviço atual está sendo exibido.
Isso ainda não é um script!
Até agora, usei o Windows PowerShell interativamente, que é uma ótima forma de ver imediatamente os resultados do que estou escrevendo. Entretanto, digitar novamente essas linhas se tornará, em algum momento, tedioso. É por isso que o Windows PowerShell também pode executar scripts. Na verdade, os scripts do Windows PowerShell seguem a definição mais literal da palavra script: O Windows PowerShell basicamente apenas lê o arquivo de texto de script e “digita” cada linha que encontra, exatamente como se você estivesse digitando as linhas manualmente. O que significa que tudo o que eu fiz até este ponto pode ser colado em um arquivo de script. Portanto, usarei o Bloco de Notas para criar um arquivo chamado disableservices.ps1 e colar dentro dele o seguinte:
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
Coloquei esse arquivo em uma pasta chamada C;\test. Agora tentarei executá-lo de dentro do Windows PowerShell:
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
Opa! O que saiu errado? O Windows PowerShell está focado na pasta C:\test folder, mas não encontro meu script. Por quê? Devido a restrições de segurança, o Windows PowerShell foi criado para não executar nenhum script da pasta atual, impedindo, portanto, que qualquer script seqüestre um comando do sistema operacional. Por exemplo, não posso criar um script chamado dir.ps1 e fazer com que ele substitua o comando dir normal. Se eu precisar executar um script da pasta atual, tenho que especificar um caminho relativo:
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
E agora? Ainda não está funcionando. Obtive o caminho certo, mas o Windows PowerShell diz que não é possível executar scripts. Isso ocorre porque, por padrão, o Windows PowerShell não consegue executar scripts. Novamente, trata-se de uma precaução de segurança criada para evitar os problemas que todos nós tivemos com o VBScript. Os scripts mal-intencionados não podem, por padrão, ser executados no Windows PowerShell, porque nenhum script pode ser executado por padrão. Para executar meu script, preciso alterar explicitamente a diretiva de execução:
PS C:\test> set-executionpolicy remotesigned
A diretiva de execução RemoteSigned permite que scripts não assinados sejam executados do computador local – os scripts baixados ainda devem ser assinados para serem executados. A AllSigned é uma diretiva melhor, que executa apenas os scripts que foram assinados digitalmente com um certificado emitido por um editor confiável. Entretanto, eu não tenho um certificado em mãos, assim, não posso assinar meus scripts, o que torna o RemoteSigned uma escolha um tanto melhor para essa situação. Agora tentarei executar meu script novamente:
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
Quero ressaltar que a diretiva de execução RemoteSigned que estamos usando não é uma excelente escolha, mas simplesmente uma boa escolha. Mas existe uma solução bem melhor. Seria bem mais seguro obter um certificado de assinatura de código, usar o cmdlet Set-AuthenticodeSignature do Windows PowerShell para assinar meus scripts e configurar a diretiva de execução para a diretiva AllSigned, muito mais segura.
Há também uma outra diretiva, Unrestricted, que você definitivamente deve evitar. Essa diretiva permite que todos os scripts, mesmo os mal-intencionados de locais remotos, sejam executados sem restrições em seu computador, o que pode colocá-lo em uma posição muito perigosa. Conseqüentemente, não recomendo o uso da diretiva Unrestricted por nenhum motivo.

Resultados imediatos
Os recursos de script interativos do Windows PowerShell permitem que você crie rapidamente protótipos de scripts ou mesmo apenas pequenos blocos de scripts. Você obtém resultados imediatos, assim pode ajustar os scripts para obter exatamente os resultados que deseja. Quando terminar, você poderá mover seu código para um arquivo .ps1, tornando-o permanente e de fácil acesso no futuro. E lembre-se: de preferência, você deverá assinar digitalmente esses arquivos .ps1, de modo a poder deixar o Windows PowerShell configurado para a diretiva de execução AllSigned, a diretiva mais segura que permite a execução de script.

Don Jones é o guru-chefe de scripts da SAPIEN Technologies e co-autor do Windows PowerShell: TFM (consulte www.SAPIENPress.com). Entre em contato com Don em don@sapien.com.


 Ei, Equipe de Scripts!: Perseguindo carros ... e XML
Ei, Equipe de Scripts!
Perseguindo carros ... e XML
A Equipe de Scripts da Microsoft
Faça download do código deste artigo: HeyScriptingGuy2007_02.exe (150KB)

“NÃO SEI por que meu cachorro persegue carros” é a velha piada. “Afinal, o que ele faria se de fato conseguisse capturar um carro?”
Trata-se de uma boa pergunta que a Equipe de Scripts não consegue responder. Bem, a menos que quem capture o carro seja Lucy, a cadela lá da rua de baixo. Não temos dúvida nenhuma de que essa cadela roubaria uma loja de bebidas e depois usaria o carro para fugir. E, a julgar pelas condições do gramado da frente, estamos propensos a apostar que ela não se deteria em nenhuma pausa para descanso pelo caminho, se é que você me entende.
Se tivéssemos que atualizar essa piada antiga para a era atual de alta tecnologia, ficaria mais ou menos da seguinte forma: “Não sei por que meu administrador de sistemas continua tentando aprender XML. Afinal, o que ele faria se de fato conseguisse aprender?”
Observação Em nossa defesa, dissemos apenas que iríamos atualizar aquela piada antiga e ultrapassada, não dissemos em nenhum momento que a tornaríamos engraçada.
Para ser honesto, XML pode ser uma tecnologia um tanto quanto badalada, pelo menos quando se trata de administração de sistemas. A verdade é que muitos administradores de sistemas viveram por muito tempo e felizes sem ter que escrever um script sequer que interagisse com um arquivo XML, e não esperamos que isso mude em nenhum momento no futuro próximo.
Assim, é verdade também que cada vez mais aplicativos estão adotando o XML como padrão para armazenamento de dados. E por que não? Como não passam de arquivos de texto adornados, esses arquivos de dados XML são rápidos e fáceis de se criar, são portáteis em plataformas e não requerem nenhum programa de banco de dados complexo (e caro). Você tem um sistema operacional e um editor de texto? Então você pode criar um banco de dados XML.
O que significa, é claro, que existe pelo menos uma coisa o administrador de sistema possa fazer com o XML: escrever scripts que consultem um arquivo XML como se o arquivo fosse um banco de dados de pesquisa completo. E quem melhor que a Equipe de Scripts para dar algumas indicações de como fazer exatamente isto?
Tudo bem, boa observação. Mas, se tivéssemos fazer uma suposição, apostaríamos que Lucy provavelmente está muito ocupada cavando o canteiro de flores de alguém, para escrever uma coluna sobre XML.
Para começar, vamos dar uma olhada em um arquivo XML simples (veja a Figura 1), um arquivo de banco de dados destacando quatro scripts, encontrado na coluna diária Hey, Scripting Guy! !
Figure 1 Ei, Equipe de Scripts! Scripts em XML (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
Como você pode ver, trata-se de um arquivo pequeno e bem simples. Cada script individual é arquivado em uma marca <Script> . De agora em diante, vamos nos referir a esses scripts como registros. Sim, você tem razão - os aficionados por XML nunca se referem a esses itens como registros. Mas, tudo bem, nosso objetivo aqui é mostrar como aplicar algo que você já conhece: técnicas de consulta ao banco de dados, para um tipo novo e diferente de fonte de dados. Nós pensamos em nos concentrar primeiramente em como fazer as coisas, e depois, talvez, retornar a esse tópico no futuro e fornecer então a terminologia adequada.
OK, voltemos aos registros. Cada registro contém os seguintes campos: <Category>, <Subcategory>, <Keyword>, <Title>, and <URL>.
Hmm, você não está tão impressionado quanto pensamos que ficaria. Talvez ajudasse se tivéssemos mostrado a você um script que pudesse abrir esse arquivo XML e retornasse o conteúdo:
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Observação tenha cuidado: esses nomes de marca fazem distinção entre maiúsculas e minúsculas. É “/Repository/Script" e não "/repository/script" ou "/REPOSITORY/SCRIPT".
Está certo, isso também não impressiona muito. Mas esta é a questão: isso não é nem de perto tão difícil quanto você possa esperar.
Como se pode observar no código, começamos criando uma instância do objeto Microsoft.XMLDOM, o objeto COM usado para trabalhar com arquivos XML. Depois, configuramos a propriedade Async para False; isso ajuda a assegurar que o arquivo inteiro seja lido na memória antes que o controle retorne para o script. Usamos em seguida o método Load para ler o arquivo C:\Scripts\Scripts.xml:
xmlDoc.Load("C:\Scripts\Scripts.xml")
Assim que o arquivo tiver sido carregado na memória, podemos usar o método selectNodes para selecionar o registro especificado no banco de dados:
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
Examine de perto o parâmetro passado para selectNodes. Na verdade, ele representa o caminho no arquivo XML. Nosso arquivo XML tem esta estrutura:
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
Você deve se importar com isso? Em poucas palavras, sim! Ao lidar com arquivos XML, a estrutura é muito importante. Por exemplo, como chegamos às propriedades individuais de um registro? É fácil: acessamos a marca <Repository>seguida pela marca <Script> e pelas marcas de propriedade individual. E...adivinhe só: É o mesmo caminho que especificamos como sendo o parâmetro para selectNodes. Simplesmente seguimos aquele caminho com /*, que significa "Selecione todas as propriedades para esses registros”. Em outras palavras, nossa coleção retornada consistirá em todas as propriedades de todos os registros do banco de dados - semelhante à consulta "Selecionar * De" do Windows® Management Instrumentation (WMI).
Observação dê uma chance ao script de exemplo e você verá exatamente o que queremos dizer.
O restante do script é fácil, tudo o que fazemos é configurar um loop For Each para percorrer a coleção, e retornarmos o valor da propriedade Text de cada item e cada propriedade:
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Muito mais fácil do que perseguir carros.
Mas, você está certo: se tudo o que desejávamos fazer era retornar o conteúdo inteiro do arquivo, poderíamos ter ignorado todos aqueles recursos XML e usado apenas o FileSystemObject. (Poderia ter sido um pouquinho mais complicado, mas só um pouquinho.) Se nossa intenção fosse deslumbrá-lo e fazê-lo pensar “Puxa, afinal esses recursos XML são muito úteis”, bem, provavelmente ainda temos maneiras de o fazer.
Então vejamos o que se pode fazer a respeito. No primeiro script obtivemos de volta todos os valores de propriedade de todos os registros. Tudo bem, mas, vamos supor que tudo o que realmente desejávamos ter de volta fosse o título do script? Isso é possível? Hmm, só um segundo...
OK, de acordo com Lucy, tudo o que devemos fazer é modificar o comando selectNodes, adicionando a propriedade de interesse ao final do caminho. Em outras palavras:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
Acontece que o único motivo de termos obtido de volta todas as propriedades na primeira vez, é o fato de usamos o caractere curinga *. Agora obtivemos apenas a propriedade Title. Por quê? Porque esse é o único valor de propriedade que solicitamos de volta.
Observação Hmm, dê uma olhada nisto: O XML fornece exatamente o que você pede. Sem ofensas, Lucy, mas achamos que o XML é o novo melhor amigo do homem!
E, com certeza, é possível retornar mais de uma propriedade. Por exemplo, este comando modificado retorna valores para as propriedades Title e URL:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
Com certeza, a sintaxe tem uma aparência um tanto desajeitada, mas assim que você se acostuma a ela, não é tão ruim assim. Para começar, especificamos a parte principal do caminho, exatamente como fizemos anteriormente:
    /Repository/Script/
Em seguida, adicionamos um conjunto de parênteses e, dentro desses parênteses, especificamos as propriedades a serem retornadas. (Observe que usamos o separador pipe: o caractere | - para dividir as propriedades individuais). Ou seja:
    (Title | URL)
Como dissemos, talvez seja um pouco tolo, mas funciona.
E você não esta limitado a retornar apenas duas propriedades. Desde que você continue adicionando separadores pipe, poderá obter de volta todas as informações que desejar. Por exemplo, o comando a seguir retorna três propriedades (Title, URL e Keyword):
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
Legal, hein?
Bem, nós achamos legal. Vocês são uma equipe corajosa. Mas, novamente, temos uma boa questão: tudo o que fizemos até aqui foi recuperar informações sobre todos os registros de nosso banco de dados. Entretanto, não há nada de errado nisso. Muitas vezes, isso é exatamente o que você deseja fazer. Por outro lado, também haverá momentos (muitos) em que desejaremos recuperar informações de apenas um subconjunto desses registros. Por exemplo, talvez desejemos obter de volta as informações apenas dos scripts que tenham uma palavra-chave igual aos bancos de dados. Você sabe, usando uma consulta semelhante a esta:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
Mais uma vez, a sintaxe é um pouco estranha. O lado bom é que, contudo, a sintaxe também é fácil e bem simples. Após especificar o caminho principal, colocamos nossa clausula "Where" (por exemplo, where x equals y) dentro de colchetes, assim:
/Repository/Script [Keyword = ‘databases’]
Como você provavelmente já deve ter entendido, nosso equivalente da cláusula Where informa ao script “Retornar apenas os itens onde o atributo Keyword for igual a database". Observe que database está entre aspas simples. Isso não é apenas perfeito, é praticamente necessário. Se o termo de filtragem estiver entre aspas duplas, você obterá um erro de sintaxe quando tentar executar o script.
Observação por quê? Porque, lembre-se, a seqüência de consulta inteira:"/Repository/Script [Keyword = ‘databases’]", está entre aspas duplas.
É claro que você não está limitado a usar o sinal de igual (=) quando filtrar os dados. Você poderá usar os sinais maior que (>) ou menor que (<), bem como os sinais favoritos de todos, menor que ou igual a (<=) e maior que ou igual a (>=). Você também pode negar qualquer um desses sinais, colocando um ponto de exclamação na frente. Por exemplo, este comando solicita todos os scripts quando a palavra-chave não for igual a database (observe o sinal !=):
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
Espere um minuto: Quem foi que disse, "Claro, você pode configurar um filtro, mas aposto que você não pode configurar um filtro e especificar as propriedades que deseja retornar". Claro que você consegue:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
Se tudo for bem,, esse comando retornará apenas a propriedade Title de todos os scripts que tenham bancos de dados Keyword. Vejamos se funciona:
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
Vejamos se conseguimos ajustar mais um comando antes de irmos embora. Embora estejamos fazendo progressos, talvez ainda estejamos retornando mais registros do que queremos de fato retornar Afinal, nosso comando anterior retorna uma mistura de scripts do Microsoft ® Access® e scripts do Microsoft SQL Server™. (Por quê? Porque todos esses scripts usam os bancos de dados Keyword). E, se quiséssemos limitar os dados retornados a scripts que têm bancos de dados para uma palavra-chave e têm o Microsoft SQL Server™ como uma subcategoria? A filtragem com base em critérios múltiplos é possível?
Como se você tivesse que perguntar:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
É a mesma sintaxe básica, usamos apenas dois critérios separados (ou seja, palavra-chave = ‘database’ e Subcategoria = ‘Microsoft SQL Server’) e conectamos os dois, usando o operador AND.
Observação Sim, você têm razão: com esse arquivo XML pequeno e simples, bastava termos solicitado todos os scripts onde a Subcategoria fosse igual ao Microsoft SQL Server. Mas isso não teria graça nenhuma e não seria nem de perto educativo.
Você também pode usar as cláusulas OR. Por exemplo, suponhamos que tivéssemos um monte de scripts do Microsoft Office, incluindo scripts com Subcategorias iguais ao Microsoft Excel®, Microsoft PowerPoint®, Microsoft Outlook® e assim por diante. É possível restringir os dados retornados apenas aos scripts das subcategorias Microsoft Word ou Microsoft Acess? Pode apostar que sim:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
É assim mesmo? Tudo bem, isso pode não ser qualificado como uma coluna que tenha mudado a sua vida para sempre, mas, ainda assim, existe uma boa chance de que, mais cedo ou mais tarde, a possibilidade de consultar um arquivo XML dessa maneira seja útil. Mas a decisão é sua: você pode aprender algumas técnicas de XML básicas ou perseguir carros. Você decide. (Se você escolher a última opção e acontecer de se encontrar com Lucy, a cadela da rua de baixo, diga a ela que a equipe dos Scripts manda um “Olá”. E diga a ela para ficar longe do nosso jardim!)
Ei, Equipe de Scripts! - Todos os dias
Você acabou de examinar a coluna Hey, Scripting Guy! deste mês e considerou este o melhor material técnico que já leu até hoje. Você poderia até ir além disso e afirmar que este é o melhor material escrito até hoje. Além disso, você já está ansiosamente aguardando, ao lado da caixa de correio, na expectativa da próxima edição da TechNet Magazine, só para poder ler mais artigos como este.
O que você está esperando então? Quer saber mais sobre a cadela da vizinhança ou ler sobre as explorações mais recentes do Scripting Son? Você ouviu como foi a partida de boliche Turducken no ano passado? Fique em dia com todos esses assuntos importantes, lendo a coluna diária (sim, dissemos diária): Ei, Equipe de Scripts (em inglês). . Sempre de segunda a sexta-feira (menos nos principais feriados e nas férias da Equipe de Scripts), você poderá ler tudo sobre o beisebol do curso secundário, o futebol americano e o basquete universitários e, vez por outra, ficar por dentro da previsão do tempo. (É verdade que só é local se "local" for Redmond para você, mas quem não deseja saber o que se passa com o clima em Redmond?)
E não é só isso, na verdade você aprenderá algo novo sobre script todos os dias. Sim, no meio de todo esse conteúdo instigante existem informações reais sobre scripts. Em cada coluna a Equipe de Scripts responde perguntas reais enviadas por quem eles presumem ser pessoas reais. Você pode ler a coluna diária online em microsoft.com/technet/scriptcenter/resources/qanda. Além disso, como eles já responderam centenas de perguntas, os arquivos são bem amplos e, sendo assim, representam uma grande fonte de informações de script (consulte microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx).
Você tem uma pergunta para a Equipe de Scripts? Você tem chances reduzidas de ter sua pergunta respondida, enviando-a para scripter@microsoft.com. (Por outro lado, você não terá chance nenhuma se não a enviar, sendo assim, o que você tem a perder? Ao contrário de um bilhete de loteria, é de graça e suas possibilidades são ligeiramente maiores).

A Equipe de Scripts da Microsoft trabalha para - bem, estão empregados por ela - a Microsoft. Quando não está jogando/treinando/assistindo beisebol (e diversas outras atividades), ela administra o TechNet Script Center. Confirme isso em www.scriptingguys.com (em inglês).


 Security Watch: Implantando o EFS: Parte 1
Security Watch
Implantando o EFS: Parte 1
John Morello

Todos já ouviram falar sobre relatórios de dados pessoais ou confidenciais perdidos devido ao furto e à perda de laptops. Laptops são perdidos regularmente. Com o roubo de identidade em crescimento e a conformidade a normas mais rígidas do que nunca, a proteção completa de dados em sistemas de computação móvel é essencial.
Uma resposta a isso é o uso de EFS (sistema de arquivos com criptografia) , incluído no Windows® desde o Windows 2000, que oferece criptografia interna de alto desempenho e baseada em disco. O EFS integra-se totalmente ao Windows Explorer, assim, o usuário final geralmente nem saberá quando um arquivo que está sendo usado é criptografado. Além disso, o EFS funciona igualmente bem com tecnologias nativas de autenticação e controle de acesso do Windows, de modo que o usuário final não precisa se lembrar de senhas distintas para acessar os próprios dados. Por fim, o EFS oferece opções gerenciáveis de recuperação de dados em casos onde o usuário pode perder o acesso às chaves de criptografia (por exemplo: quando um nome de usuário é excluído ou danificado ou o cartão inteligente do usuário é perdido).
O EFS usa a tecnologia de criptografia interna do Windows para gerar, armazenar e implantar chaves de criptografia fortes para proteção a dados. No Windows XP Service Pack 1 (SP1) e versões posteriores, o EFS utiliza o algoritmo EAS (Padrão Avançado de Criptografia) com uma chave de 256 bits para criptografar dados em disco. Essas chaves simétricas são então protegidas com um par de chaves assimétricas (RSA). O EFS criptografa cada arquivo com a chave AES; em seguida, criptografa essa chave com a chave RSA do usuário e armazena o resultado no arquivo. Para obter mais informações sobre criptografia EFS, consulte a barra lateral "EFS Resources" Por enquanto focarei não nas bases técnicas do EFS, mas em como implementá-lo e torná-lo viável em seu ambiente. Por esse motivo, o artigo supõe um conhecimento prévio dos conceitos de criptografia EFS.

Uma observação sobre segurança EFS
Existem alguns aplicativos que afirmam ser capazes de decifrar ou romper a criptografia EFS. Nenhum desses aplicativos verdadeiramente descriptografa o texto cifrado criptografado AES (ou o DES, Padrão de Criptografia de Dados, ou o DESX, Padrão de Criptografia de Dados); em vez disso, obtém acesso à chave particular EFS do usuário, usando “brute-forcing” (força bruta) para obter a senha do usuário. O importante a se ter em mente sobre criptografia EFS é que as chaves particulares usadas para gerar e proteger os dados criptografados utilizam a DPAPI (API de Proteção a Dados). A DPAPI usa derivados de credenciais de logon do usuário para proteger dados, assim, o resultado final é que a proteção a dados com o EFS iguala-se à proteção por senha do usuário. Com o Windows Vista™, você agora pode armazenar certificados de criptografia EFS em cartões inteligentes, o que altera esse paradigma e aumenta significativamente a segurança relativa de dados protegidos por EFS.
Qual deve ser o tamanho da senha para que ela seja resistente a esses ataques? Levando em consideração os recursos de hardware e os algoritmos modernos de ataque a senhas da atualidade, uma senha de 11 caracteres ou mais (ou, mais corretamente, uma passphrase (senha)) é o recomendado. Uma senha de 11 caracteres ou mais é altamente resistente aos métodos mais avançados da atualidade, incluindo ataques hash pré-calculados (como a Rainbow Table; consulte a postagem do blog "Why you shouldn't be using passwords of any kind on your Windows networks" (“Por que você não deve usar senhas de qualquer tipo em suas redes Windows”), listada na barra lateral "Recursos", para obter mais informações).

Optar por PKI ou não optar por PKI?
Um dos erros de concepção mais comuns sobre o EFS é que ele requer uma PKI (infra-estrutura de chave pública) para funcionar. Embora o EFS possa integrar-se facilmente e beneficiar-se de uma PKI no caso de a organização já possuir uma, ela não é um requisito. Assim, a decisão quanto a usar ou não uma PKI em sua implantação EFS terá impacto sobre muitas decisões de implantação futuras, portanto, deve ser analisada primeiramente.
A vantagem principal do uso de uma PKI com o EFS é a possibilidade de executar arquivamento e recuperação de chave. Enquanto o EFS sozinho permite aos administradores executar a recuperação de dados, a recuperação de chave só é possível com a PKI e, ainda assim, apenas quando o Windows Server® 2003 Enterprise Edition estiver sendo executado como sua autoridade de Certificação (CA). Recuperação de dados é o processo pelo qual o usuário que perde o acesso à chave de criptografia pode fornecer seus dados criptografados a um administrador designado, conhecido como DRA (Agente de recuperação de dados), que pode, em seguida, descriptografar esses dados e retorná-los ao usuário ou criptografá-los novamente para uso com uma nova chave de criptografia. O DRA funciona como uma sombra para o processo de criptografia do usuário, por meio da qual tudo o que o usuário criptografa com a própria chave é também criptografado com uma cópia da chave DRA. Assim, quando a chave do usuário é perdida, o DRA pode interferir, obter os dados de texto cifrado, aplicar a eles a chave DRA para descriptografia (ou nova criptografia) e, em seguida, retornar os dados ao usuário. A abordagem do DRA funciona bem, mas pode ser difícil de gerenciar se o usuário tiver grandes volumes de dados criptografados ou se não tiver uma equipe de TI local para atuar como DRAs.
A recuperação de chave, por outro lado, requer que a autoridade de certificação faça uma cópia da chave de criptografia do usuário durante o processo de criação da chave e armazene com segurança a cópia dessa chave no banco de dados da autoridade de certificação. Então, quando um usuário perde o acesso a arquivos criptografados, o administrador de autoridade de certificação só precisa recorrer a esse banco de dados e recuperar a chave do usuário. Nesse ponto, o usuário terá acesso imediato a seus dados novamente, sem precisar que o DRA os recupere em seu lugar. Quando feita dessa forma, a recuperação de chave pode ser mais ágil e mais eficiente. Observe, contudo, que a prática recomendada é sempre ter DRAs no local, mesmo quando usar a recuperação de chave, para oferecer um mecanismo de backup em caso de perda da chave. Isso também permite às grandes organizações contar com um sistema de recuperação distribuído, em que administradores de TI locais possam recuperar dados de usuários sem jamais ter que envolver o grupo de administradores de PKI.
Outro benefício potencial de se usar uma PKI com o EFS é facilitar o compartilhamento de arquivos criptografados. Lembre-se de que o EFS não se limita apenas a laptops; ele pode ser igualmente valioso em qualquer situação onde a segurança física do computador não possa ser garantida. Nessas situações, pode haver a necessidade de vários usuários acessarem os mesmos dados criptografados. Embora o suporte do Windows para compartilhamento de arquivos criptografados seja um tanto limitado porque só permite o compartilhamento de arquivos individuais e não de diretórios, ele pode ser uma ferramenta útil. Para facilitar o compartilhamento de arquivos do EFS, o usuário que compartilha o arquivo deve ter acesso às chaves públicas dos usuários com que ele estiver compartilhando (que será mais fácil se esses usuários tiverem um certificado EFS válido publicado na conta respectiva no Active Directory®). Embora seja possível executar essa publicação manualmente, o uso do Windows CA instalado no modo Empresa (integrado ao Active Directory) torna o processo totalmente automatizado.

Gerenciamento de chave EFS
Se você tiver uma PKI baseada no Windows Server 2003 disponível para uso, gerar certificados EFS de usuários será um processo simples. A autoridade de certificação do Windows Server 2003 vem com um conjunto padrão de modelos de certificado, incluindo um modelo chamado EFS básico. Entretanto, esse modelo é um modelo de versão 1 e não oferece suporte a arquivamento de chaves. Portanto, antes de disponibilizá-lo em sua autoridade de certificação, é aconselhável duplicar o modelo para criar um novo modelo de versão 2 (por exemplo, você poderia chamá-lo EFS com Arquivamento de chaves, como mostra a Figura 1). Nesse novo modelo, vá até a guia Tratamento de solicitação e selecione a opção para arquivar a chave de criptografia do usuário. Observe que você precisará configurar o arquivamento de chaves corretamente na autoridade de certificação antes de habilitar essa opção. A seção de recursos inclui uma excelente orientação do processo. Você também deve configurar esse modelo para substituir o modelo EFS básico, a título de garantir que os clientes usarão a nova versão (consulte a Figura 2).
Figura 1 EFS com arquivamento de chaves
Figura 1 EFS com arquivamento de chaves (Clique na imagem para diminuir a exibição)
Figura 1 EFS com arquivamento de chaves
Figura 1 EFS com arquivamento de chaves (Clique na imagem para aumentar a exibição)
Figura 2 Substituir o modelo EFS básico
Figura 2 Substituir o modelo EFS básico (Clique na imagem para diminuir a exibição)
Figura 2 Substituir o modelo EFS básico
Figura 2 Substituir o modelo EFS básico (Clique na imagem para aumentar a exibição)
Em seguida, você precisará configurar as permissões adequadas no modelo, para permitir que o conjunto certo de usuários tenha acesso de registro a ele. Como o componente EFS no Windows solicita automaticamente um certificado na primeira vez que o EFS é usado, você geralmente não precisa permitir que usuários registrem-se automaticamente em relação ao modelo EFS. Na verdade, eu recomendaria contra permitir o registro automático para certificados EFS, a menos que você esteja certo de que todos os usuários registrados automaticamente estarão utilizando o EFS. A Figura 3 mostra as configurações de registro do EFS. Emitindo certificados para usuários que talvez nunca usem o EFS, você estará aumentando o tamanho do seu banco de dados da autoridade de certificação sem nenhum benefício. Embora o banco de dados da autoridade de certificação em si não tenha limite de tamanho, pode ser mais difícil gerenciá-lo (especialmente por meio do Console de gerenciamento Microsoft, ou MMC) quando você aumenta o número de certificados emitidos.
Figura 3 Configurando permissões de usuário do EFS
Figura 3 Configurando permissões de usuário do EFS (Clique na imagem para diminuir a exibição)
Figura 3 Configurando permissões de usuário do EFS
Figura 3 Configurando permissões de usuário do EFS (Clique na imagem para aumentar a exibição)
Por fim, se você precisar dar suporte ao compartilhamento de arquivos criptografados, pode ser conveniente fazer com que a autoridade de certificação publique o certificado do usuário automaticamente no Active Directory.
Após configurar o modelo corretamente na autoridade de certificação, na primeira vez que o usuário criptografar um arquivo com o EFS, ele obterá o certificado de sua autoridade de certificação, e ela arquivará a chave particular desse usuário automaticamente.

Gerenciamento de chave DRA
A próxima questão a considerar se você tiver uma PKI em vigor é usar ou não os certificados DRA gerados pela autoridade de certificação. Por que você não desejaria usar certificados DRA em sua PKI? Considere um cenário onde se tem uma autoridade de certificação emissora com um período de validade de certificado bem pequeno (dois anos ou menos). A autoridade de certificação não será capaz de emitir nenhum certificado com tempos de vida útil mais longos do que o próprio, ou seja, seus certificados DRA teriam (no máximo) um tempo de vida de dois anos. Isso pode resultar em um cenário de recuperação de dados significativamente mais complexo. Esse exemplo hipotético é ilustrado no cenário a seguir.
  1. O usuário criptografa um arquivo em janeiro de 2006; os certificados DRA enviados ao computador desse usuário por meio da Diretiva de Grupo têm um intervalo de tempo de dois anos (expiram em janeiro de 2008).
  2. O usuário continua a trabalhar com o EFS, criptografando novos arquivos.
  3. Em janeiro de 2008 os certificados DRA vencem e o administrador envia novos certificados por meio da Diretiva de Grupo.
  4. Qualquer operação de criptografia desse ponto em diante usará os novos certificados DRA (incluindo qualquer arquivo aberto que era criptografado com os DRAs antigos; uma vez salvos, eles usarão os novos DRAs), mas qualquer arquivo que o usuário não mais alterar ainda estará protegido apenas pelos DRAs antigos.
  5. O usuário danifica o próprio perfil acidentalmente e precisa da recuperação de dados.
  6. O administrador de TI agora precisará dispor de dois conjuntos de certificados DRA: os novos, para todo arquivo alterado desde a Etapa 3, e o antigo, para todo arquivo que não tenha sido alterado desde então.
Embora seja possível para o administrador de TI executar um script após a Etapa 3 para atualizar todos os arquivos com o novo DRA (usando o cipher.exe /u), esse processo pode ser demorado. Além disso, a título de esclarecimento, os pares de chaves DRA não se tornam inúteis após atingirem a data de vencimento, embora o componente EFS não permita nenhuma nova operação de criptografia se um certificado DRA vencido estiver incluído na diretiva de recuperação. É claro que arquivos antigos criptografados com pares de chaves DRA vencidos ainda podem ser recuperados por eles. Portanto, pares de chaves DRA não devem ser descartados nunca, mesmo depois do vencimento do respectivo tempo de vida útil; a verdade é que você não sabe quando precisará utilizá-los.
Por esses motivos, recomendamos que ambientes com autoridades de certificação que dispõem de tempos de vida curtos de certificado empreguem certificados DRA auto-assinados, com tempos de vida mais longos. O utilitário de codificação inclui uma opção (cipher.exe /r) que cria automaticamente pares de chaves do agente de recuperação do EFS, com um tempo de vida de 100 anos (consulte a Figura 4). O certificado desse par de chaves pode então ser anexado aos GPOs (Objetos de Diretiva de Grupo) e usado como um DRA em toda a organização. Como o componente EFS não verifica a cadeia de confiança de certificados DRA, esses certificados auto-assinados funcionarão sem precisar fazer nenhuma alteração à lista de Autoridades de Certificação de raiz confiáveis nos sistemas. Independentemente do tempo de vida da autoridade de certificação de uma organização, sempre recomendo criar pelo menos um certificado DRA de vida longa útil e anexá-lo a um GPO por todo o domínio. Essa é a opção de recuperação de dados fallback a ser usada caso todas as demais opções falhem. Ela é especialmente vital se você estiver usando chaves DRA geradas pela autoridade de certificação na ausência de um arquivamento de chaves de autoridade de certificação. Na ocorrência de um certificado DRA comprometido, você poderá atualizar o GPO com um novo certificado e usar a opção cipher.exe/u, mencionada anteriormente, para atualizar seus arquivos.

Figura 4 Executando o Ciquer /R (Clique na imagem para diminuir a exibição)

Figura 4 Executando o Ciquer /R (Clique na imagem para aumentar a exibição)
Recurso EFS
Obtenha mais informações sobre particularidades e práticas recomendadas do EFS visitando os sites a seguir:
  • Why you shouldn’t be using passwords of any kind on your Windows networks
  • Implementing Key Archival Walkthrough
  • Encrypting File System in Windows XP and Windows Server 2003

Implantação de KRA e DRA
O arquivamento de chaves oferece aos administradores da autoridade de certificação a capacidade de recuperar chaves de criptografia caucionadas em nome do usuário. Obviamente, trata-se de um recurso muito confidencial e eficiente, porque pode permitir que um administrador de autoridade de certificação descriptografe qualquer dado que utilize uma chave assinada pela autoridade de certificação na organização. O arquivamento e a recuperação de chave, portanto, devem ser tratados com cuidado e apenas um pequeno número de pessoas confiáveis ligadas à segurança devem receber essa permissão. Em razão da natureza confidencial da recuperação de chave, se você desejar contar com esse recurso como o mecanismo principal de reobtenção de acesso a dados criptografados por EFS, é importante ter um processo de escalonamento claramente definido para que solicitações de recuperação sejam enviadas à sua equipe de administração da autoridade de certificação. Só depois que a solicitação tiver sido cuidadosamente verificada o processo de recuperação será iniciado. Então, após a chave ser recuperada efetivamente, ela deverá ser fornecida ao usuário, por um método seguro (ou seja, não por email), porque a chave recuperada oferece acesso a todos os dados protegidos por EFS do usuário.
As chaves do Agente de Recuperação de Chave ou KRA são geradas e mantidas pelos administradores da autoridade de certificação e não são divulgadas pela Diretiva de Grupo. Na verdade, o próprio EFS não pode determinar se uma chave que ele utiliza foi ou não arquivada; ele simplesmente executa as operações de criptografia, como normalmente o faria. Além disso, as chaves KRA criadas na autoridade de certificação não são específicas de forma nenhuma do EFS. Uma autoridade de certificação que use o arquivamento de chaves terá um número n de chaves KRA anexadas no nível da autoridade de certificação que serão usadas para proteger qualquer chave arquivada pela autoridade de certificação. Essas chaves podem incluir as chaves usadas com o EFS, email seguro ou qualquer outra finalidade de certificado que inclua criptografia. As chaves do KRA devem ser armazenadas de modo seguro pelos agentes de recuperação de chave individuais, e deve haver pelo menos dois KRAs usados para fornecer fallback em caso de perda de uma das chaves.
Na primeira vez que um administrador fizer logon no controlador de domínio de um domínio recém-criado, uma diretiva de recuperação padrão será criada no nível do domínio, usando um certificado auto-assinado e um par de chaves armazenado no perfil do administrador, no controlador de domínio. Esse certificado DRA terá um tempo de vida útil de três anos. A abordagem recomendada é remover esse certificado padrão e substituí-lo por certificados auto-assinados com vida útil mais longa ou certificados emitidos em sua PKI. Se você não remover esse certificado auto-assinado padrão, três anos após a criação dele o EFS deixará de criptografar novos arquivos em todo o seu domínio. Isso ocorre porque o certificado terá vencido e o EFS impedirá a criptografia de todos os dados posteriores quando um certificado DRA for incluído em sua diretiva de recuperação. Embora seja possível operar o Windows XP e sistemas posteriores sem nenhuma diretiva de agente de recuperação em vigor, isso é altamente desencorajado. Fazer isso significa que, se o usuário perder o acesso à chave de criptografia por algum motivo e a recuperação de chave não for possível, todos os dados desse usuário serão irremediavelmente perdidos.
Conforme dissemos anteriormente, chaves DRA podem ser auto-assinadas ou emitidas de uma autoridade de certificação. Na maioria dos casos, uma abordagem híbrida é melhor, com pelo menos dois DRAs de vida útil longa e auto-assinados, usados em toda a empresa como um agente de recuperação de último recurso. Como os certificados DRA são implementados por meio dos Objetos de Diretiva de Grupo, eles possuem os mesmos recursos de herança de outros GPOs. Em outras palavras, o algoritmo de acumulação e aplicativo padrão de GPO Local, de Site, Domínio e UO que controla o aplicativo de outras configurações do GPO também se aplica aos DRAs. Portanto, uma organização pode implementar facilmente uma abordagem em camadas, onde o grupo de TI central tenha acesso ao DRA em qualquer lugar da empresa, mas onde grupos de TI locais também mantenham a capacidade nas respectivas áreas específicas de responsabilidade. Trata-se de um ativo especialmente valioso em organizações de grande porte e dispersas geograficamente, porque minimiza a necessidade de transferir grandes volumes de dados criptografados por links WAN, para facilitar a recuperação de dados. A Figura 5 ilustra uma implantação DRA típica com várias camadas.
Figura 5 Implantação DRA em várias camadas
Figura 5 Implantação DRA em várias camadas
Neste caso, um usuário da UO Baton Rouge acabaria com seis DRAs para cada arquivo criptografado: dois dos administradores locais, dois do grupo de TI da América do Norte e dois do nível do domínio. Assim, se o usuário perdesse o acesso aos dados criptografados, ele poderia recuperá-los em um DRA local no Baton Rouge ou no grupo de TI da América do Norte. Como fallback final, se esses quatro DRAs estivessem indisponíveis ou fossem perdidos, os DRAs no nível do domínio poderiam igualmente assumir e recuperar os dados. Independentemente do DRA que executou a recuperação, o processo seria essencialmente o mesmo. O usuário primeiramente disponibilizaria os dados para o DRA. É importante que o DRA cumpra as etapas necessárias para garantir que a solicitação é legítima e se origine do verdadeiro proprietário dos dados. Uma vez feito isso, o DRA carregaria o certificado DRA, descriptografaria os dados (e, de preferência, faria uma nova criptografia) e, em seguida, os enviaria de volta ao usuário final. Algumas organizações também optam por executar a recuperação local, em que o DRA visitaria fisicamente o usuário com problema, carregaria o par de chaves DRA desse usuário no perfil e, então, descriptografaria os dados e removeria o par de chaves. O usuário teria então acesso aos dados em formato não criptografado e poderia criptografá-los novamente, com uma nova chave. Deve-se observar que essa abordagem é muito menos segura, pois o par de chaves DRA é copiado (embora temporariamente) no computador local; apesar disso, pode economizar algum tempo, especialmente se um grande volume de dados deve ser recuperado.
Observe que, se a recuperação fosse fornecida ao usuário por meio de arquivamento e da recuperação de chave, a solicitação de recuperação seria manipulada inteiramente à parte desse processo. Em vez de usar o DRA, a solicitação de recuperação de chave do usuário iria para os administradores da autoridade de certificação, que deve verificar a solicitação; em seguida, iria para o arquivamento e recuperaria a chave particular do usuário. Eles então disponibilizariam essa chave particular para o usuário, de maneira segura, como, por exemplo, colocando-a em um site seguro para ser obtida por download. (Se o usuário estivesse se beneficiando de um cartão inteligente para armazenar a chave EFS, disponível com o Windows Vista, essa chave também precisaria ser emitida novamente). O usuário carregaria a chave no perfil respectivo e, em seguida, teria acesso imediato a todos os dados criptografados.
Como os pares de chaves DRA e KRA podem ser usados para descriptografar dados confidenciais, é importante que eles sejam bem protegidos. Os pares de chaves DRA e KRA não devem ser armazenados nos perfis de área de trabalho normal de administradores (perfis em que eles executam as respectivas atividades diárias normais). Em vez disso, esses pares de chaves devem ser armazenados de maneira segura, offline, em mídia tipo disquete, ótica ou flash, mantida em um local fisicamente seguro. Quando então a recuperação se fizer necessária, o agente de recuperação poderá carregar o par de chaves em uma estação de trabalho de recuperação a partir dessa mídia, executar a operação de recuperação e, em seguida, remover o par de chaves. Em algumas organizações especialmente sensíveis à segurança, são criadas estações de trabalho dedicadas de recuperação, para aumentar ainda mais a segurança desses pares de chaves. Isso, no entanto, não é um requisito de todas as organizações.

Da próxima vez
Agora que examinamos o gerenciamento de chave, a recuperação de dados e os aspectos do Active Directory relacionados ao planejamento, focarei nas questões de implantação do cliente, na Parte 2 deste tópico, a ser liberada no próximo mês. Na ocasião, abordarei tópicos como o controle de uso do EFS por meio de Diretiva de Grupo, a escolha do que criptografar, a criptografia automática de dados através de scripts de logon e os aprimoramentos do lado do cliente no Windows Explorer, para tornar mais fácil o trabalho de dados protegidos por EFS.

John Morello graduou-se com louvor na LSU (Universidade do Estado da Louisiana) e trabalha na Microsoft há seis anos, em várias funções. Na condição de consultor sênior, Morello criou soluções de segurança para as empresas da Fortune 100 e clientes civis federais e da defesa. Atualmente, ele é gerente de programa do grupo Windows Server e trabalha em segurança e tecnologias de acesso remoto.


 Os arquivos da &#225;rea de trabalho: Estendendo o Windows PE
Os arquivos da área de trabalho
Estendendo o Windows PE
Wes Miller

Antes mesmo de lançarmos o Windows PE há cinco anos, clientes ansiosos já pediam mais recursos. Infelizmente, o Windows PE não foi criado para ser estendido facilmente, conforme, digamos, o Windows XP Embedded pode ser: acrescentando-se camadas adicionais do sistema operacional. É claro que o Windows PE tinha que ter suporte
rudimentar ao Win32® (para que a maioria dos aplicativos Windows® pudesse funcionar) e suporte de rede e armazenamento em massa (para se comunicar pela rede e poder instalar o Windows). Mas, mesmo desde o início, desejávamos restringir o shell. Usando o cmd.exe em vez do shell do Windows Explorer tradicional, limitamos as ações do ambiente Windows PE e, mais importante, fizemos isso de forma que o ambiente padrão fosse facilmente programável por scripts em todas as tarefas de automação.
Ainda assim, você poderá estender o Windows PE; basta apenas lembrar-se de que ele é limitado. Você pode esperar que o seu aplicativo talvez não funcione ou se comporte incorretamente se ele requerer alguma das tecnologias listadas na Figura 1 (essa lista não é abrangente).
Figure 1 APIs ausentes do Windows (Close Figure 1)

.NET Framework (qualquer versão)
Interfaces de Serviços do Active Directory ® (ADSI)
DirectX®
Microsoft Data Access Components (MDAC)
Jet (Acess)
Visual Basic® (versõs .NET anteriores incluídas)
Todo tipo de executável que exija uma estrutura que não esteja instalada nativamente com o Windows.
Windows Explorer ou Internet Explorer
Windows Media Player®
SAPI, MAPI, TAPI (APIs de fala, email e telefonia do Windows, respectivamente)
Se você não sabe do que depende o seu aplicativo, precisará descobrir. Mas como? Quando tentamos fazer com que os componentes ADO, HTA (aplicativos HTML) e WSH (Host de Scripts do Windows) funcionassem no Windows PE antes de o lançarmos, nós nos deparamos com o mesmo problema. Observe, no entanto, que, embora este artigo descreva maneiras de rastrear essas dependências, adicionar qualquer binário do Windows à imagem do Windows PE, além do que o comando MKIMG inclui, não é coberto pelo EULA (Contrato de Licença de Usuário Final). Você precisará adquirir um adendo de licença da Microsoft para implementar alterações dessa natureza em seu ambiente.

Noções básicas sobre dependências
Se você abrir um arquivo .inf do aplicativo no Bloco de Notas e examiná-lo cuidadosamente, poderá aprender muito. Na verdade, geralmente essa é a maneira mais fácil de se compreender um aplicativo e ver que dependências ele possui. O importante a saber sobre o Windows PE é que geralmente ele é tão mais simples que você terá que depurar vários níveis de dependências: as dependências diretas próprias do seu aplicativo e as dependências que cada um deles possa apresentar para fazer com que o aplicativo seja executado de forma confiável. Essencialmente, pode ocorrer uma cascata muito grande de dependências se você não for cuidadoso. Com algumas adições de componentes acidentais (ou intencionais), sua imagem pode crescer consideravelmente em tamanho e complexidade.
Se você já tiver um arquivo .inf que descreva o aplicativo, poderá obter indícios sobre as dependências, localizando chaves e arquivos do Registro que o .inf adiciona ao sistema. Procure as seções CopyFiles e AddReg. Essas entradas apontarão para aplicativos, DLLs e outros arquivos de que o seu aplicativo depende. Dos três suplementos do Windows PE (ADO, HTA e WSH), o WSH foi o mais simples de se criar. Como uma versão redistribuível do WSH ainda estava disponível para versões mais antigas do Windows e por haver um .inf interno no Windows atual que executa as associações de arquivo no WSH (em %windir%\inf\wsh.inf), instalá-lo no Windows PE foi relativamente fácil.

Orca e Instantâneo
Se o aplicativo em questão for distribuído como um arquivo Microsoft® Installer (MSI), você poderá localizar dependências de duas formas: Se você for um guru de MSI, poderá usar a Orca (uma ferramenta de edição dos arquivos do instaladores do Windows, distribuída como parte da plataforma SDK do Windows Server® 2003 R2: go.microsoft.com/fwlink/?LinkId=77941) para exibi-la. Você também pode instalar o MSI nos componentes que desejar, executando uma análise de antes e depois nos arquivos e nas chaves do Registro que foram alterados. Você pode fazer um despejo do Registro, instalar o aplicativo, exportar o Registro novamente e, em seguida, executar o WinDiff nele (consulte a barra lateral “Using WinDiff"). O resultado pode então ser usado como um modelo para as alterações que precisam ser feitas ao Registro. O problema é que o número de alterações pode se tornar confuso. No entanto, essa pode ser a melhor opção se você não tiver um .inf (ou o autor do aplicativo) à mão.
Talvez você esteja familiarizado com o processo de instantâneo do aplicativo. É basicamente o mesmo da análise de antes e depois que se realiza para executar o aplicativo. A Microsoft distribuía (com o Windows 2000) uma ferramenta que fazia isso, mas essa ferramenta não funciona mais com as versões mais recentes do Windows. Vários aplicativos comerciais (reempacotadores de instalação) podem fazer isso, mas alguns utilitários gratuitos também o fazem. Para uma solução, instale a Plataforma SDK (veja o link no parágrafo anterior), que inclui o WinDiff. Observe que, para executar a comparação WinDiff, talvez seja conveniente instalar o aplicativo no Windows Server 2003 com o Service Pack 1 (SP1) porque essa é a versão do Windows PE que você deve estar usando: Windows PE 1.6 criado com base no Standard Edition ou Enterprise Edition (com o SP1). Realizando essa tarefa no Windows Server 2003 você obterá o ambiente mais próximo daquele que obteria no Windows PE (onde obviamente você não pode executar um MSI) Siga as etapas na barra lateral “Using WinDiff”.
Isso lhe mostrará um volume razoável de informações que foram alteradas. Infelizmente não existe um modo fácil de exportar as informações alteradas de capturas de Registro ou de arquivo para criar um manifesto de algum tipo para instalar seu aplicativo. Você terá que incorporar as alterações manualmente. É aí que encontramos alguns dos problemas mais difíceis com a primeira versão do Windows PE. Fazer com que os componentes HTA funcionassem era complexo, porque não havia nenhuma definição para eles (fora do Internet Explorer®) na Microsoft. Ao usar a diferenciação, conseguimos inserir manualmente suporte HTA suficiente para que ele funcionasse. Embora seja possível adicionar manualmente essas chaves ao Registro do Windows PE, pode ser que você deseje adicioná-las após o Windows PE ter iniciado. Você pode olhar nos arquivos OC.bat e OC2.bat usados para instalar o HTA, WSH e/ou o suporte ADO no Windows PE por meio do script buildoptionalcomponents.vbs incluído nas ferramentas de compilação do Windows PE.

Ferramentas úteis
Mesmo após isolar as dependências diretas, geralmente não se consegue localizar todo binário de que o seu aplicativo depende. Você não saberá, por exemplo, se ele requer outra DLL ou outro OCX para executar uma tarefa. Então, como saber a diferença? Mark Russinovich, celebridade da Sysinternals (atualmente um parceiro técnico na Microsoft) escreveu um utilitário prático chamado listdlls que faz exatamente isso. O listdlls pode ser baixado do site Microsoft.com/technet/sysinternals/utilities/ListDlls.mspx. Para usar o utilitário, execute o comando listdlls.exe > dlls.txt e, depois, examine a saída. A Figura 2 mostra a saída de execução do listdlls por si própria. Você pode comparar essa lista com os arquivos DLL e OCX incluídos no Windows PE para determinar se todas as dependências do aplicativo estão em vigor ou não (no caso do listdlls, elas já estão presentes). Para o suporte HTA no Windows PE, o comando listdlls foi fundamental na identificação de algumas dependências que, do contrário, não poderiam ser identificadas.
Figura 2 Saída do comando Listdlls executada por si própria
Figura 2 Saída do comando Listdlls executada por si própria (Clique na imagem para diminuir a exibição)
Figura 2 Saída do comando Listdlls executada por si própria
Figura 2 Saída do comando Listdlls executada por si própria (Clique na imagem para aumentar a exibição)
Mas só porque uma DLL está listada não significa necessariamente que seja requerida para que o aplicativo funcione. Se você carregar o Bloco de notas, por exemplo, verá que ele carrega o uxtheme.dll. No Windows PE, essa DLL não está disponível e, na verdade, como os temas do Windows não são usados, ela nunca será carregada. Infelizmente é difícil saber, dentre as DLLS mostradas pelo comando listdlls, aquelas de que você realmente precisa versus aquelas que são carregadas por demanda. Isso exigirá de uma boa dose de tentativa e erro, ou que você se familiarize bastante com aspectos de nível inferior do Windows. (Para isso, recomendo o livro de Mark Russinovich e David Solomon, Microsoft Windows Internals, Quarta Edição (Microsoft Press®, 2004).
Na verdade, Mark, também inclui a mesma funcionalidade na substituição gratuita disponível do Process Explorer do Gerenciador de tarefas do Windows. A diferença é que o listdlls cria uma saída que, em minha opinião, é mais facilmente incluída em um script e usada para localizar e coletar dependências ausentes.
Observe que, mesmo após adicionar uma DLL à sua imagem, ainda haverá algum trabalho a ser feito. Ou seja, existem dois tipos de DLLs: as que requerem registro e as que não requerem. Infelizmente, não há uma maneira fácil diferenciá-las sem tentar registrar cada uma delas. Para registrar uma DLL (ou um OCX), execute o comando regsvr32 dllname.dll. Se funcionar corretamente, uma caixa de diálogo informará que a DLL foi registrada. Do contrário, talvez você não receba uma mensagem ou, mais provável, uma caixa de diálogo informará que houve falha ao registrar a DLL ou que ela não pôde ser registrada. Durante o desenvolvimento dos componentes opcionais HTA e ADO do Windows PE, descobrimos que DLLs requerem armazenamento gravável quando da execução de seus registros, seja para gravar temporariamente um arquivo .inf de instalação ou para registrar alguma outra dependência (digamos, um diretório especifico de que necessitem). No Windows PE, isto significa falha. Felizmente, com o Windows PE 2.0 tarefas como essas funcionarão, pois existe um espaço transitório disponível por padrão.
Uma terceira ferramenta criada por Mark e lançada recentemente chama-se Process Monitor. O Process Monitor pode ser visualizado como um superconjunto de Regmon e Filemon, embora forneça mais detalhes do que ambos, ao adicionar uma camada nova inteira de comunicação entre processos. Essa ferramenta incrivelmente eficiente pode ajudá-lo a solucionar problemas de aplicativos no Windows, além de ajudar a responder perguntas sobre o que de fato está acontecendo com as interdependências de DLL. O Process Monitor pode ser baixado.

Removendo arquivos do Windows PE
Junto com a capacidade de adicionar itens ao Windows PE, outra solicitação freqüente era por instruções sobre como tornar o Windows PE menor. Há etapas que você pode percorrer para reduzir um pouco o tamanho do Windows PE. Sua cópia licenciada do Windows PE deve incluir uma coleção de ferramentas de compilação e alguma documentação. Um dos documentos é um arquivo de ajuda chamado winpe.chm. Se você abrir esse arquivo e explorar a seção Guia do Usuário do Ambiente de Pré-instalação do Windows, verá um tópico intitulado Reduzindo o Tamanho do Windows PE. Essa seção lista uma coleção de arquivos que você pode remover com segurança (supondo que você não precise deles). Você encontrará três seções relacionadas aos arquivos removíveis:
  • Os arquivos de fonte podem sempre ser removidos com segurança.
  • Arquivos .inf e utilitários relacionados à rede podem ser removidos, mas remova-os somente se você não planeja, de maneira nenhuma, usar sua compilação na rede.
  • Os utilitários de linha de comando não devem ser removidos. Não recomendo a remoção de nenhum deles, a menos que você saiba exatamente o que ele faz e o que pode acontecer se o remover.
Depois de determinar que arquivos podem ser excluídos com segurança, você pode simplesmente gravar um arquivo em lotes ou outro script e removê-los da sua compilação do Windows PE, após o mkimg.cmd concluir a compilação.

Modificando o Registro do Windows PE
Você pode observar que fizemos uma escolha consciente de não instalar os componentes opcionais no momento da compilação. Embora isso tenha significado um pouco mais de tempo na execução, também significou que não tivemos que projetar uma nova maneira de inserir estes componentes de volta no Windows PE - algo que não tínhamos tempo para fazer e que, provavelmente, significaria omiti-los por completo. Mas e se você desejar fazer uma alteração no Registro, como, por exemplo, adicionar ao delta do Registro alterações do seu aplicativo, ou simplesmente editar uma chave que possa manter o aplicativo em funcionamento? Isso é fácil de se fazer, por meio do regedit, mostrado na Figura 3. Siga estas etapas:
  1. Execute o regedit e selecione o hive HKEY_LOCAL_MACHINE.
  2. Selecione File | Load Hive e, em seguida procure o local de sua compilação do Windows PE. Selecione setupreg.hiv em I386\System32\ (ou MiniNT\System32, se for uma imagem o que você estiver colocando no disco rígido).
  3. Insira um nome temporário para o hive, como WinPE, e procure esse nó em HKLM.
  4. Modifique essa chave adequadamente. Curiosamente, observe que este nó é, na verdade, o mesmo que seria o nó HKLM\System em uma instalação normal do Windows.
  5. Depois de fazer as modificações, selecione a chave em HKLM criada na Etapa 3 (é muito importante fazer isso da maneira correta ou o sistema poderá sair danificado).
  6. Selecione File | Unload Hive... e confirme na caixa de diálogo Sim | Não; certifique-se de desmontar o Registro sempre, uma vez que, se ele estiver bloqueado, isso impedirá que a compilação do Windows PE tenha êxito.
Figura 3 Abrindo o Registro do Windows PE
Figura 3 Abrindo o Registro do Windows PE (Clique na imagem para diminuir a exibição)
Figura 3 Abrindo o Registro do Windows PE
Figura 3 Abrindo o Registro do Windows PE (Clique na imagem para aumentar a exibição)
Seguindo estas etapas você poderá modificar o HKLM\System. Existem também duas outras chaves localizadas em I386\System32 que permitem modificar outras áreas do Registro. DEFAULT é o hive padrão para usuários (até SYSTEM, executado durante o uso do Windows PE) e SOFTWARE, que equivale a HKLM\Software. Como sempre, modifique o Registro com cuidado e somente quando necessário.
Agora você já tem algumas informações que deverão ajudá-lo a começar a transferir suas soluções de problemas ou ferramenta de recuperação favorita para o Windows PE. No mês que vem falarei sobre o conjunto PStools, uma coleção de ferramentas de gerenciamento de sistema muito úteis, também escrito por Mark Russinovich.
Usando o WinDiff
O WinDiff pode ajudá-lo a encontrar as dependências do seu aplicativo. Basta seguir estas etapas para obter uma instalação e uma execução bem-sucedidas.
  1. Prepare o seu sistema para a instalação: você deseja minimizar o tempo e qualquer alteração no Registro ou ao arquivo entre os instantâneos inicial e final.
  2. Abra um prompt de comando e execute o comando reg export HKLM C:\HKLM1.reg para realizar uma exportação completa do hive do Registro HKEY_Local_Machine.
  3. Execute dir C:\*.* /S > C:\C1.txt para realizar um despejo completo de todos os arquivos da unidade C: (supondo que C: é a sua unidade de sistema).
  4. Instale o seu aplicativo e defina todas as configurações pós-instalação.
  5. Execute o reg export HKLM C:\HKLM2.reg.
  6. Execute dir C:\*.* /S > C:\C2.txt.
  7. Abra o WinDiff, selecione File | Compare Files... e selecione HKLM1.reg na primeira caixa de diálogo Abrir arquivo e HKLM2.reg, na segunda.
  8. Você verá uma mensagem em vermelho indicando qual é o mais recente. Seja paciente; a ação talvez leve algum tempo, pois as exportações do HKLM podem ser muito grandes.
  9. Clique duas vezes no texto em vermelho para expandir as diferenças.
  10. Talvez seja conveniente configurar o que será mostrado na comparação, selecionando Options | Show Right-Only Lines. Isso permitirá mostrar apenas as linhas adicionadas recentemente ao segundo arquivo comparado (assim, apenas os novos arquivos e as novas chaves do Registro serão exibidos).
Observe que talvez seja necessário usar a função Localizar para localizar as chaves relacionadas ao seu aplicativo. Nas Figuras A e B, você poderá ver as alterações de arquivo e de Registro a um aplicativo fictício que eu criei. Felizmente, os comandos copiar e colar estão disponíveis no WinDiff. Para usar essas funções basta clicar na linha !> e selecionar as linhas desejadas.
Figura A Entradas WinDiff
Figura A Entradas WinDiff (Clique na imagem para diminuir a exibição)
Figura A Entradas WinDiff
Figura A Entradas WinDiff (Clique na imagem para aumentar a exibição)
Figura B Chave específica do WinDiff
Figura B Chave específica do WinDiff (Clique na imagem para diminuir a exibição)
Figura B Chave específica do WinDiff
Figura B Chave específica do WinDiff (Clique na imagem para aumentar a exibição)

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


 Anota&#231;&#245;es de campo: Ele simplesmente p&#225;ra de funcionar
Anotações de campo
Ele simplesmente pára de funcionar
R'ykandar Korra'ti

"NÃO SEI, Eu, simplesmente, sou desconectada."
"Qualquer hora do dia? Acontece quando você faz alguma coisa específica? Alguma máquina específica de onde você se conecta?"
"Não. Estou conectada e, então, não estou. Pronto! Já era."
"Você sabe que isso não me fornece muita informação com que trabalhar. Vamos lá, me diga alguma coisa. Uma dica, um indício, alguma coisa."
"Contei a você tudo o que eu sei. Às vezes eu simplesmente sou desconectada. Você pode corrigir esse problema?"
Eu disse a ela que trabalharia nele. Não existe muito nos logs de roteador, mas nosso tráfego é interrompido vez por outra, indicando que algo está errado – mas por apenas um ou dois minutos por vez, após o que tudo volta ao normal. Nenhum erro, nenhum padrão, simplesmente por vezes não há nenhum tráfego. É estranho. Então temos sorte:
Ring Ring soa o telefone anexado ao DSL.
Thunk Die vai-se a nossa conexão IP.
Você está brincando comigo, penso. E, ainda assim, ela reproduz: se alguém liga para o número de telefone DSL, o único que ninguém usa e sobre o qual não se espera que ninguém saiba, nossa conectividade cai. O ponto de venda de serviços número um da companhia telefônica , a maior calamidade com que eles alegam que você nunca terá que se preocupar, acontece – em detalhes flamejantes e cintilantes.
E, apesar disso, estamos a apenas 270 metros da subestação. Isso não deveria estar acontecendo. Verifico cabos, redefino tudo e até limpo as conexões para ver se isso ajuda. Mas, é claro que não. Então, ligo para a companhia telefônica. "Como é que vocês prometem que nunca haverá interrupção da conexão por uma ligação telefônica recebida? Adivinha o que está acontecendo. Podemos ser ludibriados por operadores de telemarketing."
Talvez seja o cobre ...
Talvez seja o cobre ...
Um técnico vem no dia seguinte e descobre que, inexplicavelmente, testamos a mais de 915 metros distante da subestação, tão distantes que um esquilo raivoso poderia nos cortar com uma pequena bússola. No final, descobrimos que, no passado, quando o cabeamento da vizinhança foi feito, todas as linhas telefônicas foram agrupadas e cada linha foi enviada para todos os edifícios no quarteirão; a idéia era evitar jamais ter que passar um novo cabo. Tudo bem se o seu mundo inteiro é de voz analógica, mas do ponto de vista de um DSL, cada polegada linear dessas ramificações conta como distância da subestação, enfraquecendo a sua intensidade do sinal.
Felizmente, o problema teve uma correção rápida e fácil. Todas as ramificações laterais da linha foram desconectadas e uma anotação dizia, "NÃO RECONECTE. PORÇÃO DSL EM USO." Tchã-nan! Uma distância de apenas 270 metros, um sinal muito mais forte e, mais importante, sem perda da operadora em toques.
Moral da história: não presuma que um problema de conexão é esotérico ou mesmo que seja causado pelo software. Às vezes é apenas uma questão de fio de cobre. Faça com que os técnicos da companhia telefônica verifiquem constantemente a força real do sinal DSL na instalação, ainda que eles tenham certeza de que não é necessário; nunca se sabe o que mais pode estar pendurado lá, só esperando para confundi-lo mais tarde. E não os leve ao pé da letra com relação à distância até a subestação. Você não tem idéia de onde possam ir esses cabos, e nem eles. Descubra. Eles têm as ferramentas e as tecnologias: faça-os usá-las. Você ficará satisfeito de tê-lo feito. Especialmente depois que operadores de telemarketing descobrirem o seu número DSL.

R'ykandar Korra'ti, postmaster de um pequeno ISP cooperado, vive perto de Seattle com sua amiga, Anna. Tendo anteriormente fornecido produtos para email na Microsoft, ela agora está considerando uma graduação em um campo tão hermético que não tem efetivamente nem um nome. Orientadores potenciais podem contatá-la pelo email darako@murkworks.net.


 Segredos do Windows: Uma &quot;mistura&quot; aben&#231;oada
Segredos do Windows
Uma "mistura" abençoada
Raymond Chen

Quando você insere um CD ou DVD , o shell "fareja" o disco, para determinar que tipo de conteúdo reside nele. Essa determinação então orienta o shell na decisão sobre que ação de execução automática ele deve executar. Os detalhes precisos de como o farejamento é feito não são documentados, pois são heurísticos que podem ser alterados no futuro, se um algoritmo melhor for encontrado.
Documentar o algoritmo formalmente o tornaria contratual, evitando, dessa forma, que o algoritmo fosse ajustado em versões subseqüentes. Oficialmente, portanto, os detalhes do algoritmo são deixados sem especificação.
Se você nunca escreveu a documentação de um SDK, talvez não tenha percebido que a documentação leva ao contrato. Depois que você registra que algo se comporta de uma determinada maneira, não pode mudar isso. Se você o fizer, pessoas que contavam com esse comportamento dirão, "Ei, não é isso o que diz a documentação. Você está mudando as regras depois do início do jogo."
Com essa limitação fora do caminho, eis uma descrição rápida e incrivelmente supersimplificada de como o Windows® XP Service Pack 2 (SP2) categoriza o conteúdo de CDs de dados e DVDs de dados que não têm um arquivo autorun.inf. (Service packs futuros e futuras versões do Windows poderão comportar-se de modo diverso). Digo "incrivelmente supersimplificada" porque o algoritmo real é uma tabela de decisão de 61 etapas que leva em conta todos os tipos de informações, como: se o aplicativo de primeiro plano respondeu à notificação "Query cancel autoplay", se um programa de tela cheia está em execução e até se o computador é um laptop que foi encaixado ou desencaixado recentemente. Eu, no entanto, vou analisar apenas a etapa de farejamento de conteúdo.

Primeiro, o shell verifica se o usuário especificado "Não toma nenhuma atitude" como atitude em relação a todos os tipos de conteúdo. Em caso positivo, não há por que farejar. A decisão é simplesmente "Não tomar nenhuma atitude".
Do contrário, o shell tem algo a fazer. Ele olha em cada arquivo do disco – até quatro diretórios de profundidade – e os coloca em uma das categorias a seguir, com base nos respectivos tipos percebidos: imagem, música e filme.
Os arquivos que não se encaixam em uma dessas categorias são ignorados. Se apenas uma categoria for representada entre todos os arquivos que foram verificados (digamos, por exemplo, todos os arquivos no disco são arquivos de música), isso estabelece o tipo de disco. Se mais de uma das três categorias forem representadas, o disco é considerado de conteúdo misto.
Isso significa que a arte do álbum em seu CD cheio de arquivos de música fará com que o CD seja tratado como conteúdo misto pelo Windows XP SP2. Isso é um dos fatores que provavelmente poderia comportar algum ajuste. Mas, suponhamos que esse algoritmo tenha sido ajustado e nós decidimos que uma imagem ocasional em um CD cheio de MP3s não deve desequilibrar o conteúdo misto. Alguma empresa pode ter um CD com muitos arquivos de áudio e apenas algumas imagens nele. A empresa efetivamente confia que o CD será detectado como de conteúdo misto. Mas, quando o algoritmo é alterado, o CD é categorizado erroneamente como sendo de música. Agora a empresa fica aborrecida. Mas quem é o culpado por esse problema? A empresa pode ser culpada por confiar nos detalhes do algoritmo de farejamento? Ou o Windows é culpado, já que ele é o responsável pela alteração do algoritmo?
Pasme! No Windows Vista™, o algoritmo foi alterado, embora apenas um pouco. No Windows Vista, diversas verificações foram feitas de antemão para dar um curto-circuito no algoritmo de determinados layouts de disco bem conhecidos. Por exemplo, se uma pasta DCIM estiver presente na raiz do disco, presume-se que essa pasta consista em imagens digitais. Agora vamos aguardar para ver se alguém irá observar.

Raymond Chen, The Old New Thing, e o livro, de título idêntico (Addison-Wesley, 2007) tratam da história do Windows e da programação Win32. Raymond reflete sobre como pode ser o sol.