 TechNet Magazine April 2007
TechNet Magazine April 2007
APRIL 2007
Administração do Windows

Nesta edição, Mark Russinovich aborda mais uma vez o kernel do Windows Vista, a fim de examinar os aprimoramentos em segurança, confiabilidade e recuperação. A recuperação do Active Directory também é um dos principais temas abordados neste mês. Em vez de reagir em uma emergência, tenha previamente preparado um plano de recuperação do Active Directory. Finalmente, antes de decidir que o Windows XP Embedded não é adequado para a sua empresa, continue a leitura – você se surpreenderá!

Gerenciamento

Como você atinge o equilíbrio ideal entre a capacidade de hardware e a relação custo benefício? Neste mês, saiba como o System Center Capacity Planner permite que você molde os requisitos da sua infra-estrutura de acordo com o plano. Além disso, saiba como combinar o Systems Management Server, o WMI e uma parte de script para obter um melhor relatório de inventário cliente, bem como implantar atualizações personalizadas com o SMS.
RECURSOS
Administração do Windows Dentro do kernel do Windows Vista: parte 3

Nesta edição, concluiremos nossa minuciosa discussão sobre as novidades do kernel do Windows Vista. Nesta parte final, analisaremos as alterações e os novos recursos pertinentes à confiabilidade, recuperação e segurança.

Mark Russinovich Recuperação de desastres: usuários e grupos do Active Directory

A recuperação de dados no Active Directory pode ser muito complexa, ainda assim é essencial que você tenha um plano de recuperação preparado. Mostraremos como o Active Directory armazena, exclui, restaura e replica objetos, para que você esteja preparado na próxima vez que uma associação de grupo ou usuário for acidentalmente excluída.

Gil Kirkpatrick Por que o Windows XP Embedded é importante para você

Embora você possa não saber, o Windows XP Embedded pode ser uma excelente solução para a disponibilidade de TI da sua empresa. Saiba como o Windows XP Embedded pode reduzir a sua sobrecarga administrativa, economizar o seu dinheiro e melhorar a segurança.

Don Jones Gerenciamento Planeje com antecedência com o System Center Capacity Planner

A insuficiência de hardware ocasiona tempos insatisfatórios de resposta, enquanto o hardware em excesso representa perda de orçamento e de recursos administrativos. Saiba como você pode usar o System Center Capacity Planner para moldar a sua rede e estimar com precisão as suas necessidades de infra-estrutura.

John Savill Inventários avançados de cliente com o SMS

O Microsoft Systems Management Server 2003 coleta prontamente várias informações, mas não coleta a quantidade exata que você precisa. Saiba como a combinação ideal do conhecimento de script, WMI e SMS pode ajudar a expandir inventários do SMS, a fim de coletar e relatar praticamente qualquer parte da informação.

Wes Dobry Implantando atualizações personalizadas de software com o SMS 2003 R2

O Systems Management Server 2003 R2 permite que você utilize os recursos de atualização gerenciada para implantar atualizações personalizadas. Explore duas novas ferramentas – a Ferramenta de Estoque para Atualizações Personalizadas e a Ferramenta de Edição de Atualizações Personalizadas – e veja como elas podem ajudá-lo a implantar as suas próprias atualizações, bem como atualizações de desenvolvedores de terceiros.

Steve Rachui
COLUNAS
Do editor

Podemos estar errados...

Joshua Trupin Caixa de Ferramentas

Novos produtos para profissionais de TI

Greg Steen P&R do SQL

Recriando índices, comprimento da fila de disco e muito mais

Editado por Nancy Michell Destaque de utilitário

Autoruns

Lance Whitney The Cable Guy

Configurações da Diretiva de Grupo sem fio para Windows Vista

Joseph Davies Windows PowerShell

Filtrando e formatando dados

Don Jones 		Ei, Equipe de Scripts!

Gerenciando ingenuamente usuários e grupos locais

A Equipe de Scripts da Microsoft Security Watch

O Assistente de Configuração de Segurança

John Morello Os arquivos da área de trabalho

When I’m x64

Wes Miller Por dentro da Microsoft.com

Usando os Serviços de Federação do Active Directory

Jim Guthrie Anotações de campo

As alegrias (e as dificuldades) do aprendizado

Mark D. Scott Segredos do Windows

O poder dos bugs

Raymond Chen


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

Dentro do kernel do Windows Vista: Parte 3
Visão geral:
  • Confiabilidade
  • Recuperação
  • Segurança

Até agora, esta série tem abordado os aprimoramentos do kernel do Windows Vista relacionados a processos, E/S, gerenciamento de memória, inicialização do sistema, desligamento e gerenciamento de energia. Nesta terceira parte
final, analisarei os recursos e aprimoramentos nas áreas de confiabilidade, recuperação e segurança.
Um recurso que não estou abordando nesta série é o Controle de Conta de Usuário (UAC, User Account Control), o qual envolve várias tecnologias diferentes, inclusive o sistema de arquivos e a virtualização do Registro de aplicativos herdados, consentimento de elevação para acesso a direitos administrativos e o mecanismo do Nível de Integridade do Windows®, a fim de isolar processos em execução com direitos administrativos dos processos com menos privilégios sendo executados na mesma conta. Para obter uma abordagem mais detalhada sobre as partes internas do UAC, fique atento a uma edição futura da TechNet Magazine.
O Windows Vista™ aprimora a confiabilidade do seu sistema, bem como a capacidade de diagnosticar problemas do sistema e de aplicativos por meio de vários novos recursos e aprimoramentos. Por exemplo, o agente de log do kernel do ETW (Event Tracing for Windows, rastreamento de eventos do Windows) está sempre ativo, gerando rastreamento de eventos de arquivos, Registro, interrupção e outros tipos de atividade em um buffer circular. Quando ocorre um problema, a nova WDI (Windows Diagnostic Infrastructure, Infra-estrutura de Diagnóstico do Windows) pode capturar um instantâneo do buffer e analisá-lo localmente ou carregá-lo no suporte da Microsoft para que seja solucionado.
O novo Monitor de confiabilidade e desempenho do Windows ajuda os usuários a correlacionarem erros, como falhas e interrupções, a alterações que tenham sido feitas na configuração do sistema. A poderosa SRT (System Repair Tool, ferramenta de reparo do sistema) substitui o Console de Recuperação para a recuperação offline de sistemas não inicializáveis.
Existem três áreas que dependem das alterações no nível do kernel no sistema e, portanto, merecem uma análise mais detalhada neste artigo: o KTM (Kernel Transaction Manager, gerenciador de transações de kernel), o tratamento aprimorado de falhas e as versões anteriores.

Gerenciador de Transações de Kernel
Um dos aspectos mais entediantes do desenvolvimento de software é o tratamento das condições de erro. Isso é especialmente válido se, durante a execução de uma operação de nível superior, um aplicativo concluiu uma ou mais subtarefas que resultaram em alterações no sistema de arquivos ou no Registro. Por exemplo, um serviço de atualização de software de um aplicativo pode efetuar várias atualizações do Registro, substituir um dos executáveis do aplicativo e, em seguida, ter o acesso negado quando tentar atualizar um segundo executável. Se o serviço não quiser permitir que o aplicativo resulte em um estado inconsistente, ele deverá rastrear todas as alterações feitas por ele e estar preparado para desfazê-las. O teste do código de recuperação de erro é difícil e, conseqüentemente, com freqüência é ignorado; portanto, os erros no código de recuperação podem negar o esforço.
Os aplicativos escritos para o Windows Vista podem, com muito pouco esforço, obter os recursos de recuperação automática de erro usando o novo suporte a transações no NTFS e no Registro com o Gerenciador de Transações de Kernel. Quando um aplicativo quiser efetuar determinado número de alterações relacionadas, ele pode criar uma transação do DTC (Distributed Transaction Coordinator, coordenador de transações distribuídas) e um identificador de transação do KTM diretamente e associar as modificações dos arquivos e das chaves do Registro à transação. Se todas as alterações tiverem êxito, o aplicativo confirma a transação e as alterações são aplicadas, mas a qualquer momento, até esse ponto, o aplicativo pode reverter a transação e as alterações serem descartadas.
Como vantagem adicional, outros aplicativos não visualizam as alterações feitas em uma transação até que ela seja confirmada; além disso, os aplicativos que utilizam o DTC no Windows Vista e na próxima versão do Windows Server®, cujo codinome é “Longhorn” podem coordenar as suas transações com o SQL Server™, Microsoft® Message Queue Server (MSMQ, servidor de enfileiramento de mensagens) e outros bancos de dados. Portanto, um serviço de atualização de aplicativo que utilize as transações do KTM nunca deixará o aplicativo em um modo inconsistente. É por esse motivo que o Windows Update e a Recuperação do Sistema utilizam as transações.
Como o núcleo do suporte à transação, o KTM permite que gerenciadores de recursos de transações, como o NTFS e o Registro, coordenem as suas atualizações em um conjunto específico de alterações feitas por um aplicativo. No Windows Vista, o NTFS utiliza uma extensão para oferecer suporte a transações denominadas TxF. O Registro utiliza uma extensão semelhante denominada TxR. Esses gerenciadores de recursos no modo kernel trabalham com o KTM para coordenar o estado da transação, justamente como os gerenciadores de recursos no modo de usuário utilizam o DTC para coordenar o estado da transação em vários gerenciadores de recursos no modo de usuário. Os terceiros também podem usar o KTM para implementar os seus próprios gerenciadores de recursos.
O TxF e o TxR definem um novo conjunto de sistema de arquivos e APIs do Registro que são semelhantes aos existentes, exceto pelo fato de incluírem um parâmetro de transação. Se um aplicativo quiser criar um arquivo em uma transação, ele primeiro utilizará o KTM para criar a transação e, em seguida, passará o identificador resultante da transação para a API de criação do novo arquivo.
O TxF e o TxR dependem da funcionalidade de registro em log do sistema de arquivos de alta velocidade do CLFS (Common Log File System, sistema de arquivos de log comum) (%SystemRoot%\System32\Clfs.sys), o qual foi introduzido no Windows Server 2003 R2. O TxR e o TxF utilizam o CLFS para armazenar permanentemente as alterações de estado de transações antes de confirmarem uma transação. Isso permite que eles forneçam recuperação de transações e garantias mesmo se houver queda de energia. Além do log do CLFS, o TxR cria um conjunto de arquivos de log relacionados, a fim de rastrear as alterações de transação no arquivo de Registro do sistema no %Systemroot%\System32\Config\Txr, como observado na Figura 1, bem como conjuntos separados de arquivos de log para cada hive de Registro de usuário. O TxF armazena dados de transações para cada volume em um diretório oculto no volume intitulado \$Extend\$RmMetadata.
Figura 1 Arquivos de log do TxR do hive de Registro do sistema
Figura 1 Arquivos de log do TxR do hive de Registro do sistema (Clique na imagem para diminuir a exibição)
Figura 1 Arquivos de log do TxR do hive de Registro do sistema
Figura 1 Arquivos de log do TxR do hive de Registro do sistema (Clique na imagem para aumentar a exibição)

Suporte aprimorado a falhas
Quando o Windows detectar um erro irrecuperável no modo kernel – devido a um driver de dispositivo com bugs, hardware ou sistema operacional com falhas – ele tentará impedir a corrupção dos dados no disco interrompendo o sistema depois de exibir a famosa “Blue Screen of Death” (tela azul de erro) e, se configurado para tal, gravará o conteúdo de parte ou de toda a memória física em um arquivo de despejo de memória. Os arquivos de despejo são úteis, pois quando você reinicializa depois de uma falha, o serviço de Análise Online de Pane da Microsoft (OCA, Online Crash Analysis) pode analisá-los para descobrir a raiz do problema. Se você quiser, você mesmo pode analisá-los usando as Ferramentas de depuração da Microsoft para Windows).
No entanto, na versão anterior do Windows, o suporte aos arquivos de despejo de memória não era habilitado até que o Gerenciador de Sessão (%Systemroot%\System32\Smss.exe) processasse os arquivos de paginação inicializados. Isso significava que quaisquer erros críticos anteriores a esse ponto resultariam em uma tela azul, mas não em um arquivo de despejo. Como a carga da inicialização do driver de dispositivo ocorre antes de o Smss.exe iniciar, as falhas anteriores nunca resultariam em despejos de memória, tornando assim extremamente difícil o diagnóstico da causa.
O Windows Vista reduz o período de tempo em que nenhum arquivo de despejo é gerado ao inicializar o suporte ao arquivo de despejo depois que todos os drivers de dispositivo de inicialização tiverem sido inicializados, mas antes de carregar os drivers de início do sistema. Devido a essa alteração, se ocorrer uma falha durante a parte inicial do processo de reinicialização, o sistema pode capturar um despejo de memória, permitindo que a OCA ajude a resolver o problema. Além disso, o Windows Vista salva os dados em um arquivo de desejo em blocos de 64 KB, enquanto as versões anteriores do Windows os gravavam usando blocos de 4 KB. Essa alteração fez com que grandes arquivos de despejo fossem gravados 10 vezes mais rápido.
O tratamento de falhas de aplicativo também foi aprimorado no Windows Vista. Na versão anterior do Windows, quando um aplicativo falhava, ele executava um manipulador de exceção não tratada. O manipulador iniciava o processo de Relatório de Erros dos Aplicativos Microsoft (AER, Application Error Reporting) (%Systemroot%\System32\Dwwin.exe) para exibir uma caixa de diálogo indicando que o programa tinha falhado e lhe perguntando se desejaria enviar um relatório de erros à Microsoft. No entanto, se a pilha do segmento principal do processo tiver sido corrompida durante a falha, o manipulador de exceção não tratada falhou durante a execução, resultando no término do processo pelo kernel, o desaparecimento instantâneo das janelas do programa e na não exibição da caixa de diálogo de relatório de erros.
O Windows Vista move o tratamento de erros do contexto do processo de falha para um novo serviço intitulado WER (Windows Error Reporting, Relatório de Erros do Windows). Esse serviço é implementado por uma DLL (%Systemroot%\System32\Wersvc.dll) dentro do processo de Hospedagem do Serviço. Quando um aplicativo falha, ele ainda executa um manipulador de exceção não tratada, mas o manipulador envia uma mensagem para o serviço WER e ele inicia o processo de Relatório de Erros de Falha do WER (%Systemroot%\System32\Werfault.exe) para exibir a caixa de diálogo de relatório de erros. Se a pilha estiver corrompida e o manipulador de exceção não tratada falhar, ele executará novamente e falhará de novo, consumindo eventualmente toda a pilha do segmento (área de memória do zero), sendo que nesse ponto o kernel atuará e enviará a mensagem de notificação de falha ao serviço.
Você pode visualizar o contraste nessas duas abordagens nas Figuras 2 e 3, as quais mostram a relação de processo do Accvio.exe, um programa de teste que falha, e os processos de relatório de erros destacados em verde, no Windows XP e no Windows Vista. A nova arquitetura de tratamento de erros do Windows Vista significa que os programas não serão mais encerrados silenciosamente, sem oferecer a chance para que a Microsoft obtenha um relatório de erros e ajude os desenvolvedores de software a aprimorar os seus aplicativos.
Figura 2a Tratamento de erros de aplicativo no Windows Vista
Figura 2a Tratamento de erros de aplicativo no Windows Vista (Clique na imagem para diminuir a exibição)
Figura 2a Tratamento de erros de aplicativo no Windows Vista
Figura 2a Tratamento de erros de aplicativo no Windows Vista (Clique na imagem para aumentar a exibição)
Figura 2b
Figura 2b (Clique na imagem para diminuir a exibição)
Figura 2b
Figura 2b (Clique na imagem para aumentar a exibição)
Figura 3a Tratamento de erros de aplicativo no Windows Vista
Figura 3a Tratamento de erros de aplicativo no Windows Vista (Clique na imagem para diminuir a exibição)
Figura 3a Tratamento de erros de aplicativo no Windows Vista
Figura 3a Tratamento de erros de aplicativo no Windows Vista (Clique na imagem para aumentar a exibição)
Figura 3b
Figura 3b

VSS (Volume Shadow Copy, Cópia de Sombra de Volume)
O Windows XP introduziu uma tecnologia denominada Cópia de Sombra de Volume, a fim de criar instantâneos dos volumes de disco. Os aplicativos de backup podem usar esses instantâneos para criar imagens consistentes de backup, mas eles ficam ocultos da exibição e são mantidos somente durante o processo de backup.
Na verdade, os instantâneos não são cópias completas dos volumes. Em vez disso, eles são exibições de um volume de um ponto anterior, o qual consistia nos dados dinâmicos do volume recobertos com cópias de setores de volume, que tinham sido alterados desde a captura do instantâneo. O driver do Provedor de Instantâneo do Volume (%Systemroot\%System32\Drivers\Volsnap.sys) monitora as operações destinadas em volumes e efetua cópias dos setores antes de permitir que sejam alterados, armazenando os dados originais em um arquivo associado ao instantâneo no diretório de Informações de Volume do Sistema do volume.
O Windows Server 2003 exibia o gerenciamento de instantâneos aos administradores no servidor, e aos usuários nos sistemas cliente com as suas Cópias de Sombra de Pastas Compartilhadas. Esse recurso permitia instantâneos persistentes que os usuários podiam acessar, por meio da guia Versões Anteriores nas caixas de diálogo de propriedades do Explorer, para as suas pastas e arquivos localizados nos compartilhamentos de arquivo do servidor.
O recurso de Versões Anteriores do Windows Vista oferece esse suporte a todos os sistemas cliente, criando automaticamente instantâneos de volume, em geral uma vez ao dia, os quais você pode acessar por meio da caixa de diálogo de propriedades do Explorer, usando a mesma interface utilizada pelas Cópias de Sombra de Pastas Compartilhadas. Isso permite que você visualize, restaure ou copie as versões anteriores de arquivos e diretórios que possa ter acidentalmente modificado ou excluído. Apesar de essa não ser uma tecnologia nova do ponto de vista técnico, a implementação do recurso de Versões Anteriores do Windows Vista da Cópia de Sombra de Volume otimiza a do Windows Server 2003 para uso em ambientes da área de trabalho cliente.
O Windows Vista também aproveita os benefícios dos instantâneos de volume, a fim de unificar os mecanismos de proteção de dados do usuário e do sistema, bem como evitar salvar dados de backup redundantes. Quando uma alteração na instalação ou na configuração do aplicativo ocasiona comportamentos incorretos ou indesejados, você pode usar a Restauração do Sistema, um recurso introduzido na linha Windows NT® dos sistemas operacionais no Windows XP, a fim de restaurar os arquivos e dados do sistema para o seu estado anterior quando foi criado o ponto de restauração.
No Windows XP, a Restauração do Sistema utiliza um driver de filtro do sistema de arquivos – um tipo de driver que pode visualizar as alterações no nível de arquivos –, a fim de efetuar cópias de backup dos arquivos do sistema quando eles forem alterados. No Windows Vista, a Restauração do Sistema utiliza instantâneos de volume. Quando você utiliza a interface de usuário de Restauração do Sistema no Windows Vista para voltar a um ponto de restauração, na verdade você está copiando versões anteriores dos arquivos modificados do sistema a partir do instantâneo associado com o ponto de restauração para o volume dinâmico.

BitLocker
Até o momento, o Windows Vista é a versão mais segura do Windows. Além da inclusão do mecanismo de anti-spyware do Windows Defender, o Windows Vista introduz vários recursos de segurança e defesa em profundidade, inclusive a criptografia de volume completo BitLocker™, assinatura de código para o modo kernel, processos protegidos, randomização de carga de espaço de endereço e aprimoramentos no Controle de Conta de Usuário e na segurança do serviço do Windows.
Um sistema operacional pode reforçar somente as suas políticas de segurança enquanto estiver ativo, de forma que você precisará tomar medidas adicionais para proteger os dados quando a segurança física de um sistema estiver comprometida e os dados possam ser acessados de fora do sistema operacional. Os mecanismos baseados em hardware, como senhas de BIOS e criptografia, são duas tecnologias comumente utilizadas para impedir o acesso não autorizado, especialmente em laptops, os quais têm grande probabilidade de serem perdidos ou roubados.
O Windows 2000 introduziu o Sistema de arquivos com criptografia (EPS, Encrypting File System) e, na sua versão do Windows Vista, o EFS inclui vários aprimoramentos em relação às implementações anteriores, inclusive aprimoramentos de desempenho, suporte à criptografia do arquivo de paginação e armazenamento de chaves de EFS de usuário em cartões inteligentes. No entanto, não é necessário usar o EFS para proteger o acesso a áreas confidenciais do sistema, como os arquivos de hive do Registro. Por exemplo, se a Diretiva de grupo permitir que você faça logon no seu laptop mesmo quando você não estiver conectado a um domínio, os verificadores de credencial de domínio estarão armazenados em cache no Registro; portanto, um invasor poderia usar as ferramentas para obter o hash de senha da conta de domínio e usá-la para tentar obter a sua senha com um cracker de senha. A senha forneceria acesso à sua conta e os arquivos de EFS (supondo-se que você não tenha armazenado a chave de EFS em um cartão inteligente).
Para facilitar a criptografia do volume completo de reinicialização (o volume com o diretório do Windows), inclusive todos seus arquivos e dados do sistema, o Windows Vista introduz um recurso de criptografia de volume completo intitulado Criptografia de Unidade de Disco do Windows. Ao contrário do EFS, que é implementado pelo driver do sistema de arquivos NTFS e opera no nível de arquivos, o BitLocker efetua a criptografia no nível do volume usando o driver de FVE (Full Volume Encryption, criptografia de volume completo) (%Systemroot%\System32\Drivers\Fvevol.sys) como apresentado na Figura 4.
Figura 4 Driver de filtro FVE do BitLocker
Figura 4 Driver de filtro FVE do BitLocker (Clique na imagem para diminuir a exibição)
Figura 4 Driver de filtro FVE do BitLocker
Figura 4 Driver de filtro FVE do BitLocker (Clique na imagem para aumentar a exibição)
O FVE é um driver de filtro, de forma que ele visualiza automaticamente todas as solicitações de E/S que o NTFS envia para o volume, criptografando blocos como eles são gravados e os descriptografando como eles são lidos, usando a FVEK (Full Volume Encryption Key, chave de criptografia de volume completo) atribuída ao volume quando ele for inicialmente configurado para usar o BitLocker. Por padrão, os volumes são criptografados usando uma chave AES de 128 bits e uma chave difusora de 128 bits. Como a criptografia e descriptografia ocorrem abaixo do NTFS no sistema de E/S, o volume aparece como NTFS como se estivesse descriptografado e o NTFS não precisa nem mesmo ter conhecimento de que o BitLocker está habilitado. No entanto, se você tentar ler os dados a partir do volume fora do Windows, ele aparecerá como dados aleatórios.
A FVEK é criptografada com uma VMK (Volume Master Key, chave mestra de volume) e armazenada em uma região especial de metadados do volume. Quando você configurar o BitLocker, você terá várias opções para a proteção da VMK, dependendo dos recursos de hardware do sistema. Se o sistema tiver um TPM (Trusted Platform Module, módulo de plataforma confiável) que esteja de acordo com a v1.2 da especificação do TPM e tiver suporte a BIOS associado, você pode criptografar a VMK com a TPM, fazer com que o sistema criptografe a VMK usando uma chave armazenada no TPM e uma armazenada em um dispositivo flash USB, ou criptografar a chave usando uma chave armazenada no TPM e um número de identificação pessoal que você digitará quando o sistema for reinicializado. Para sistemas que não tenham um TPM, o BitLocker oferece a opção de criptografia da VMK usando uma chave armazenada em um dispositivo flash USB externo. Em qualquer caso, você precisará de um volume de sistema NTFS de 1,5 GB descriptografado, o volume no qual o Gerenciador de inicialização e o BCD (Boot Configuration Database, banco de dados de configuração de inicialização) estão armazenados.
A vantagem de usar um TPM é que o BitLocker utiliza recursos do TPM, a fim de garantir que ele não descriptografará a VKM, nem desbloqueará o volume de inicialização se o BIOS ou os arquivos de reinicialização do sistema tiverem sido alterados desde que o BitLocker tiver sido habilitado. Quando você criptografar o volume do sistema pela primeira vez e sempre que executar atualizações em qualquer um dos componentes mencionados, o BitLocker calculará hashes SHA-1 desses componentes e armazenará cada hash, denominado uma medida, nos diferentes PCRs (Platform Configuration Registers, registros de configuração de plataforma) do TPM com a ajuda do driver de dispositivo do TPM (%Systemroot%\System32\Drivers\Tpm.sys). Em seguida, ele utiliza o TPM para lacrar a VKM, uma operação que utiliza uma chave particular armazenada no TPM, a fim de criptografar a VMK e os valores armazenados nos PCRs, juntamente com outros dados que o BitLocker passar para o TPM. O BitLocker armazenará então a VMK lacrada e a FVEK criptografada na região de metadados do volume.
Quando o sistema for inicializado, ele medirá seu próprio hash e código de carregamento de PCR, e gravará o hash no primeiro PCR do TPM. Em seguida, ele executará o hash do BIOS e armazenará a medição no PCR apropriado. O BIOS, por sua vez, efetua o hash no próximo componente na seqüência da inicialização, o MBR (Master Boot Record, registro mestre de inicialização) do volume de inicialização, e esse processo continuará até que o carregador do sistema operacional seja medido. Cada parte subseqüente do código executada será responsável por medir o código carregado, bem como por armazenar essa medição no registro apropriado no TPM. Finalmente, quando o usuário selecionar qual sistema operacional deseja inicializar, o Gerenciador de inicialização (Bootmgr) lerá a VMK criptografada a partir do volume e solicitará que o TPM a desbloqueie. Somente se todas as medições forem as mesmas de quando a VMK foi lacrada, inclusive o número de identificação pessoal opcional, o TPM terá êxito ao descriptografar a VMK.
Você pode pensar nesse esquema como uma cadeia de verificação, na qual cada componente na seqüência de inicialização descreve o próximo componente para o TPM. O TPM somente divulgará o seu segredo se todas as descrições corresponderem aos originais fornecidos. Portanto, o BitLocker protege os dados criptografados mesmo quando o disco for removido e inserido em outro sistema, quando o sistema for inicializado usando um diferente sistema operacional ou quando os arquivos não criptografados no volume de inicialização estiverem comprometidos.

Verificação de integridade do código
O malware implementado como um driver de dispositivo no modo kernel, inclusive rootkits, é executado no mesmo nível de privilégio que o kernel e, portanto, sua identificação e remoção são mais difíceis. Tal malware pode modificar o comportamento do kernel e outros drivers, ao ponto de se tornarem praticamente invisíveis. A integridade de código do Windows Vista para o recurso de código do modo kernel, também conhecida como assinatura de código no modo kernel (KMCS, Kernel-Mode Code Signing), também permite que os drivers de dispositivo sejam carregados, caso tenham sido publicados e assinados digitalmente por desenvolvedores que tenham sido verificados por algumas das autoridades de certificação (CAs, Certificate Authorities). A KMCS é reforçada, por padrão, no Windows Vista para sistemas de 64 bits.
Como as autoridades de certificação cobram uma taxa por seus serviços e executam verificações básicas em segundo plano, como verificar uma identidade comercial, é mais difícil produzir malware anônimo no modo kernel que seja executado no Windows Vista de 64 bits. Além disso, o malware que consegue escapar pelo processo de verificação pode potencialmente deixar pistas que, quando o malware for detectado em um sistema comprometido, levem ao autor. A KMCS também apresenta usos secundários, como fornecer as informações de contato para a equipe de Análise Online de Pane da Microsoft quando houver suspeita de que um driver tem um bug que está causando falha nos sistemas dos clientes, bem como desbloquear conteúdo de multimídia de alta definição, o qual descreverei em seguida.
A KMCS utiliza tecnologias de criptografia de chave pública, as quais têm sido utilizadas há mais de uma década pelo Windows, e requer que o código no modo kernel inclua uma assinatura digital gerada por uma das autoridades de certificação confiáveis. Se um editor enviar um driver para o WHQL (Windows Hardware Quality Laboratory, laboratório de qualidade de hardware do Windows) da Microsoft e o driver passar pelo teste de confiabilidade, a Microsoft atuará como a autoridade de certificação que assinará o código. A maioria dos editores obterá assinaturas por meio do WHQL, mas quando um driver não tiver um programa de teste do WHQL, o editor não desejará submetê-lo aos testes do WHQL, ou se o driver for um driver de reinicialização, o qual seja carregado antecipadamente na inicialização do sistema, os editores devem eles mesmos assinar o código. Para fazer isso, eles primeiro devem obter um certificado de assinatura de código a partir de uma das autoridades de certificação que a Microsoft tenha identificado como confiável para a assinatura do código no modo kernel. O autor então efetuará o hash do código digitalmente, assinará o hash o criptografando com uma chave particular e incluirá o certificado e o hash criptografado com o código.
Quando um driver tentar ser carregado, o Windows descriptografará o hash incluído no código usando a chave particular armazenada no certificado e, em seguida, verificará se o hash corresponde àquele incluído no código. A autenticidade do certificado será verificada da mesma forma, porém usando a chave pública da autoridade de certificação, a qual está incluída no Windows.
O Windows também verifica a cadeia do certificado associado em até uma das autoridades raiz, as quais são incorporadas no carregador de inicialização do Windows e no kernel do sistema operacional. As tentativas de carregar um driver de 64 bits não assinado nunca ocorrem em um sistema de produção, ao contrário do Plug and Play Manager, que exibe uma caixa de diálogo de aviso quando é direcionado para carregar um driver, o qual não apresenta uma assinatura confirmando que passou pelos testes do WQHL, o Windows Vista de 64 bits grava silenciosamente um evento no log de eventos do aplicativo de Integridade do Código, como o apresentado na Figura 5, sempre que ele bloquear o carregamento de um driver não assinado. O Windows Vista de 32 bits também verifica as assinaturas do driver, mas permite que os drivers não assinados sejam carregados. O bloqueio dos drivers interromperia os sistemas atualizados do Windows XP que exigem que os drivers sejam carregados no Windows XP; além disso, permite suporte para hardware para o qual existem somente drivers do Windows XP. No entanto, o Windows de 32 bits também grava eventos no log de eventos do Código de Integridade quando ele carrega um driver não assinado.
Figura 5 Eventos de tentativa de carregamento de driver não assinado
Figura 5 Eventos de tentativa de carregamento de driver não assinado (Clique na imagem para diminuir a exibição)
Figura 5 Eventos de tentativa de carregamento de driver não assinado
Figura 5 Eventos de tentativa de carregamento de driver não assinado (Clique na imagem para aumentar a exibição)
Como a assinatura de código é comumente utilizada para rotular o código como uma versão oficial rigorosamente testada, os editores geralmente não querem assinar o código de teste. Por esse motivo, o Windows Vista inclui um modo de assinatura de teste que você pode habilitar e desabilitar com a ferramenta Bcdedit (descrita em meu artigo de março de 2007 da TechNet Magazine), onde os drivers no modo kernel assinados digitalmente serão carregados com um certificado de teste gerado por uma autoridade de certificação interna. Esse modo foi desenvolvido para uso pelos programadores durante o desenvolvimento de seus códigos. Quando o Windows estiver nesse modo, ele exibirá marcadores na área de trabalho, como o apresentado na Figura 6.
Figura 6 Modo de assinatura de teste do Windows Vista
Figura 6 Modo de assinatura de teste do Windows Vista

Processos protegidos
O conteúdo de multimídia da próxima geração, como o HD-DVD, BluRay e outros formatos licenciados sob o AACS (Advanced Access Content System, sistema de conteúdo de acesso avançado), serão cada vez mais comuns nos próximos anos. O Windows Vista inclui várias tecnologias, coletivamente denominadas PMP (Protected Media Path, caminho de mídia protegida), as quais são exigidas pelo padrão do AACS para que tal conteúdo seja reproduzido. O PMP inclui o PUMA (Protected User-Mode Audio, áudio no modo de usuário protegido) e o PVP (Protected Video Path, caminho de vídeo protegido), os quais juntos fornecem mecanismos para drivers de áudio e vídeo, bem como aplicativos de reprodução de mídia, a fim de impedir que software ou hardware não autorizado capture conteúdo na forma de alta definição.
O PUMA e o PVP definem interfaces e oferecem suporte a reprodutores de áudio e vídeo, drivers de dispositivo e hardware, mas o PMP também depende de um mecanismo geral do kernel, introduzido no Windows Vista, denominado processo protegido. Os processos protegidos têm como a construção do processo padrão do Windows, a qual encapsula uma imagem executável em execução, suas DLLs, o contexto de segurança (a conta na qual o processo está em execução e seus privilégios de segurança) e os segmentos que executam o código no processo, mas impedem determinados tipos de acesso.
Os processos padrão implementam um modelo de controle de acesso, o qual permite total acesso ao proprietário do processo e a contas administrativas com o privilégio de Depurar programas. O acesso total permite que um usuário visualize e modifique o espaço do endereço do processo, inclusive o código e os dados mapeados do processo. Os usuários também podem injetar segmentos no processo. Esses tipos de acessos não são consistentes com as exigências do PMP, pois eles permitiriam que um código não autorizado obtivesse acesso a conteúdo de alta definição e a chaves de DRM (Digital Rights Management, gerenciamento de direitos digitais) armazenadas em um processo que está reproduzindo o conteúdo.
Os processos protegidos restringem o acesso a um conjunto limitado de interfaces de informação e de gerenciamento do processo, as quais incluem consulta do nome da imagem do processo e conclusão ou suspensão do processo. Entretanto, o kernel apresenta informações diagnósticas para processos protegidos disponíveis pro meio de funções de consulta do processo em geral, as quais retornam dados relativos a todos os processos em um sistema e, portanto, não requerem acesso direto ao processo. Os acessos que poderiam comprometer a mídia são permitidos somente pelos outros processos protegidos.
Além disso, para impedir esse comprometimento, todos os códigos executáveis carregados em um processo protegido, inclusive sua imagem executável e as DLLs, devem ser assinados pela Microsoft (WHQL) com um sinalizador de PE (Protected Environment, ambiente protegido), ou no caso de codec de áudio, assinado pelo desenvolvedor com um certificado de assinatura de DRM obtido da Microsoft. Como o código no modo kernel pode obter acesso total a qualquer processo, inclusive aos processos protegidos, e o Windows de 32 bits permite que o código no modo kernel não assinado seja carregado, o kernel fornece uma API para processos protegidos, a fim de consultar o “nível de correção” do ambiente no modo kernel e utilizar o resultado para desbloquear conteúdo premium, somente se não houver código não assinado carregado.
Identificando um processo protegido
Não há APIs que identifiquem especificamente os processos protegidos, mas você pode identificá-las indiretamente com base nas informações limitadas disponíveis para elas, bem como por meio de sua incapacidade de depurá-las até mesmo a partir de uma conta administrativa. O processo de Isolamento de Gráfico de Dispositivo de Áudio (%Systemroot%\System32\Audiodg.exe) é utilizado para reproduzir DVDs codificados com CSS (Content Scramble System) e é identificável como um processo protegido no painel do Gerenciador de tarefas, devido ao fato de o gerenciador não conseguir obter sua linha de comando, virtualização e status de prevenção de execução de dados, até mesmo quando em execução com direitos administrativos.
Visualização do gerenciador de tarefas do processo protegido audiodg
Visualização do gerenciador de tarefas do processo protegido audiodg (Clique na imagem para diminuir a exibição)
Visualização do gerenciador de tarefas do processo protegido audiodg
Visualização do gerenciador de tarefas do processo protegido audiodg (Clique na imagem para aumentar a exibição)

ASLR (Address Space Load Randomization)
Apesar das medidas como a prevenção de execução de dados e da verificação de erros do compilador avançado, os autores de malware continuam encontrando vulnerabilidades de estouro de buffer, as quais permitem que eles infectem processos em rede, como o Internet Explorer®, serviços do Windows e aplicativos de terceiros, a fim de obter acesso a um sistema. No entanto, assim que eles tiverem infectado um processo, eles devem usar as APIs do Windows para concluir sua meta final de ler os dados do usuário ou estabelecer uma presença permanente por meio da modificação das configurações do usuário ou do sistema.
A conexão de um aplicativo com pontos de entrada de API exportados pelas DLLs geralmente é algo tratado pelo carregador do sistema operacional, mas esses tipos de infecção de malware não aproveitam os benefícios dos serviços do carregador. Isso não apresenta um problema para malware não versões anteriores do Windows, pois para qualquer versão do Windows, as imagens executáveis do sistema e DLLs sempre são carregadas no mesmo local, permitindo que o malware pressuponha que as APIs residem nos endereços fixos.
O recurso de ASLR do Windows Vista não permite que o malware saiba onde as APIs estão localizadas. Isso é feito por meio do carregamento das DLLs e dos executáveis do sistema em local diferente sempre que o sistema for inicializado. No início do processo de inicialização, o Gerenciador de memória seleciona uma compensação de carregamento de imagem de DLL aleatória a partir de um dos 256 endereços alinhados de 64 KB, na região de 16 MB na parte superior do espaço de endereço no modo de usuário. Como as DLLs que têm novo sinalizador de realocação dinâmica no seu cabeçalho de imagem são carregadas no processo, o Gerenciador de memória as empacota na memória, iniciando no endereço de compensação de carregamento da imagem e seguindo o fluxo descendente.
Os executáveis com o sinalizador definido obtêm um tratamento semelhante, sendo carregados em um ponto aleatório alinhado de 64 KB em 16 MB do endereço de carregamento base armazenado em seu cabeçalho de imagem. Além disso, se determinada DLL ou executável for carregado novamente depois de ter sido descarregado por todos os processos utilizando essa DLL ou executável, o Gerenciador de memória selecionará novamente um local aleatório no qual carregá-lo. A Figura 7 mostra um exemplo de layout do espaço de endereço para um sistema de 32 bits do Windows Vista, inclusive as áreas das quais o recurso de ASLR seleciona a compensação de carregamento de imagem e o endereço de carregamento do executável.
Figura 7 Efeito do ASLR em endereços de carregamento de DLL e executável
Figura 7 Efeito do ASLR em endereços de carregamento de DLL e executável (Clique na imagem para diminuir a exibição)
Figura 7 Efeito do ASLR em endereços de carregamento de DLL e executável
Figura 7 Efeito do ASLR em endereços de carregamento de DLL e executável (Clique na imagem para aumentar a exibição)
Somente as imagens com sinalização de realocação dinâmica, o que inclui todas as DLLs e executáveis do Windows Vista, obtêm realocação, pois o fato de mover as imagens herdadas poderia interromper as suposições internas que os desenvolvedores fizeram sobre onde suas imagens seriam carregadas. O Visual Studio® 2005 SP1 acrescenta suporte para a definição do sinalizador, de forma que os desenvolvedores de terceiros podem ter proveito total do ASLR.
A randomização dos endereços de carregamento de DLL para um dos 256 locais não impede que um malware adivinhe a localização correta de uma API, mas prejudica seriamente a velocidade na qual um worm de rede pode se propagar e impede que o malware, que tenha somente uma chance de infectar o sistema, funcione de forma confiável. Além disso, a estratégia de realocação de ASLR tem um benefício secundário de os espaços de endereço serem empacotados com mais rigidez do que nas versões anteriores do Windows, criando regiões maiores de memória livre para as alocações de memória contíguas, reduzindo o número de tabelas de página que o Gerenciador de memória aloca para controlar o layout de espaço do endereço e minimizando as falhas do TLB (Translation Lookaside Buffer, buffer de conversão à parte).

Aprimoramentos da segurança de serviço
Os serviços do Windows são alvos ideais para malware. Muitos oferecem acesso de rede à sua funcionalidade, expondo possivelmente acesso explorável remotamente a um sistema; a maioria é executada com mais privilégios do que as contas de usuário padrão, oferecendo a chance para elevar os privilégios em um sistema local se puderem ser comprometidos por malware. Por esse motivo, o Windows começou a evoluir com alterações feitas no Windows XP SP2, o que reduziu os privilégios e o acesso atribuído aos serviços para somente os necessários para suas funções. Por exemplo, o Windows XP SP2 introduziu as contas de Serviço Local e Serviço de Rede, as quais incluem somente um subconjunto dos privilégios disponíveis para a conta em que os serviços eram sempre executados anteriormente, o Sistema Local. Isso minimiza o acesso que um invasor pode conseguir ao explorar um serviço.
Vendo o ASLR em ação
Você pode observar facilmente os efeitos do ASLR ao comparar os endereços de carregamento de DLL para um processo em duas sessões diferentes de inicialização usando uma ferramenta, como Process Explorer da Sysinternals. Nessas duas capturas de tela, obtidas de duas sessões diferentes, a Ntdll.dll foi carregada no Explorer primeiro no endereço 0x77A30000 e, em seguida, no endereço 0x77750000.
Diferentes endereços base para ntdll.dll
Diferentes endereços base para ntdll.dll (Clique na imagem para diminuir a exibição)
Diferentes endereços base para ntdll.dll
Diferentes endereços base para ntdll.dll (Clique na imagem para aumentar a exibição)
Diferentes endereços base para ntdll.dll
Diferentes endereços base para ntdll.dll (Clique na imagem para diminuir a exibição)
Diferentes endereços base para ntdll.dll
Diferentes endereços base para ntdll.dll (Clique na imagem para aumentar a exibição)

No meu artigo anterior, descrevi como os serviços são executados isoladamente das contas de usuários em sua própria sessão, mas o Windows Vista também amplia o seu uso do princípio de privilégios mínimos ao reduzir ainda mais os privilégios e acessos a arquivos, chaves de Registro e portas de firewall que atribui para a maioria dos serviços. O Windows Vista define uma nova conta de grupo, denominada Identificador de segurança do serviço (Service Security Identifier), exclusiva para cada serviço. O serviço pode definir permissões em seus recursos, de forma que somente o seu SID de serviço tenha acesso, impedindo que outros serviços executados na mesma conta de usuário tenham acesso se um serviço ficar comprometido. Você pode ver um SID de serviço ao usar o comando sc showsid, seguido pelo nome de serviço, como mostrado na Figura 8.
Figura 8 Visualizando um SID de serviço
Figura 8 Visualizando um SID de serviço (Clique na imagem para diminuir a exibição)
Figura 8 Visualizando um SID de serviço
Figura 8 Visualizando um SID de serviço (Clique na imagem para aumentar a exibição)
Os SIDs de serviço protegem o acesso aos recursos de propriedade de um determinado serviço, mas por padrão os serviços ainda têm acesso a todos os objetos que a conta de usuário, na qual são executados, pode acessar. Por exemplo, um serviço sendo executado na conta de Serviço Local pode não conseguir acesso a recursos criados por outro serviço sendo executado como Serviço Local em um processo diferente, o qual tenha protegido seus objetos com permissões fazendo referência a um SID de serviço; no entanto, ele ainda pode ler e gravar quaisquer objetos aos quais o Serviço Local (e quaisquer grupos aos quais o Serviço Local pertence, como o grupo de Serviço) tenha permissões.
O Windows Vista introduz um novo tipo de serviço restrito chamado de serviço de gravação restrita, o qual permite que um serviço grave somente o acesso a objetos acessíveis ao seu SID de serviço, a todos no grupo e ao SID atribuído na sessão de logon. Para realizar isso, ele utiliza SIDs restritos, um tipo de SID introduzido novamente no Windows 2000. Quando o processo de abertura de um objeto for um serviço de gravação restrita, o algoritmo de verificação do acesso será alterado, de forma que um SID que não tenha sido atribuído a um processo, tanto nas formas restritas e não restritas, não poderá ser utilizado para conceder ao processo acesso de gravação a um objeto. Você pode ver se um serviço está restrito com o comando a seguir:
sc qsidtype [service]
Outra alteração facilita que um serviço impeça que outros serviços sendo executados na mesma conta tenham acesso aos objetos que ele criar. Nas versões anteriores do Windows, o criador de um objeto também é o seu proprietário, e os proprietários têm a capacidade de ler e alterar as permissões de seus objetos, permitindo que tenham acesso total aos seus próprios objetos. O Windows Vista introduz o novo SID de Direitos do Proprietário, o qual, se presente nas permissões de um objeto, pode limitar os acessos de um proprietário ao seu próprio objeto, mesmo removendo o direito de definir e consultar as permissões.
Um aprimoramento adicional ao modelo de segurança do serviço no Windows Vista permite que um desenvolvedor do serviço especifique exatamente quais privilégios de segurança o serviço precisa para operar, quando o serviço for registrado em um sistema. Por exemplo, se o serviço precisar gerar eventos de auditoria, ele deveria listar o privilégio de auditoria.
Quando o Gerenciador de controle de serviço iniciar um processo que hospede um ou mais serviços do Windows, ele cria um token de segurança (o objeto kernel que lista uma conta de usuário do processo, associações de grupo e privilégios de segurança) para o processo, o qual inclui somente os privilégios exigidos pelos serviços no processo. Se um serviço especificar um privilégio que não esteja disponível na conta na qual é executado, o serviço apresentará falha ao iniciar. Quando nenhum dos serviços em execução em um processo de conta de Serviço Local precisar do privilégio de Depurar programas, por exemplo, o Gerenciador de controle de serviço distribui esse privilégio a partir do token de segurança do processo. Dessa forma, se o processo de serviço estiver comprometido, o código malicioso não poderá aproveitar os privilégios que não tiverem sido explicitamente solicitados pelos serviços em execução no processo. O comando sc qprivs relata os privilégios que um serviço tenha solicitado.

Conclusão
Este artigo conclui a terceira parte da análise das alterações no kernel do Windows Vista. Há recursos e aprimoramentos que não foram abordados ou mencionados, como um novo pool de segmentos de trabalho para desenvolvedores de aplicativos, novos mecanismos de sincronização, como bloqueios de leitura/gravação compartilhada, marcação de segmento do serviço, suporte para verificação de disco NTFS online e redimensionamento de volume e um novo mecanismo de IPC de kernel denominado ALPC (Advanced Local Procedure Call, chamada avançada de procedimento local). Para obter mais informações sobre esses e outros recursos, consulte a próxima edição do Windows Internals, com previsão de publicação no final de 2007.
Visualizando o serviço de gravação restrita
Somente um processo de hospedagem de serviço no Windows Vista hospeda serviços restritos. Você pode identificá-lo com uma ferramenta de visualização de processo, como o Process Explorer, como a que possui a linha de comando:
svchost -k LocalServiceNoNetwork
Os serviços configurados para execução nesse processo incluem o Mecanismo de Filtragem Base, o Serviço de Diretiva de Diagnóstico, o Firewall do Windows, Logs e alertas de desempenho e o Windows Media® Center Service Starter.
Esta tela mostra o formato textual do SID do serviço de Mecanismo de Filtragem Base, NT SERVICE\BFE, listado uma vez com a sinalização Restrito e novamente sem ela, de forma que o processo tenha acesso a recursos acessíveis a essa conta. No entanto, ele não tem acesso necessariamente a outros objetos em geral acessíveis à conta de Serviço Local. Por exemplo, como a conta NT AUTHORITY\SERVICE não aparece no token do processo com o sinalizador restrito, o processo não pode modificar os objetos que concedem acesso de gravação somente a tal conta, mas não a outras contas no token que tenham o sinalizador restrito.
Os serviços em execução nesse processo também limitam os privilégios, pois os privilégios listados na parte inferior da caixa de diálogo de propriedades são um subconjunto dos privilégios disponíveis para a conta de Serviço Local.
Sinalizadores de SID em um serviço
Sinalizadores de SID em um serviço (Clique na imagem para diminuir a exibição)
Sinalizadores de SID em um serviço
Sinalizadores de SID em um serviço (Clique na imagem para aumentar a exibição)

Mark Russinovich é um colega da área técnica da Microsoft na divisão de plataforma e serviços. Ele é co-autor do livro Microsoft Windows Internals (Microsoft Press, 2004) e palestrante assíduo em conferências de desenvolvedores e TI, inclusive da Microsoft Tech•Ed e de PDC. Russinovich uniu-se à Microsoft com a aquisição da empresa de que foi co-fundador, a Winternals Software. Ele também criou a Sysinternals, onde publicou utilitários muito populares, inclusive o Process Explorer, o Filemon e o 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: Recupera&#231;&#227;o de desastres: usu&#225;rios e grupos do Active Directory
Administração do Windows Gil Kirkpatrick

Recuperação de desastres: usuários e grupos do Active Directory
Visão geral:
  • Mecânica da replicação e vinculação de objeto
  • Usando o NTDSUTIL para backup e restauração
  • Restaurações autoritativas e não autoritativas

O Active Directory é um dos serviços mais importantes em uma rede do Windows. Para evitar o tempo de inatividade e a perda de produtividade, é fundamental que você tenha planos eficientes de recuperação de desastres em vigor para os problemas relacionados ao Active Directory. Isso pode parecer óbvio, mas é
impressionante como muitos administradores não têm um plano para um dos cenários de falha mais comuns do Active Directory®: a exclusão acidental de dados.
A exclusão acidental de objetos é uma das causas básicas mais comuns de falha do serviço. Quando sou palestrante em seminários e conferências, pergunto freqüentemente quem já teve uma falha do Active Directory devido à exclusão acidental de dados. E, sempre, quase todos levantam as mãos.
Para compreender por que a recuperação de dados é tão complexa, primeiro é necessário compreender o seguinte: como o Active Directory armazena e replica objetos, como ele exclui objetos e a mecânica das restaurações autoritativas e não autoritativas.

Armazenando objetos
O Active Directory é um banco de dados especializado em objetos, o qual implementa o modelo de dados X.500/LDAP. O armazenamento de dados (denominado árvore de informações de diretórios ou DIT [Directory Information Tree]) tem como base o ESE (Extensible Storage Engine, mecanismo de armazenamento extensível), um mecanismo de banco de dados ISAM (Indexed Sequential Access Method, método de acesso seqüencial indexado). Conceitualmente, o Active Directory armazena a DIT em duas tabelas: a tabela de dados (que contém os reais objetos e atributos do Active Directory) e a tabela de vínculo (que contém as relações entre os objetos).
Cada objeto do Active Directory é armazenado em uma linha separada na tabela de dados, com uma coluna por atributo. A tabela de dados contém todas as entradas para todas as réplicas armazenadas no DC (Domain Controller, controlador de domínio). Em um controlador de domínio normal, a tabela de dados contém entradas de um NC (naming context, contexto de nomenclatura) de domínio, da configuração e do esquema. Em um catálogo global, a tabela de dados contém entradas para cada objeto na floresta.
O Active Directory utiliza a marca de nome distinto (DNT, Distinguished Name Tag) – um inteiro de 32 bits – para identificar exclusivamente cada linha na tabela de dados. O DNT, utilizado para consultar objetos internamente, é muito menor do que outros identificadores, como o nome distinto (DN, Distinguished Name) e o GUID do objeto (uma estrutura binária de 16 bytes). Mas ao contrário do GUID do objeto, o DNT é um identificador local e é diferente em cada controlador de domínio.

Como o Active Directory vincula os objetos
O Active Directory gerencia dois tipos de relações entre os objetos na DIT: a relação pai-filho (também chamada de relação de recipiente) e a relação de referência (também chamada de relação de vínculo). Para implementar a relação pai-filho, o Active Directory armazena uma coluna adicional na tabela de dados denominada marca de nome distinto pai ou PDNT. Essa coluna sempre contém o DNT do pai do objeto.
Cada atributo do Active Directory é definido por um objeto attributeSchema no recipiente Schema do Active Directory. Certos atributos no Active Directory são definidos como atributos de vínculo, conforme determinado por um valor par e que não seja zero no atributo linkID do objeto attributeSchema. Os atributos de vínculo estabelecem uma relação entre os objetos no diretório e podem ter um valor único ou valores múltiplos. O atributo de membro de um objeto de grupo é um exemplo de um atributo de vínculo com valores múltiplos – ele estabelece um vínculo entre o objeto de grupo e seus objetos membro.
Mesmo que pareça que o atributo de membro de um grupo tenha os DNs dos membros (como exibido pelo snap-in de usuários e computadores do Active Directory, por exemplo), essa não é a forma como o Active Directory os armazena. Quando você adiciona o DN de um objeto membro a um atributo de membro de um grupo, o Active Directory armazena o DNT do objeto, não o seu DN. Como o DNT não é alterado, mesmo quando um objeto é renomeado, é possível renomear um objeto de usuário; além disso, o Active Directory não precisará classificar todos os grupos no sistema para atualizar o DN em cada um dos atributos de membro. É assim que o Active Directory mantém a integridade de referência no DIT. A Figura 1 mostra uma representação, embora muito simplificada, de como a tabela de dados e a tabela de vínculos se relacionam. Essas tabelas mostram que os três objetos de usuário – Molly Clark, Alexander Tumanov e Makoto Yamagishi – são todos membros do grupo de Engenheiros seniores.
Figure 1 Como os dados e as tabelas de vínculo estão relacionados (Close Figure 1)

Tabela de dados |  |  |
DNT | PDNT | Classe de objeto | Cn
14529 | 14401 | organizationalUnit | Engenheiros
14530 | 14529 | Grupo | Engenheiros seniores
14531 | 14529 | Usuário | Molly Clark
14532 | 14529 | Usuário | Alexander Tumanov
14533 | 14529 | Usuário | Makoto Yamagishi
Tabela de vínculos |  |  |
Atributo | DNT | Vínculo progressivo |
Membro | 14530 | 14531 |
Membro | 14530 | 14532 |
Membro | 14530 | 14533 |
Esses vínculos são denominados progressivos. Do mesmo modo, o Active Directory também fornece atributos de vínculo regressivo. Eles fornecem uma referência a partir do objeto vinculado de volta ao objeto a que se refere, representando o objeto com o vínculo progressivo. O atributo memberOf attribute para usuários e grupos é um exemplo de um atributo de vínculo regressivo. O objeto attribute-Schema que descreve um atributo de vínculo regressivo tem um valor linkID, o qual é maior que o valor linkID com número par do atributo de vínculo progressivo correspondente. Por exemplo, o atributo de membro no esquema do Windows Server® 2003 R2 tem um valor linkID de 2; o atributo memberOf que serve como vínculo regressivo tem um valor linkID de 3. Para obter mais informações, a Figura 2 fornece uma lista de atributos vinculados, definidos por padrão no esquema do Windows Server 2003 R2.
Figure 2 Atributos de vínculo no esquema do Windows Server 2003 R2 (Close Figure 2)

Atributo do vínculo progressivo | linkID | Atributo do vínculo regressivo | Vinculado
membro | 2 | memberOf | 3
gerente | 42 | directReports | 43
proprietário | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
Os atributos de vínculo regressivo são sempre de valores múltiplos e são mantidos automaticamente pelo Active Directory. Na verdade, não é possível modificar diretamente um atributo de vínculo regressivo. Mesmo que pareça possível modificar o atributo memberOf de um usuário ou grupo usando o snap-in do MMC de usuários e computadores do Active Directory, na verdade o snap-in está modificando o atributo de membro do grupo correspondente, e o Active Directory atualiza o atributo memberOf em segundo plano. É por esse motivo que não são necessárias permissões no objeto de usuário para adicionar o usuário a um grupo; você só estará realmente modificando o atributo de membro do objeto de grupo. Como cada controlador de domínio gerencia seus atributos de vínculo regressivo localmente, as alterações aos vínculos regressivos nunca são replicadas. Somente a alteração ao atributo de vínculo progressivo, como o atributo de membro de um grupo, é replicada.
Em um controlador de domínio normal, a tabela de dados contém entradas de objetos de domínio, bem como de objetos dos recipientes Configuration e Schema. Mas alguns tipos de grupo podem ter referências a objetos que residem em outro domínio. Como o Active Directory armazena um DNT de um objeto que não está na tabela de dados? A resposta depende do proprietário de função de FSMO (Flexible Single Master Operations, operação flutuante de mestre único) de mestre de infra-estrutura e de algo chamado de objeto fantasma.

Objetos fantasma
Quando você adiciona um membro de um domínio a um grupo em outro domínio, o Active Directory cria automaticamente um objeto especial na tabela de dados denominado fantasma, o qual contém o objectGUID, objectSid e DN do novo membro. Isso fornece um DNT que pode ser armazenado no atributo de membro do grupo. Se um controlador de domínio for um catálogo global, ele não precisará criar um fantasma, pois já tem uma entrada em sua tabela de dados para cada objeto na floresta.
O controlador de domínio que detém a função de FSMO de infra-estrutura verifica periodicamente as entradas na sua tabela de dados em comparação a um catálogo global; quando ele detecta que um objeto foi transferido, renomeado ou excluído, ele atualiza os fantasmas na tabela de dados e replica a alteração para os outros DCs no domínio. E devido a uma contagem de referência, o mestre de infra-estrutura também pode remover fantasmas que não são mais mencionados por qualquer atributo de vínculo progressivo no domínio.
Os fantasmas permitem que os DCs gerenciem referências a objetos em outros domínios na floresta; porém, os atributos de vínculo progressivo também podem fazer referência a objetos externos à floresta – por exemplo, em um domínio confiável. Nesse caso, o Active Directory cria um objeto denominado FSP (Foreign Security Principal, entidade de segurança estrangeira) no recipiente CN=ForeignSecurityPrincipals no NC de domínio. A FSP contém o SID (Security Identifier, identificador de segurança) do objeto e outros atributos que identificam o objeto no domínio estrangeiro, mas não há um processo para garantir que a FSP se mantenha atualizada. Para fins de recuperação de dados, tratamos as FSPs como faríamos com qualquer outro objeto do Active Directory.

Excluindo objetos
Nesta seção, meu foco principal será a restauração de usuários e de suas associações de grupo. No entanto, os mesmos princípios se aplicam à recuperação de outros atributos vinculados.
Quando o Active Directory exclui um objeto, ele não o exclui fisicamente da DIT. Em vez disso, ele marca o objeto como excluído, definindo o seu atributo isDeleted como true (verdadeiro), o que resulta no processamento “invisível” do objeto nas operações normais do diretório. O Active Directory remove todos os atributos que não devam ser salvos, como definido pelo esquema, e altera o RDN (Relative Distinguished Name, nome distinto relativo) do objeto para <old RDN>\0aDEL:<objectGUID>. Em seguida, ele move o objeto para o recipiente CN=Deleted Objects do NC. (Há algumas classes de objetos no NC Configuration que o Active Directory não move para o recipiente Deleted Objects.) O Active Directory remove todos os vínculos progressivos a outros objetos que o objeto excluído detenha – o que reduz a sua contagem de referência na tabela de vínculo. Se houver outros objetos que tenham os vínculos progressivos para o objeto agora excluído, o Active Directory também removerá esses vínculos.
O objeto resultante é denominado marca para exclusão. O Active Directory replica essa marca para exclusão para outros DCs, nos quais as mesmas alterações tenham sido feitas. Observe que o Active Directory não replica as alterações feitas nos vínculos progressivos que se refiram ao objeto excluído. Cada controlador de domínio efetua localmente a alteração equivalente; portanto, não há necessidade de replicá-la. Isso apresenta conseqüências para a recuperação de associações de grupo, como abordarei posteriormente no artigo.
O Active Directory mantém objetos marcados para exclusão na DIT, como determinado pelo atributo tombstoneLifetime do objeto CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain>. O processo de coleta de lixo em cada controlador de domínio remove as marcas de exclusão que forem mais antigas do que a vida útil configurada da marca de exclusão. Por padrão, a vida útil da marca de exclusão é de 60 dias para o Windows® 2000, o Windows Server 2003 e o Windows Server 2003 R2. Para o Windows Server 2003 SP1, a vida útil é de 180 dias.
A vida útil da marca de exclusão tem um importante significado no processo de restauração. Não é possível restaurar de um backup que seja mais antigo do que a vida útil da marca de exclusão. Como os objetos que foram excluídos e, em seguida, passaram pela coleta de lixo do domínio não têm mais marcas de exclusão, a operação de exclusão nunca replicará novamente para o controlador de domínio restaurado. Então, os objetos excluídos permanecerão no controlador de domínio restaurado como objetos remanescentes; o controlador de domínio restaurado nunca convergirá adequadamente com os outros DCs no domínio.

Replicando objetos
Sempre que um controlador de domínio executar uma operação de atualização de qualquer tipo – por exemplo, acrescentar um objeto ou modificar um atributo – o controlador de domínio atribui um número exclusivo de 64 bits para a operação de atualização denominado USN (Update Sequence Number, número de atualização de seqüência). O Active Directory marca os objetos e atributos que são atualizados com o USN, a fim de ajudar a determinar se eles precisam ser replicados.
O Active Directory replica objetos por atributo. Ou seja, se você modificar um atributo de um objeto, o Active Directory replicará somente esse atributo, não todo o objeto. Para fazer isso, o Active Directory controla as alterações feitas por ele em cada atributo com metadados de replicação. Os metadados de replicação de um atributo incluem:
  • O USN local, que identifica a operação de alteração no controlador de domínio local.
  • O invocationID do controlador de domínio que originou a alteração (especificamente, o atributo invocationID do objeto nTDSSettings correspondente do controlador de domínio), o que identifica uma geração específica da DIT em um controlador de domínio.
  • O USN da operação original da mesma forma que ele existe no controlador de domínio de origem.
  • Um carimbo de data/hora que contém o horário do sistema do controlador de domínio de quando a alteração de origem foi realizada.
  • Um número de versão seqüencial de 32 bits, o qual será incrementado sempre que o valor for alterado.
Quando um controlador de domínio de destino solicita alterações de seu parceiro de controlador de domínio de origem, ele envia o USN da última alteração replicada com êxito para o controlador de domínio de origem, juntamente com um vetor de atualização, o qual inclui o maior USN de origem visualizado pelo controlador de domínio de destino, a partir de cada controlador de domínio com uma réplica do NC sendo replicado. O controlador de domínio de origem utiliza essa informação, a fim de enviar somente as atualizações que o controlador de domínio de destino ainda não tenha visualizado.
À medida que o controlador de domínio de destino processar as atualizações do atributo de entrada, ele verifica o número de versão de cada atributo. Se o número de versão de um atributo de entrada for maior que a versão que o controlador de domínio já tem para esse atributo, o controlador de domínio armazenará o valor de entrada. Se o número de versão de entrada for igual à versão que o controlador de domínio já tem, o controlador de domínio comparará os carimbos de data/hora e utilizará o atributo com o carimbo de data/hora mais recente. Se os carimbos de data/hora forem os mesmos, o controlador de domínio de destino escolherá o valor com o maior invocationID. Isso garante que cada controlador de domínio eventualmente definirá o mesmo valor para cada atributo replicado.

Replicação de valor vinculado
No Windows 2000, o Active Directory replicava atributos com valores múltiplos da mesma maneira que com os atributos de valor único. Isso causou problemas para grandes objetos de grupo dinâmico, cujo atributo de membro com valores múltiplos poderia ser alterado com freqüência em diferentes controladores de domínio. Se um administrador acrescentasse um usuário a um grupo em um controlador de domínio, e outro administrador acrescentasse um usuário diferente ao grupo em outro controlador de domínio na janela de latência de replicação, o Active Directory escolheria a última adição e perderia completamente a adição anterior. A Microsoft solucionou esse problema no Windows Server 2003 com um processo denominado LVR (Linked Value Replication, replicação de valor vinculado).
Com o nível funcional de floresta ou nível funcional de floresta provisório do Windows Server 2003, o Active Directory replica separadamente os valores individuais de atributos de vínculo progressivo com valores múltiplos, com cada valor tendo seus próprios metadados de replicação. Isso soluciona efetivamente o problema detectado no Windows 2000, no qual a maior parte das atualizações simultâneas de associação de grupo em controladores de domínios diferentes poderia causar a perda dos dados.
No entanto, há um ponto a ser considerado. A elevação do nível funcional de floresta não corrige atualmente os atributos de vínculo com valores múltiplos com os novos metadados de replicação. Somente os valores adicionados depois da elevação do nível funcional de floresta terão os novos metadados. Isso terá um efeito significativo na recuperação de associações de grupo, como você verá a seguir.

Efetuando backup
O Windows inclui o utilitário muito básico NTBACKUP, o qual pode ser utilizado para executar um backup de estado do sistema de um controlador de domínio. O estado de sistema de um controlador de domínio inclui o seu Registro, SYSVOL, arquivos de DIT do Active Directory e arquivos fundamentais do sistema. A maioria dos utilitários de backup de terceiros também tem o recurso de backup e restauração do estado do sistema de um controlador de domínio.
Para executar um backup do estado do sistema para um arquivo de disco, utilize o seguinte comando:
NTBACKUP backup systemstate /F “<filename>”
Nesse caso, <filename> é o nome do arquivo de backup a ser criado e deve utilizar a extensão .bkf.

Executando uma restauração não autoritativa
A restauração de objetos excluídos do Active Directory a partir do backup é um processo de duas etapas. Primeiramente, reinicialize o controlador de domínio no DSRM (Directory Services Restore Mode, modo de restauração dos serviços de diretório); em seguida, restaure toda a DIT do Active Directory a partir do backup do estado do sistema usando o utilitário NTBACKUP do Windows ou um produto equivalente de terceiros. Esse processo substituirá toda a DIT.
Há duas formas de inicializar um controlador de domínio no DSRM. Se você tiver acesso ao console do sistema do controlador de domínio, desligue e reinicie o controlador de domínio e pressione F8 quando solicitado, a fim de ativar o menu de inicialização do Windows. No menu, selecione Restauração dos Serviços de Diretório e digite a senha do DSRM.
Se você estiver gerenciando o servidor remotamente, você não poderá acessar o menu de inicialização do Windows. Em vez disso, você pode alterar as opções de inicialização do sistema selecionando Propriedades em Meu Computador, clicando na guia Avançado e pressionando o botão Configurações, localizado em Inicialização e recuperação. Pressione o botão Editar na seção Inicialização do sistema para editar o arquivo boot.ini e acrescente a opção /SAFEBOOT:DSREPAIR ao final da linha, como mostrado na Figura 3. (Para obter mais informações sobre as opções do boot.ini, consulte microsoft.com/technet/ sysinternals/information/bootini.mspx.)
Figura 3 Definindo as opções de inicialização para o DSRM
Figura 3 Definindo as opções de inicialização para o DSRM (Clique na imagem para diminuir a exibição)
Figura 3 Definindo as opções de inicialização para o DSRM
Figura 3 Definindo as opções de inicialização para o DSRM (Clique na imagem para aumentar a exibição)
Quando você reinicializar o servidor, ele será reinicializado no DSRM. Lembre-se de que, quando reinicializar o controlador de domínio no modo normal, será necessário remover a opção /SAFEBOOT do boot.ini.
Assim que você tiver efetuado logon usando a senha do DSRM, restaure o backup do estado de sistema usando novamente o comando NTBACKUP, mas sem especificar quaisquer parâmetros. (Não é possível executar uma restauração usando o NTBACKUP a partir da linha de comando.) Quando o assistente for iniciado, selecione Restaurar arquivos e configurações e clique em Avançar. Em seguida, selecione o arquivo de backup e marque a caixa Estado do Sistema, como mostrado na Figura 4.
Figura 4 Usando o Assistente de backup ou restauração para restaurar o estado do sistema
Figura 4 Usando o Assistente de backup ou restauração para restaurar o estado do sistema (Clique na imagem para diminuir a exibição)
Figura 4 Usando o Assistente de backup ou restauração para restaurar o estado do sistema
Figura 4 Usando o Assistente de backup ou restauração para restaurar o estado do sistema (Clique na imagem para aumentar a exibição)
Nesse caso, se você reinicializasse o controlador de domínio de volta no modo normal, o processo de replicação do Active Directory ativaria o controlador de domínio restaurado novamente para a sincronização com os outros controladores de domínio no domínio, e todos os dados restaurados seriam substituídos pelos dados atuais. Sem dúvida, esse não é o seu objetivo. Em vez disso, você precisa de um modo para forçar os objetos sendo restaurados a se replicarem em outros controles de domínio no domínio.

Executando uma restauração autoritativa
O NTDSUTIL também aumenta em 100.000 o número de versão de cada atributo para cada dia entre a data do backup e a data da restauração. A menos que haja mais atributos sendo atualizados mais de 100.000 vezes por dia (um cenário muito improvável), o número de versão dos atributos restaurados será muito maior que os números de versão mantidos por outros controladores de domínio; além disso, o objeto restaurado de modo autoritativo se replicará para outros controladores de domínio. Os outros objetos que foram restaurados de forma não autoritativa a partir do backup serão, por fim, substituídos pelos dados existentes a partir de outros controladores de domínio.
Depois de concluir a restauração não autoritativa, mas antes de reinicializar em modo normal, use o programa NTDSUTIL para executar uma restauração autoritativa dos objetos que deseja recuperar. Apesar do nome, a restauração de modo autoritativo de um objeto não o “restaura”; ela simplesmente garante que o Active Directory replicará o objeto em outros controladores de domínio. Para fazer isso, o NTDSUTIL atribui a próxima variável USN ao USN local dos atributos do objeto. Isso faz com que o objeto seja enviado para parceiros de replicação na próxima vez que eles efetuarem a sincronização. Para restaurar um único objeto, certifique-se de que o controlador de domínio seja inicializado no DSRM e siga estas etapas:
  1. Abra uma janela de comando e digite:
    ntdsutil
  2. No prompt ntdsutil, digite:
    authoritative restore
  3. No prompt de restauração autoritativa, digite:
    restore object “<DN of object to be restored>”
    Por exemplo, se você quiser restaurar a conta de Molly Clark a partir da unidade organizacional de engenharia no domínio DRNET, você deveria digitar:
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    Se quiser restaurar de modo autoritativo toda a subárvore do diretório (por exemplo, uma unidade organizacional), então você deveria digitar:
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    (O NTDSUTIL também fornece um comando de restauração de banco de dados, o qual restaura de modo autoritativo todo o domínio, bem como os NCs de configuração e esquema.) A restauração de todo o domínio é muito perigosa; portanto, não recomendo o uso dessa opção. Se você precisar restaurar um domínio completo, restaure um controlador de domínio e promova novamente os outros controladores de domínio no domínio, como descrito em “Planejando a recuperação de floresta do Active Directory”,
  4. Quando solicitado, confirme se a restauração autoritativa deve aumentar os números de versão dos respectivos objetos e seus atributos.
  5. Saia do ntdsutil (você não precisará digitar “quit” duas vezes).
  6. Reinicialize o controlador de domínio no modo normal do Active Directory.
Na próxima vez que o controlador de domínio se replicar com seus parceiros, o usuário restaurado será replicado. No entanto, a restauração do objeto de usuário é somente uma parte do problema. Quando você introduz vínculos de objeto como aqueles entre um grupo e seus membros, a situação é mais complicada. Há alguns problemas fundamentais a serem enfrentados durante e depois da restauração, os quais descreverei nas próximas seções.
Primeiramente, vamos rever o que acontece quando você exclui um objeto com vínculos regressivos. Digamos que você exclua um objeto de usuário que seja um membro de um ou mais grupos. Cada controlador de domínio que tiver uma cópia do objeto de usuário o converterá para uma marca de exclusão, bem como removerá quaisquer referências da tabela de vínculos; portanto, o objeto de usuário será removido de quaisquer associações de grupo no domínio do usuário. (Lembre-se de que remover o usuário das associações de grupo não é uma alteração replicada, pois cada controlador de domínio atualiza a associação de grupo localmente. O número de versão e o USN local do atributo de membro do grupo permanecem inalterados.) Pouco tempo depois, os objetos fantasma serão removidos das tabelas de vínculo em outros domínios, sem atualizar os metadados de replicação do atributo de membro do grupo.
Quando você restaurar de forma não autoritativa a DIT em um controlador de domínio no domínio do usuário, você pode recuperar o objeto de usuário junto com todas as outras associações de grupo no domínio, de forma que o controlador de domínio restaurado seja autoconsistente. E depois que você usar o utilitário NTDSUTIL para restaurar de forma autoritativa o usuário, o objeto de usuário será replicado em todos os outros controladores de domínio no domínio.
Porém, como os metadados de replicação dos grupos atuais no domínio estão inalterados, os atributos de membro dos grupos no controlador de domínio restaurados são inconsistentes com aqueles nos outros controladores de domínio. Além disso, não há nada a ser feito para a convergência deles em um estado comum. Dessa forma, as associações de usuário não serão restauradas nos outros controladores de domínio no domínio.

O problema: as associações de grupo no domínio não são restauradas
A restauração de forma autoritativa do objeto de usuário não recupera as associações de grupo de usuário. Por que não? Como a relação de associação é armazenada e replicada usando o atributo de membro dos objetos de grupo (os vínculos progressivos), não o atributo memberOf do usuário (o vínculo regressivo). O problema é como localizar as associações do grupo anterior de usuário e, assim que souber quais são, como recuperá-las corretamente.
A Microsoft efetuou aprimoramentos graduais no processo de recuperação de associações de um grupo de usuário, de forma que a técnica utilizada depende da versão do Active Directory que você estiver executando. A seção a seguir aplica-se principalmente ao Active Directory do Windows 2000.
É muito fácil determinar as associações de grupo anterior do usuário: basta inspecionar o atributo de vínculo regressivo no controlador de domínio restaurado – nesse caso, o atributo memberOf do objeto de usuário. O atributo memberOf terá todas as associações a grupos locais e globais no domínio de usuário. Você pode usar o snap-in do MMC de usuários e computadores do Active Directory (ADUC, Active Directory Users and Computers) ou usar o utilitário LDIFDE, o qual está incluído no Windows Server, a fim de obter uma lista das associações de grupo de usuário.
A linha de comando do LDIFDE a seguir apresentará uma lista dos grupos no domínio DRNET ao qual Molly Clark pertence como membro, armazenando os resultados no arquivo output.ldf:
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
Observe que você deve reinicializar o controlador de domínio no modo normal, a fim de usar quaisquer ferramentas LDAP e, novamente, deve desabilitar a replicação de entrada; caso contrário, os dados restaurados serão substituídos. A forma mais fácil de desabilitar a replicação de entrada é usar o comando REPADMIN:
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
Aqui, <dcname> é o nome do controlador de domínio para o qual você está restaurando. Além disso, quando tiver concluído, não se esqueça de habilitar novamente a replicação utilizando –DISABLE_INBOUND_REPL.
Se você estiver recuperando apenas alguns usuários, é muito fácil adicionar manualmente o usuário de volta aos grupos usando o ADUC. Se você estiver recuperando um número maior de usuários, existem algumas ferramentas que podem automatizar parte do processo. O utilitário GROUPADD da Microsoft (disponível a partir do Atendimento Microsoft) pode aceitar o arquivo LDIF que você criou, a fim de obter uma lista das associações de grupo anterior de usuário e, por sua vez, gerar um arquivo LDIF, o qual recria essas associações. Por exemplo, você utilizaria esse comando GROUPADD para processar o arquivo LDIF que criamos no exemplo anterior para Molly Clark:
C:\> groupadd /after_restore output.ldf
Esse comando criará um novo arquivo LDIF para cada domínio no qual Molly Clark tiver associações de grupo com o nome groupadd_<domain>.ldf (onde <domain> é o nome de domínio totalmente qualificado cujos grupos serão atualizados). Você importaria o arquivo LDIF criado acima com o comando a seguir:
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
Com o Windows Server 2003, a Microsoft aprimorou o NTDSUTIL para aproveitar os metadados adicionais presentes no atributo de membro, a fim de oferecer suporte à replicação de LVR (Linked Value Replication, replicação de valor vinculado). Se o objeto de usuário restaurado tiver sido um membro de qualquer grupo no domínio e a associação de grupo de usuário tiver sido armazenada nos metadados da LVR, o NTDSUTIL aumentará o número de versão do valor correspondente do atributo de membro, o que então faz com que a associação restaurada se replique.
A versão do Windows Server 2003 SP1 do NTDSUTIL incorpora as funções GROUPADD e criará automaticamente arquivos LDIF, à medida que ele executar a restauração autoritativa do objeto de usuário. A Figura 5 mostra a nova versão do NTDSUTIL; a Figura 6 exibe o conteúdo do arquivo LDIF criado automaticamente.
Figure 6 Conteúdo do arquivo LDIF criado pelo NTDSUTIL (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
Figura 5 Novo NTDSUTIL com recursos GROUPADD internos
Figura 5 Novo NTDSUTIL com recursos GROUPADD internos (Clique na imagem para diminuir a exibição)
Figura 5 Novo NTDSUTIL com recursos GROUPADD internos
Figura 5 Novo NTDSUTIL com recursos GROUPADD internos (Clique na imagem para aumentar a exibição)
Se você estiver restaurando uma unidade organizacional completa que tenha vários usuários e grupos, o acréscimo manual de usuários de volta para os seus grupos será um tanto tedioso. Outra forma de recuperar as associações de grupo restauradas é restaurar de forma autoritativa os próprios grupos.
Entretanto, há dois problemas com a restauração de forma autoritativa de grupos. O primeiro problema é razoavelmente óbvio: se você restaurar um grupo, a associação nesse grupo reverterá para o seu estado durante o backup. Isso significa que quaisquer alterações que você tiver feito no grupo desde o último backup precisarão ser aplicadas novamente no grupo. O segundo problema é um pouco mais sutil e tem a ver com a forma como a replicação funciona no Active Directory. Depois de uma restauração autoritativa de usuários e grupos, não há garantia sobre qual ordem eles serão replicados. Se um objeto de grupo se replicar para um controlador de domínio antes do objeto de usuário, o controlador de domínio da replicação removerá automaticamente a referência de usuário do grupo, pois o objeto de usuário ainda não existe nesse controlador de domínio. Quando o objeto de usuário for replicado posteriormente, ele não será adicionado ao grupo.
A solução mais fácil para esse problema é executar uma segunda vez a restauração autoritativa dos grupos. Depois de executar a primeira restauração autoritativa, reinicialize em modo normal e certifique-se de que a replicação seja realizada corretamente. Em seguida, reinicialize novamente no DSRM e execute o NTDSUTIL, a fim de realizar uma restauração autoritativa dos grupos nos quais o usuário era um membro. Isso garante que, quando você inicializar novamente no modo normal, o objeto de usuário será replicado antes que os objetos de grupo fazendo referência a ele se repliquem.

O problema: as associações de grupo em outros domínios não são restauradas
O problema “a quais grupos esse usuário pertencia como membro” é de fato mais difícil do que eu descrevi. O usuário que você estiver restaurando pode ter sido um membro dos grupos de domínio local e universais em outros domínios; essas associações de grupo não serão restauradas quando você efetuar a restauração não autoritativa. Portanto, como você sabe a quais grupos o usuário pertencia em outros domínios? A resposta está no catálogo global. Junto com seus próprios dados do domínio, o catálogo global contém uma cópia somente leitura dos dados de outros domínios na floresta.
Para aproveitar os dados abrangendo toda a floresta do catálogo global, você deve executar a restauração não autoritativa em um catálogo global, o que significa que você já deve ter feito backup de um catálogo global com o qual começará. Agora, quando você executar o LDIFDE para identificar as associações de grupo de usuário, você pode localizar as associações de grupo universal de outros domínios.
Quando você relacionar a lista das associações de grupo de usuário que está recuperando, conecte a porta 3268 do catálogo global em vez da porta 389 padrão e especifique o domínio-raiz da floresta como a base da pesquisa. O LDIFDE exibirá as associações de grupo de usuário recuperadas, inclusive a associação nos grupos universais em todos os domínios na floresta. Veja como fazer isso:
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
Se você executar o GROUPADD ou o novo NTDSUTIL em um catálogo global, você produzirá um arquivo LDIF para cada domínio no qual o usuário restaurado era membro de um grupo universal. Quando você importar esses arquivos LDIF, você irá restaurar todas as associações de grupo do usuário. Bem, quase tudo – o que nos apresenta o próximo problema.

O problema: recuperar associações de grupo local de domínio em outros domínios
Há três tipos de grupos em um ambiente do Active Directory do Windows. Os grupos globais podem conter somente membros no mesmo domínio, mas podem ser usados como membro em grupos locais de domínio em seu próprio domínio e em outros domínios na floresta. O atributo de membro dos grupos globais não aparece no catálogo global, mas não é um problema, pois os grupos globais contêm somente membros de seu próprio domínio. Os grupos universais podem conter membros de qualquer domínio e podem ser usados como membros em outros grupos universais na floresta, bem como em grupos locais de domínio em seu próprio domínio e em outros domínios na floresta. O atributo de membro de grupos universais é replicado em catálogos globais. Os grupos locais de domínio podem conter membros de qualquer domínio na floresta, mas não podem ser usados como membros em grupos em outros domínios. Mais importante, o atributo de membro dos grupos globais de domínio, como o dos grupos globais, não aparece no catálogo global. O resultado é que não há uma forma mais fácil de recuperar a associação de usuário nos grupos locais de domínio em outros domínios.
Antes do Windows Server 2003 SP1, a única forma de recuperar as associações de grupo local de domínio em domínios estranhos era restaurar um controlador de domínio em cada domínio, procurando manualmente os dados de domínio de quaisquer grupos locais de domínio que tivessem o usuário restaurado e, em seguida, adicionar o usuário de volta aos grupos identificados. Em um amplo ambiente com muitos domínios, essa abordagem é extremamente demorada.
A versão do Windows Server 2003 SP1 do NTDSUTIL pode auxiliar. Quando você executar o NTDSUTIL em um controlador de domínio, o utilitário cria um arquivo de texto que contém o DN e o GUID dos objetos de usuário restaurados. Dessa forma, para cada domínio estrangeiro, agora você pode restaurar de forma não autoritativa um único controlador de domínio, copiar o arquivo de texto no controlador de domínio e executar o NTDSUTIL, a fim de gerar um novo arquivo LDIF específico de domínio, o qual adiciona o usuário recuperado de volta nos grupos locais de domínio do qual ele era membro.
Para fazer isso, execute as etapas a seguir em um controlador de domínio em cada domínio estrangeiro:
  1. Inicialize o controlador de domínio no domínio estrangeiro no DSRM.
  2. Use o NTBACKUP para restaurar uma cópia da DIT, a qual contém as associações de grupo de usuário restauradas.
  3. Copie o arquivo .txt criado pelo NTDSUTIL no atual controlador de domínio.
  4. Abra uma janela de comando e digite “ntdsutil”.
  5. Digite “authoritative restore”.
  6. Digite “create LDIF file(s) from <file name>” (onde <file name> é o nome do arquivo de texto).
  7. Digite “quit” duas vezes para sair do ntdsutil.
  8. Reinicialize o controlador de domínio no modo normal do Active Directory.
  9. Digite “ldifde –i –f <ldif filename>” (onde <ldif filename> é o nome do arquivo LDIF que você acabou de criar).
Agora você restaurou todas as associações de grupo de usuário excluídas.

Passo a passo
A recuperação de usuários e suas associações de grupo do Active Directory, especialmente em um ambiente com vários domínios, é complicada. As etapas específicas necessárias para recuperar adequadamente as associações de grupo dependem da versão do Windows que você está executando.
Se você estiver executando o Windows 2003 SP1, você executaria as seguintes etapas:
  1. Inicialize um catálogo global no DSRM e execute uma restauração do estado do sistema usando um backup que contenha o usuário excluído.
  2. Use o NTDSUTIL para executar uma restauração autoritativa do usuário excluído. O NTDSUTIL criará um arquivo de texto contendo os DNs e GUIDs do objeto restaurado, bem como um ou mais arquivos LDIF para restaurar as associações de grupo de usuário.
  3. Use LDIFDE –i –f <LDIF filename> (onde <LDIF filename> é o nome dos arquivos LDIF criados na etapa 2) para importar as associações de grupo no domínio atual e em outros domínios.
  4. Reinicialize o catálogo global no modo normal.
  5. Em um controlador de domínio em cada domínio estrangeiro, inicialize no DSRM e execute uma restauração do estado do sistema usando um backup que contenha as associações de grupo do usuário restaurado.
  6. Execute o NTDSUTIL usando o comando “create ldif files”.
  7. Reinicialize o controlador de domínio no modo normal.
  8. Usando LDIFDE –i –f <filename> (onde <filename> é o nome do arquivo LDIF criado na etapa 6) para restaurar as associações de grupo no domínio estrangeiro.
  9. Nesse momento, você pode, opcionalmente, forçar a replicação com REPADMIN /syncall.
Se você estiver executando uma versão do Windows Server 2003 sem o SP1 instalado ou se estiver executando o Windows 2000, há algumas etapas adicionais envolvidas. Como a versão anterior do NTDSUTIL não cria arquivos LDIF, use o utilitário GROUPADD para criá-los. O processo é:
  1. Inicialize um catálogo global no DSRM e execute uma restauração do estado do sistema usando um backup que contenha o usuário excluído.
  2. Desabilite a placa de interface de rede ou desconecte o cabo para impedir a replicação de entrada.
  3. Reinicialize o catálogo global no modo normal.
  4. Use LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf para despejar a associação do usuário com o nome distinto <dn>.
  5. Use GROUPADD /after_restore membership.ldf para criar arquivos LDIF.
  6. Use LDIFDE –i –f <filename> (onde <LDIF filename> é o nome do arquivo LDIF criado pelo GROUPADD na etapa 5) para importar as associações de grupo no domínio atual e em outros domínios.
  7. Habilite novamente a replicação de entrada usando as REPADMIN /options <dcname> -DISABLE_INBOUND_REPL.
  8. Em um controlador de domínio em cada domínio estrangeiro, inicialize no DSRM e execute uma restauração do estado do sistema usando um backup que contenha as associações de grupo do usuário restaurado.
  9. Reinicialize o controlador de domínio no modo normal.
  10. Usando LDIFDE –i –f <filename> (onde <filename> é o nome do arquivo LDIF criado pelo GROUPADD na etapa 5) para restaurar as associações de grupo no domínio estrangeiro.
  11. Nesse momento, você pode, opcionalmente, forçar a replicação com REPADMIN /syncall.
A única coisa que falta agora para o ambiente anterior ao Windows Server 2003 SP1 é recuperar as associações de grupo local de domínio estranho do usuário restaurado. As suas únicas opções são: restaurar manualmente as associações de grupo local de domínio; ou restaurar um controlador de domínio do backup e restaurar de forma autoritativa os grupos locais de domínio.

Resumo
Apesar de ser relativamente fácil excluir acidentalmente usuários ou até mesmo unidades organizacionais do Active Directory, a recuperação adequada de usuários excluídos e suas associações de grupo pode ser surpreendentemente complexa, demorada e propensa a erro. Para garantir que seja possível recuperar a partir desses tipos de desastres o mais rápido possível, é necessário compreender a mecânica do vínculo de objetos, da replicação, da exclusão e das restaurações autoritativas.
Você acha que consegue realizar todas as etapas no seu ambiente de produção na primeira tentativa? Para certificar-se de que você esteja pronto na próxima vez em que precisar recuperar o objeto de usuário do presidente, tenha um plano por escrito preparado para a recuperação de objetos excluídos. Além disso, certifique-se pôr o plano em prática pelo menos uma ou duas vezes antes de tentar executá-lo em dados reais. O seu chefe (e o seu presidente) agradecerá!
Recursos adicionais
  • Como restaurar contas de usuário excluídas e suas associações de grupo no Active Directory
  • Atendimento Microsoft
  • Guia passo a passo para gerenciar o Active Directory

Gil Kirkpatrick é Diretor de tecnologia da NetPro e trabalha com o desenvolvimento de software para o Active Directory desde 1996. Juntamente com Guido Grillenmeier, da HP, ele apresenta os conhecidos workshops sobre Recuperação de desastres do Active Directory. Gil também é fundador da Directory Experts Conference (Conferência de especialistas do Active Directory) (www.dec2007.com).


 Administra&#231;&#227;o do Windows: Por que o Windows XP Embedded &#233; importante para voc&#234;
Administração do Windows Don Jones

Por que o Windows XP Embedded é importante para você
Visão geral:
  • Por dentro do Windows XP Embedded
  • Opções especiais de hardware
  • Personalizando o Windows XP Embedded

O Windows XP Embedded é a versão dividida em componentes do Windows, a qual é associada com freqüência aos dispositivos eletrônicos de consumidores, como equipamentos ou decodificadores de sinais. Porém, o Windows XP Embedded também pode ser uma solução adequada para TI da sua empresa. Apesar de poder não ser a
solução para todos os seus usuários, mas há alguns cenários muito específicos em que ela oferece redução da sobrecarga administrativa, hardware potencialmente mais barato e menor e maior segurança.

O que é o Windows XP Embedded?
O Windows® XP Embedded é uma das três versões com pequeno consumo do Windows, junto com o Windows Embedded CE e o Windows Embedded for Point of Service. Dos sistemas operacionais incorporados do Windows, somente o Windows XP Embedded oferece total funcionalidade – ou, pelo menos, o potencial para a funcionalidade completa – de um computador cliente do Windows XP Professional. Ele é baseado no Windows XP Professional Service Pack 2 (SP2); no entanto, o Windows XP Embedded é diferente do Windows XP regular no seu nível extremo de modularização. O Windows XP Embedded não tem o que você chamaria de imagem de instalação padrão. Em vez disso, você usa um kit de ferramentas chamado de Windows Embedded Studio, a fim de criar um ambiente Windows XP Embedded personalizado para qualquer dispositivo que esteja criando e que o ambiente inclua somente a funcionalidade necessária ao seu dispositivo. Se você não precisar do DirectX® ou do Windows Explorer, simplesmente não os instale. Essa modularização significa que cada imagem do Windows XP Embedded que você criar e implantar terá menos partes móveis; portanto, digamos, menos esforço administrativo e maior segurança, bem como a capacidade de execução em hardware de custo inferior. Algumas das opções disponíveis podem ser vistas no Target Designer (parte do Windows Embedded Studio), como mostrado na Figura 1.
Figura 1 Selecionando componentes no Target Designer
Figura 1 Selecionando componentes no Target Designer (Clique na imagem para diminuir a exibição)
Figura 1 Selecionando componentes no Target Designer
Figura 1 Selecionando componentes no Target Designer (Clique na imagem para aumentar a exibição)

Um local na empresa
Um crescente número de cenários de usuário são ideais para um dispositivo baseado em Windows XP Embedded. Por exemplo, considere as empresas que mantêm grandes centros de atendimento ao cliente. Em muitos casos, todos os representantes do centro de atendimento precisam de um ou dois aplicativos desenvolvidos internamente e talvez um navegador da Web. Eles estão usando somente uma fração dos recursos do seu computador, de forma que o Windows XP Embedded permite que você remova esses recursos e deixe somente os necessários. Menor funcionalidade significa que menos área de superfície está exposta a erros ou possíveis ataques de segurança.
Como os dispositivos do Windows XP Embedded possuem funcionalidade limitada, eles podem ser executados em hardware menos potente, com freqüência mais barato. Vários fabricantes produzem placas-mãe que usam processadores compatíveis com Intel de baixo consumo de energia. Essas placas-mãe são extremamente pequenas, usam muito pouca energia e, freqüentemente, nem mesmo usam um ventilador, pois são executadas com a refrigeração suficiente. Elas funcionam muito bem para um dispositivo incorporado e de consumo pequeno, capaz de executar somente em um conjunto limitado de aplicativos.

Os superpoderes especiais do Windows XP Embedded
O Windows XP Embedded oferece algumas opções muito valiosas que não estão disponíveis na versão completa do Windows XP. O Enhanced Write Filter (EWF), Hibernate Once e o Resume Many (HORM) podem simplificar as suas tarefas de administração do Windows. O EWF é um componente opcional que você adicionar a uma implantação do Windows XP Embedded e que torna um volume do disco como somente leitura. Uma atividade de gravação direta no disco é desviada para uma sobreposição, a qual pode estar localizada em outro disco ou até mesmo na memória. O próprio sistema operacional visualiza a sobreposição de EWF e seu volume-pai como uma única unidade, o que significa que se parece como um volume de disco normal. No entanto, por trás disso, o volume-pai não está de fato sendo alterado; as alterações são feitas somente na sobreposição de EWF. De certa forma, isso pode ser benéfico. Imagine implantar uma imagem do Windows XP Embedded em uma placa Compact Flash (CF) (as imagens do Windows XP Embedded podem ter apenas 5 MB e, com freqüência, verificam em torno de 200 MB, de forma que o CF tem bastante capacidade de armazenamento). Essa placa CF pode se conectar a um adaptador e conectar-se a um conector IDE da placa-mãe, fazendo com que a placa CF se pareça com um disco fixo normal. As atuais placas de CF possuem capacidade limitada de gravação (em torno de 100.000 gravações), de forma que o EWF seria utilizado para tornar o volume de CF como somente leitura. Imagine colocar a sobreposição de EWF em RAM: se o usuário cometer um engano; basta desativar a máquina. A sobreposição de EWF e quaisquer alterações feitas à máquina serão perdidas imediatamente. Quando você reinicializar, você estará voltando para o ponto de início armazenado na placa CF. Você pode usar a mesma configuração de uma imagem baseada em CD ou DVD; como esses tipos de mídia são inerentemente somente leitura; o EWF captura qualquer atividade de gravação em uma sobreposição. Mesmo se a sobreposição estiver armazenada em um disco rígido interno pequeno, você terá a garantia de que o volume original de inicialização (em CD ou DVD) não será alterado; se você precisar restaurar a máquina para a sua configuração original, basta apagar a sobreposição de EWF.
O HORM, como o nome sugere, permite que você hiberne uma máquina uma vez e, em seguida, retome do ponto de hibernação quantas vezes for necessário novamente. O computador é ativado quase que instantaneamente. Basta configurar o computador e colocar todos os aplicativos necessários em execução e, em seguida, hiberná-lo. A partir desse ponto, sempre que você ativar a máquina, você somente precisará aguardar alguns segundos para que tudo volte a funcionar novamente.

Criando uma imagem do Windows XP Embedded
A Microsoft possui um programa Embedded Partner que consiste em empresas especializadas em trabalhar com o Windows XP Embedded (você pode obter uma lista dessas empresas na página inicial do Windows XP Embedded no site microsoft.com/embedded). No entanto, com muitas empresas fornecendo aos seus fabricantes de PC normal imagens de pré-criação (que incluem aplicativos corporativos e configurações específicas), você pode querer criar as suas próprias imagens do Windows XP Embedded, as quais você pode compartilhar com um Embedded Partner fornecendo a você sistemas completos com pouco consumo. O Windows Embedded Studio, que é instalado no Windows XP Professional, pode ser usado para criar e gerenciar as imagens do Windows XP Embedded.
Para usar o kit de ferramentas, primeiro instale a versão completa do Windows XP Pro no hardware que você pretende usar no seu sistema Windows XP Embedded. Isso permite que você use a rotina completa de instalação do Windows XP para que todo o hardware funcione corretamente. Em seguida, instale o Windows Embedded Studio. Isso geralmente instala um banco de dados que é utilizado para gerenciar imagens incorporadas, mas o banco de dados pode na verdade ser instalado em qualquer parte, fornecendo um repositório central. Em seguida, você executará um utilitário da linha de comando denominado Tap.exe, que cria um novo componente especial, o qual pode ser utilizado pelo Windows XP Embedded. Geralmente, os componentes encapsulam a funcionalidade, como um media player, um sistema de arquivos ou outros aplicativos personalizados; nesse caso, você estará criando um componente que contém os drivers de dispositivo de hardware necessários para seu sistema específico. Essa etapa deve ser concluída no hardware de destino, de forma que a ferramenta possa detectar e incluir os drivers de hardware apropriados.
Na próxima etapa, execute o Windows XP Embedded Component Designer e importe o pacote de componente criado pelo utilitário Tap.exe. Como mostrado na Figura 2, o Component Designer lê as informações do dispositivo e monta um componente completo do Windows XP Embedded, o que pode se tornar a base para uma nova imagem do Windows XP Embedded. Isso simplificará o processo ao determinar exatamente quais drivers de dispositivo para determinada plataforma serão necessários. Depois de criar o componente, use o Component Database Manager para importar o novo componente para o banco de dados de componente do Windows XP Embedded, um repositório no qual todos os componentes do Windows XP Embedded são armazenados. Ter o componente no banco de dados o disponibiliza para uso nas imagens do Windows XP Embedded.
Figura 2 Component Designer
Figura 2 Component Designer (Clique na imagem para diminuir a exibição)
Figura 2 Component Designer
Figura 2 Component Designer (Clique na imagem para aumentar a exibição)
Agora você já está pronto para criar uma nova configuração de destino, usando o Windows XP Embedded Target Designer, a ferramenta na qual você realizará a maior parte do trabalho real. Como observado na Figura 1, você adicionará os componentes necessários para criar o conjunto de funções que o seu dispositivo requer. Você também precisará adicionar alguns componentes fundamentais do Windows, como Windows Explorer (se o seu dispositivo exigir um shell gráfico), o sistema de arquivos NTFS (ou FAT32), NT Loader, suporte a um idioma, núcleo da interface do usuário e assim por diante. Mais de dez mil componentes estão disponíveis por padrão.
Você também pode pré-configurar cada componente. Por exemplo, o componente principal da interface do usuário pode ser personalizado para exibir itens específicos no menu Iniciar do Windows, na área de trabalho e em outros locais. A personalização das configurações de cada componente garante que cada dispositivo será pré-configurado para atender às suas necessidades (consulte a Figura 3).
Figura 3 Personalizar configurações
Figura 3 Personalizar configurações (Clique na imagem para diminuir a exibição)
Figura 3 Personalizar configurações
Figura 3 Personalizar configurações (Clique na imagem para aumentar a exibição)
A parte mais difícil de uma imagem do Windows XP Embedded são as dependências. Por exemplo, você não pode adicionar um componente DirectX à sua imagem sem também adicionar vários componentes que forneçam ao Windows os seus recursos principais de tratamento de gráficos. Controlar todas as dependências pode ser muito difícil, especialmente para imagens maiores e mais complexas que podem ter literalmente centenas de dependências. Trata-se de um trabalho do banco de dados do componente. Basta pressionar F5 no Target Designer e ele verificará cada componente acrescentado, adicionando automaticamente quaisquer dependências que os seus componentes relacionados exijam. A Figura 4 mostra a verificação em andamento; essa é uma etapa crítica e que permite que o Windows XP Embedded seja tão modularizado. Com essa inteligência incorporada no Target Designer, seria muito difícil criar com êxito imagens que tivessem todas as dependências corretas.
Figura 4 Verificação de dependência
Figura 4 Verificação de dependência (Clique na imagem para diminuir a exibição)
Figura 4 Verificação de dependência
Figura 4 Verificação de dependência (Clique na imagem para aumentar a exibição)
Quando todos os seus componentes e suas dependências tiverem sido adicionados, você pode criar a sua própria imagem do Windows XP Embedded. As imagens são simplesmente os arquivos que precisam ser copiados para o volume de inicialização do seu dispositivo do Windows XP Embedded. Você não precisa de ferramentas especiais para implantá-las (embora o conjunto de ferramentas do Windows XP Embedded inclua um servidor de inicialização remoto semelhante na funcionalidade para os Serviços de Instalação Remota; ele permite a implantação das imagens do Windows XP Embedded para hardware bare-metal). Depois de concluir essas etapas, você pode ver de fato como a sua imagem é grande. Criei uma imagem muito básica que incluía o shell do Explorer e alguns aplicativos, como o Notepad e Paint, e criei uma imagem de menos de 90 megabytes. Com certeza, você provavelmente não encontrará muitos usuários interessados em um dispositivo que execute somente o Notepad e Paint, mas ele ilustra como uma imagem específica por tarefa pode ser.

Windows XP Embedded vs. Windows XP
O Windows XP Embedded não é uma opção de sistema operacional dividido. A Microsoft disponibiliza componentes pré-empacotados que permitem que um computador executando o Windows XP Embedded tenha muito da mesma funcionalidade de uma versão completa do Windows XP. Isso inclui opções para instalar o DirectX 9.0c, o Microsoft® .NET Framework, Windows Media® Player 10 e muito mais. Você também encontrará muita documentação de desenvolvedor que descreve como criar componentes personalizados, como um shell personalizado para substituir o Explorer, permitindo que você crie um ambiente desenvolvido para o seu dispositivo específico do Embedded.
No entanto, o Windows XP Embedded não oferece todos os recursos incluídos na versão completa do Windows XP Pro. Por exemplo, o Windows File Protection (WFP) não está incluído no Windows XP Embedded; nem inclui alguns dos recursos facilitadores para o usuário, como o Windows XP Tour, as telas inicias de boas-vindas e os assistentes que ajudam um novo usuário a configurar o seu computador ou a Instalação do Windows. O Windows XP Embedded não utiliza a Ativação do Produto do Windows (as imagens do Windows XP Embedded são ativados usando uma chave de produto do tempo de execução a partir das ferramentas do Windows Embedded Studio). O que é mais notável é que o Windows XP Embedded não usa o Windows Update, embora ela possa usar o servidor do Microsoft Software Update Services no seu ambiente. Finalmente, o Windows XP Embedded também não tem o MSN® Explorer, que está incluído no Windows XP Pro.
Pensando no futuro, o Windows XP Embedded continua um ciclo de desenvolvimento avançado: agora está disponível o Feature Pack 2007, adicionando novos recursos, como a inicialização baseada em USB, um aprimoramento para EWF que permite que novos arquivos sejam confirmados no volume-pai sem comprometer toda a sobreposição, oferece suporte para compactação NTFS e muito mais. Esses aprimoramentos continuam acrescentando flexibilidade e opções ao sistema operacional Windows XP Embedded e ao mesmo tempo oferecendo um conjunto de recursos no Windows XP Professional.

Usando o Embedded
Os sistemas incorporados podem apresentar um pouco mais de trabalho na criação do que um sistema Windows XP tradicional, mas eles oferecem vantagens significativas em determinados cenários. Embora reduzido na funcionalidade, os sistemas do Windows XP Embedded podem oferecer hardware menor, que usem menos energia e sejam mais fáceis de manter e reparar e podem custar significativamente menos. O consumo de menos energia também ajuda a reduzir as contas e geração de energia, permitindo mais flexibilidade no desenvolvimento de espaços de trabalho compactos. Além dos usos esperados do Windows XP Embedded – dispositivos do consumidor, dispositivos de equipamentos médicos, quiosques e outros locais em que você pode não ter percebido que o Windows XP Embedded é utilizado –, esse sistema operacional incorporado pode ser também uma solução para sua empresa.

Don Jones é o diretor de projetos e serviços da SAPIEN Technologies e co-autor do Windows PowerShell: TFM (SAPIEN Press). Entre em contato com Don em seu site em www.ScriptingAnswers.com.


 Gerenciamento: Planeje com anteced&#234;ncia com o System Center Capacity Planner
Gerenciamento John Savill

Planeje com antecedência com o System Center Capacity Planner
Visão geral:
  • Fundamentos de SCCP
  • Criação de novo modelo
  • Ajuste fino de modelo
  • Simulação do uso real

Os componentes das atuais infra-estruturas são fundamentais para os negócios que elas mantêm. No entanto, como o número de usuários aumenta e as empresas se tornam mais diversificadas, a estimativa precisa do tamanho e
do número de servidores executando os componentes se tornou um desafio. A insuficiência de hardware ocasiona tempos insatisfatórios de resposta para usuários finais, e hardware em excesso simplesmente representa perda de orçamento e requer gerenciamento adicional. Por esse motivo, a Microsoft criou o System Center Capacity Planner (SCCP) 2006.
Em um nível superior, o SCCP permite que você insira informações sobre a topologia de rede (localizações, velocidades de link, latência), software e hardware a ser utilizado e perfis de uso (como número de mensagens enviadas). O SCCP executa então simulações de níveis diferentes de uso e detalhes de utilizações de hardware e dos componentes de rede. Esse modelo ajuda a determinar a configuração proposta que seria adequada para atender aos requisitos de serviço, se implementado.
O SCCP não precisa ser executado em qualquer servidor específico ou executar testes de rede; ele é essencialmente uma ferramenta de simulação que pode executar cenários de teste em um ambiente com modelo. Os requisitos reais do sistema para SCCP são mínimos: o Windows® XP com Service Pack 2 (SP2), o Windows Server® 2003 ou Windows 2000 com SP4, além do Microsoft® .NET Framework 2.0. A próxima geração do SCCP pode ter uma interface mais semelhante ao Systems Management Server (SMS) e ao Microsoft Operations Manager (MOM), bem como ser automatizada com parte da informação obtida, pois o MOM já coleta informações sobre a utilização do servidor e o SMS mantém as informações sobre a configuração do hardware.
A instalação do SCCP 2006 é simples; um assistente de instalação padrão somente requer a aceitação do contrato de licença e a confirmação da pastas de instalação. Assim que o produto estiver instalado, um atalho será adicionado ao menu Todos os Programas. Quando você iniciar o SCCP pela primeira vez, a tela de boas-vindas do Microsoft Capacity Planner fornece acesso a três dos quatro componentes do planejador de capacidade, como mostrado na Figura 1.
Figura 1 Iniciando a ferramenta de planejamento da capacidade
Figura 1 Iniciando a ferramenta de planejamento da capacidade (Clique na imagem para diminuir a exibição)
Figura 1 Iniciando a ferramenta de planejamento da capacidade
Figura 1 Iniciando a ferramenta de planejamento da capacidade (Clique na imagem para aumentar a exibição)
O Assistente de modelo fará perguntas sobre o ambiente desejado, a fim de criar um System Architecture Model (SAM). O SAM inclui as localizações detalhadas, usuários, rede, padrões de usuário e hardware.
O Editor de modelos permite o ajuste fino e modificações nos SAMs criados previamente por meio do assistente ou do editor. É com o uso dele que você pode validar modelos, exibir uso simulado e testar outros cenários, como carga adicional em servidores de email ou na presença de usuários remotos.
O planejador de capacidade é fornecido com vários tipos de hardware predefinidos para uso nos SAMs. No entanto, se você precisar distinguir, o Editor de hardware oferece suporte à definição personalizada de configurações de hardware.
Quando um modelo for selecionado, a Simulação do planejador de capacidade permite que vários testes sejam executados em um modelo selecionado, a fim de definir sua viabilidade para a implementação no mundo real.
A melhor forma de verificar os componentes e como eles funcionarão entre si é de fato usar a ferramenta. Ela iniciará o assistente, executará uma simulação e, em seguida, fará um ajuste fino de um modelo de arquitetura adicionando hardware personalizado. Nessa orientação, utilizarei um ambiente Exchange, mas o processo funcionará de forma semelhante para MOM.

Criando um novo modelo
Antes de você executar uma validação ou cenários “e se” em uma infra-estrutura planejada ou até mesmo se você quiser apenas executar cenários sobre a sua atual infra-estrutura implantada, o ambiente deve ser descrito para SCCP. Infelizmente, não é possível apenas verificar a rede na atual versão. Em vez disso, você deve detalhar a sua infra-estrutura em termos de localizações físicas e tipos de conectividade entre eles, localização de servidores, caixas de correio e usuário, bem como detalhes sobre como os usuários utilizarão o ambiente.
Há algumas limitações na ferramenta, as quais são explicadas no guia de usuário em detalhes. Por exemplo, em um modelo Exchange, somente uma única floresta é compatível. Isso significa que domínios nas florestas externas não têm modelo e quaisquer servidores front-end são considerados como tendo um armazenamento de Catálogo Global e Caixa de Correio no mesmo site. Somente 100 sites podem ter modelo dos quais até 10 podem ter sites do hub, um máximo de 300 computadores servidor e somente clientes Outlook® 2003 (Web ou local) são compatíveis. A boa notícia é que o SCCP oferece suporte a 49.999 clientes nos locais central/hub e até 10.000 em locais de filiais. Os recursos do Exchange, como conexões ActiveSync® e Outlook Mobile Access não são compatíveis, nem as opções de conectividade herdada, como POP e IMAP. A utilização causada pelas operações de backup e restauração não são consideradas nem configurações agrupadas; no entanto, o planejador de capacidade tem as opções necessárias para o modelo preciso típico de uso do email diariamente.
Para iniciar a orientação a partir da página de boas-vindas, selecione “Criar um modelo com o Assistente de modelo” e descreva a infra-estrutura a ser modelo. Vou criar uma empresa que tenha três localizações – uma localização central em Dallas e filiais em Houston e Austin – cada uma das quais terá um número de usuários de email local. Cada localização não terá necessariamente seus próprios servidores, de forma que fornecerei as informações sobre o número e tipo de usuários de email; o SCCP calculará em quais localizações os servidores do Exchange local deverão existir e onde os usuários terão acesso em seu servidor Exchange remotamente.
Depois de criar um modelo básico de infra-estrutura corporativa, o assistente solicitará o número de sites da central e das filiais, a conectividade entre os sites e o percentual da largura de banda que pode ser usado para fins de mensagens. O assistente utilizará uma abordagem ampla para a execução; posteriormente, posso realizar o ajuste fino do modelo criado pelo assistente para configurar links individuais com mais granularidade. Nesse exemplo, eu posso confirmar um sites do escritório central e dois das filiais (consulte a Figura 2). Há conexões T1 entre o site das filiais e a central e metade da largura de banda pode ser usada para mensagens. Não preciso configurar a velocidade entre os sites da central pois tenho apenas um.
Figura 2 Configurando a topologia WAN e a largura de banda da conexão
Figura 2 Configurando a topologia WAN e a largura de banda da conexão (Clique na imagem para diminuir a exibição)
Figura 2 Configurando a topologia WAN e a largura de banda da conexão
Figura 2 Configurando a topologia WAN e a largura de banda da conexão (Clique na imagem para aumentar a exibição)
A próxima janela do assistente solicita o número médio de usuários nos locais da filial, o cliente email (Outlook 2003 no modo de cache ou o Outlook Web Access) e o número de usuários no site central. Novamente essa é uma informação de nível superior e pode passar por ajuste fino posteriormente no Editor de modelo. Nesse caso, eu diria que cada filial tem 200 usuários e um escritório central tem 500, todos os quais estarão usando o Outlook no modo de cache.
O assistente possui três níveis de uso de email padrão: Alto, Médio ou Baixo. Cada nível supõe um tamanho médio diferente da caixa de correio, número de mensagens enviadas e recebidas e tamanho médio por mensagem de email. Se nenhum dos tipos internos corresponder aos padrões de uso esperados na sua empresa, os valores individuais podem ser configurados para cada uma das quatro características separadas de uso.
A próxima etapa é configurar as preferências de hardware, como mostrado na Figura 3. O SCCP permite que sejam especificadas até três possíveis configurações de CPU e essas serão utilizadas para modelo de hardware para várias funções de servidor. As configurações de CPU abrangem desde um único processador 1 GHz Pentium III Xeon até quatro processadores 3.66 GHz Xeon MP. O Exchange 2003 consiste em várias funções, a saber Armazenamento da Caixa de Correio, Bridgehead e Front End, além de uma função adicional de Catálogo Global do Active Directory®. Se a utilização permitir, a opção estará disponível para consolidar funções em alguns servidores. Se a consolidação não for especificada, então servidores separados serão configurados para cada uma das funções até mesmo se a utilização não exigir. Permitir que o SCCP consolide fornecerá os melhores resultados.
Figura 3 Configurando perfis de hardware para servidores
Figura 3 Configurando perfis de hardware para servidores (Clique na imagem para diminuir a exibição)
Figura 3 Configurando perfis de hardware para servidores
Figura 3 Configurando perfis de hardware para servidores (Clique na imagem para aumentar a exibição)
Finalmente, o tipo de discos disponíveis pode ser selecionado com base na interface, no tamanho e na velocidade. O número de discos não é necessário; o planejador de capacidade calculará isso para mim. O planejador também pode especificar a Storage Area Network (SAN), embora a capacidade de criar clusters não esteja atualmente disponível.
A próxima etapa no assistente é um resumo do modelo calculado, o que mostra o número de servidores que o SCCP calcula como ideal, as funções de cada um dos servidores, bem como detalhes, como configurações de processador, memória e disco. Se uma SAN tiver sido selecionada, ela também será exibida.
Lembre-se de que apenas pelo fato de eu ter selecionado vários locais, é possível que os servidores sejam exibidos somente como um subconjunto das localizações. Isso ocorre devido ao fato de o SCCP ter definido que os servidores Exchange locais em determinadas localizações não são ideais e, que em vez disso, as caixas de correio armazenadas são mais bem atendidas por meio de um servidor da caixa de correio Exchange remoto, que é o caso no meu exemplo, mostrado na Figura 4. Nesse caso, os 400 usuários da filial não têm armazenamento da caixa de correio Exchange local, mas em vez disso foram consolidados em um único servidor de armazenamento da caixa de correio Exchange na localização de Dallas, que agora tem 500 usuários.
Figura 4 Um resumo da avaliação de planejamento da capacidade inicial
Figura 4 Um resumo da avaliação de planejamento da capacidade inicial (Clique na imagem para diminuir a exibição)
Figura 4 Um resumo da avaliação de planejamento da capacidade inicial
Figura 4 Um resumo da avaliação de planejamento da capacidade inicial (Clique na imagem para aumentar a exibição)
Nesse ponto no assistente, eu posso clicar nos botões Voltar e Avançar para modificar as respostas e executar um ajuste fino do resumo do modelo (ou clicar diretamente nas páginas do assistente por meio do painel esquerdo de navegação). Quando estiver satisfeito com a configuração, clico no botão Concluir na página Resumo do modelo. Isso abrirá o modelo no Editor de modelo, que é onde é possível uma configuração mais granular.

Ajuste fino de modelo
O Assistente de modelo é uma excelente ferramenta para criação de um modelo de base. No entanto, a menos que vários locais sejam os mesmos e com a mesma média, é provável que certa personalização será necessária para o modelo a ser verdadeiramente útil como uma base para a utilização de cálculo. Não é raro que as localizações tenham diferentes números de usuários ou talvez uma combinação dos vários clientes de mensagens, como Outlook 2003 em cache e parte do Outlook Web Access (OWA). Enquanto não for possível obter esse nível de detalhe no Assistente de modelo, isso pode ser configurado por meio do Editor de modelo. Essa ferramenta também é útil ao tentar definir o efeito da modificação de aspectos do ambiente, por exemplo, acrescentando localizações extras ou tipos de usuários.
O Editor de modelo, mostrado na Figura 5, salva e recupera modelos nos arquivos .sam, que são um formato proprietário para a ferramenta. É uma boa prática, como com todo trabalho, salvar modelos em arquivos antes de realizar as principais alterações, bem como usar um nome descritivo para garantir que o modelos em uso não sejam perdidos. O menu Arquivo fornece um menu Exportar, o qual gera um relatório de resumo detalhado no formato Excel® e como um diagrama de topologia Visio® do modelo.
Figura 5 Ajustando uma configuração SAM no Editor de modelo
Figura 5 Ajustando uma configuração SAM no Editor de modelo (Clique na imagem para diminuir a exibição)
Figura 5 Ajustando uma configuração SAM no Editor de modelo
Figura 5 Ajustando uma configuração SAM no Editor de modelo (Clique na imagem para aumentar a exibição)
No painel esquerdo do Editor de modelo está uma área de navegação básica com opções para visualizar a topologia global, topologia de site ou um resumo de modelo. A Topologia Global mostra o modelo de arquitetura a partir de uma perspectiva de site com redes adicionais, como a Internet. A Topologia de Site exibe as informações sobre um site ou rede selecionada. O Resumo de Modelo exibe um resumo textual do ambiente, o qual é o mesmo formato que você verá exibido no término do Assistente de modelo.
Qualquer que seja a opção selecionada, os detalhes serão exibidos no painel central do Editor de modelo. O painel direito – no espírito da nova versão do Microsoft Management Console (MMC) fornecido com o Windows Server 2003 R2 – é uma área de “ações” dividida em duas subáreas: a parte superior fornece ações relativas ao contexto que são alteradas dependendo da visualização atual ou objeto selecionado, enquanto a parte inferior contém ações gerais que sempre se aplicam. Essas últimas ações permitem que eu adicione um novo site, edite perfis de uso de usuários e (um pouco divertido) execute uma simulação.
Ao trabalhar no painel central do Editor de modelo, todos os itens são selecionáveis. Depois de selecionar um item, além das ações de item atuais sendo alteradas com base no objeto selecionado, eu posso obter mais detalhes sobre ele. Por exemplo, clicar duas vezes em um site alternará para a exibição de Topologia de Site e fornecerá detalhes dos objetos desenvolvidos para aquele site. Dessa forma, um site atendido localmente mostraria um ou mais servidores, redes e usuários no local. Isso por sua vez torna possível clicar duas vezes no objeto selecionado para visualizar suas propriedades detalhadas e modificá-las como necessário.
As linhas que conectam os sites representam as redes entre as localizações e podem ser editadas para permitir a configuração exata da rede. Por exemplo, posso especificar diferentes velocidades de largura de banda para uplink e downlink, e a porcentagem da largura de banda disponível. Também posso configurar latência de conexão, a qual pode ser um importante atributo para a comunicação estável. Outras alterações comuns incluem acrescentar tipos de usuários adicionais. Nesse caso, digamos que você tenha uma combinação de clientes Outlook Web Access e Outlook 2003 atendidos pela localização central. Depois de abrir o Dallas em sua exibição de Topologia de Site, eu selecionaria “Adicionar um perfil de cliente” e acrescentaria informações para usuários baseados em OWA, o que incluiria o servidor que os clientes OWA utilizarão, a rede na qual os usuários se conectarão e a largura de banda que estará disponível para eles, como mostrado na Figura 6.
Figura 6 Adicionando e modificando elementos em um modelo facilmente
Figura 6 Adicionando e modificando elementos em um modelo facilmente (Clique na imagem para diminuir a exibição)
Figura 6 Adicionando e modificando elementos em um modelo facilmente
Figura 6 Adicionando e modificando elementos em um modelo facilmente (Clique na imagem para aumentar a exibição)
Assim que o SAM refletir a infra-estrutura planejada ou existente da forma mais semelhante possível, salve-o e nomeie-o, a fim de garantir que seja de fácil identificação como o ponto inicial para quaisquer modificações futuras. Nesse ponto, gostaria de executar uma simulação para obter uma idéia de como o modelo será executado nas configurações definidas. Com base no resultado, eu posso modificar o modelo para testar vários cenários “e se”, como adicionar um novo site e usuários, adicionar ou remover usuários, adicionar novos usuários a localizações ou alterar o tipo de conexão ou cliente de email. Assim que o modelo for atualizado com esses novos elementos, eu posso executar outra simulação para ver como será o comportamento da nova configuração.

Simulando o uso real
A execução da simulação é tão simples quanto clicar na ação geral de simulação de execução ou no botão da barra de ferramentas. Uma verificação de sanidade do modelo ocorrerá primeiro: quaisquer falhas no modelo serão exibidas antes da simulação ser executada. Por exemplo, se um número de clientes OWA for adicionado a um modelo que anteriormente não tinha clientes OWA e nenhum servidor Front End for configurado, uma mensagem de erro o notificará de que não há um servidor Front End. Se não existirem tais falhas, o status será exibido à medida que a simulação for executada.
Assim que a simulação for concluída, um relatório com informações detalhadas sobre o uso de todos os componentes será gerado e a exibição dos resultados da simulação será aberta. Ele exibirá inicialmente uma visualização de resumo fornecendo detalhes das mais elevadas utilizações de CPU, armazenamento e link de conexão (que são as causas comuns de afunilamento), bem como tempos mais longos de transação e latência, que podem afetar a experiência do usuário final. Os detalhes sobre a utilização exata das conexões de servidores, SAN, local e externas podem ser visualizadas selecionado links no painel esquerdo dos resultados da simulação, como mostrado na Figura 7.
Figura 7 Resumo dos resultados de simulação para um modelo simples
Figura 7 Resumo dos resultados de simulação para um modelo simples (Clique na imagem para diminuir a exibição)
Figura 7 Resumo dos resultados de simulação para um modelo simples
Figura 7 Resumo dos resultados de simulação para um modelo simples (Clique na imagem para aumentar a exibição)
Manter o mouse sobre várias exibições gráficas, como análise de afunilamento, mostra o servidor e o atributo do servidor que está causando esse afunilamento. Observe que as configurações de limiar estão no painel esquerdo. Essa categoria permite que eu defina o que considero uso razoável antes de elevar para avisos, um recurso útil.
Os relatórios detalhados da simulação são excelentes não somente para ajudar a informar as decisões de compra de hardware, mas também para mostrar a quantidade de recursos de rede que serão utilizados pelos aplicativos de mensagens. Por exemplo, para usuários conectando-se por meio de links WAN mais lentos, o relatório fornece uma indicação se o link é ou não rápido o suficiente. Caso não seja, é possível detectar se a velocidade do link entre os locais deve ser atualizada ou se um servidor de armazenamento da caixa de correio local deve ser adicionado, simplesmente modificando o modelo e executando novamente a simulação para obter resultados que atendam a critérios específicos. Da mesma forma, se os servidores estiverem todos executando com 5% da utilização da CPU, eu posso ignorar a especificação dos servidores. Ao permitir a fácil modificação de modelo e o recurso de nova execução das simulações, estou na verdade experimentando diferentes opções de solução. Com métrica precisa de todos os cenários de testes, posso orientar as reuniões de orçamento e planejamento com segurança.

Resumo
Apenas apresentei uma visão geral de como o SCCP permite que você simule e analise a implantação do Exchange. Lembre-se de que o SCCP é executado no mesmo nível de modelo e simulação do MOM. O SCCP pode ser baixado atualmente como parte dos downloads do MSDN® Premium ou TechNet Plus. ¦

John Savill é Diretor de infra-estrutura técnica da Geniant. Ele é um profissional certificado de segurança de sistemas de informação (CISSP), engenheiro de sistemas certificado pela Microsoft (MCSE) em Security and Messaging no Windows Server 2003, MVP por oito anos e instrutor de Krav-Magá. Ele também é autor do livro Windows Server 2003 Active Directory Design and Implementation da Packt Publishing.


 Gerenciamento: Invent&#225;rios avan&#231;ados de cliente com o SMS
Gerenciamento Wes Dobry

Inventários avançados de cliente com o SMS
Visão geral:
  • Usando o agente de inventário de hardware do SMS 2003
  • Ampliando o inventário com arquivos MIF
  • Arquivos MOF dinâmicos vs. estáticos
Faça download do código deste artigo: DobrySMSInventory2007_04.exe (152KB)

Sempre há um momento na vida do administrador quando o chefe pede uma informação que não pode ser obtida sem muito trabalho árduo. Agora imagine um administrador proativo
que já tenha obtido esses dados. Você pode fornecer as informações para o seu chefe instantaneamente, evitando assim perda de tempo desnecessária, horas extras e possivelmente até mesmo ajudando a economizar o dinheiro da empresa. Você poderia ser um herói.
O Microsoft® Systems Management Server (SMS) 2003 coleta prontamente várias informações. Mas ele não coleta tudo. Por exemplo, o SMS 2003 não se reporta por padrão a grupos locais e seus membros ou usuários locais e seus atributos. Não ter essa informação pode ser um problema se, digamos, um técnico estiver inserido Usuários de domínio, ou ainda pior, Todos no grupo de administradores locais em cada sistema que trabalham. Ou, digamos que uma empresa não tenha como saber quais listas de exclusão de pasta e arquivo local estão na sua solução de antivírus/anti-spyware corporativa. Isso pode não ser visto como um problema importante – até que alguém em TI perceba que os usuários estão inserindo c:\*.* na lista de exclusão.
Com a combinação apropriada de script, Instrumentação de Gerenciamento do Windows® (WMI, Windows Management Instrumentation) e conhecimento de SMS, você pode expandir inventários para conter praticamente qualquer parte da informação. Isso é possível através do uso dos arquivos MIF (Management Information Format, formato de informação de gerenciamento) e MOF (Management Object Format, formato de objeto de gerenciamento).

Usando o inventário
Com o SMS, as empresas podem executar implantações personalizadas, monitorar os alvos e manter os sistemas implantados. Ao ampliar os inventários de SMS, você pode criar e gerenciar um destino muito mais personalizado. Por exemplo, você pode reforçar as políticas de segurança corporativa local ao implantar as suas diretivas de segurança em sistemas que já tenham tido as diretivas modificadas por um usuário. Você também pode desabilitar as contas de usuários locais não aprovadas e remover administradores locais irrelevantes.
É claro que as empresas também dependem do SMS para obter informações oportunas e detalhadas sobre sistemas cliente. A ampliação de inventários permite que você crie relatórios que contêm informações totalmente personalizadas, as quais não estão disponíveis ao depender exclusivamente dos inventários padrão. Além disso, as informações podem ser muito granulares. Por exemplo, você pode querer criar um relatório que contenha a contagem dos sistemas que tenham uma chave de Registro específico, a qual aponte para um determinado farm de servidor. Isso permitiria que os administradores avaliassem aproximadamente quantos clientes são apontados para cada farm em determinado momento. Da mesma forma, a equipe de segurança pode verificar para ver quais sistemas na rede estão executando um processo específico conhecido como spyware.
O valor dos arquivos MIF e MOF está relacionado à capacidade de inserir informações de praticamente qualquer origem com um pouco de conversão. Desde que a informação seja baseada em texto, ela pode ser manipulada e inserida na WMI com um arquivo MOF, ou coletada na forma de um arquivo MIF e enviada no próximo ciclo de inventário de hardware. A implementação de uma expansão de inventário requer conhecimento de VBScript ou JScript®, bem como conhecimento sobre o que será coletado. Considerando que praticamente qualquer informação pode ser coletada, esse conhecimento necessário pode variar de WMI para conhecimento avançado em SQL. É claro que o conhecimento de SQL é fundamental, não importando que tipo de informação você esteja obtendo, pois você precisará desse conhecimento para relatar os dados coletados.

Como funcionam os inventários
O SMS contém dois tipos de processos de inventário: hardware e software. Os inventários de software possuem somente informações sobre arquivos, como onde eles estão localizados, quais versões eles possuem, o tamanho e outros atributos do arquivo. No entanto, o processo de inventário do software também permite que você colete arquivos e os armazene no servidor de site.
A expansão do inventário de hardware é facilmente concluída, pois os inventários de hardware contêm a maior matriz de informações sobre um sistema. As informações nos inventários de hardware são derivadas predominantemente da WMI, do Registro e do BIOS do sistema.
Os inventários de hardware são coletados em um cronograma, o qual é definido nas configurações do site do Hardware Inventory Agent no SMS 2003. As coleções podem ser definidas para que ocorram, com freqüência, a cada minuto e, sem tanta freqüência, como em intervalos de vários meses. Geralmente, você deseja ter um equilíbrio ao coletar as informações na taxa mais rápida necessária pelo gerenciamento, mas sem carregar a rede, os servidores de site, os pontos de gerenciamento ou clientes.
Quando o Hardware Inventory Agent for instalado pela primeira vez, ele compilará o arquivo sms_def.mof. Esse arquivo contém todas as informações que o SMS coleta inicialmente. Quando esse arquivo for compilado, todos os espaços para nome do SMS e classes associadas necessários para o Hardware Inventory Agent serão criados na WMI. A maioria está localizada no espaço para nome \\.\root\CIMv2\SMS. Depois da instalação, o Hardware Inventory Agent verifica a maioria dessas classes para criar as informações que são então enviadas ao ponto de gerenciamento e, eventualmente, ao banco de dados do site.

Arquivos MIF
Além de receber informações dessas classes de WMI, o Hardware Inventory Agent procura por arquivos MIF nas pastas de coleção NOIDMIF e IDMIF. Qualquer arquivo MIF que o agente detectar nesses locais será processado no inventário de hardware seguinte.
Os arquivos MIF proporcionam a forma mais fácil de ampliar o Inventário de Hardware do SMS. Há dois tipos de arquivos MIF – NOIDMIF e IDMIF. Esses arquivos são XML estáticos que podem conter praticamente qualquer informação que um usuário quiser inserir no banco de dados do SMS. Eles podem ser criados por qualquer meio utilizado para criar arquivos de texto comuns. Portanto, esses arquivos podem ser criados pela maioria dos idiomas de script ou manualmente.
Geralmente, os arquivos MIF são utilizados em situações em que a informação não está contida no Registro ou na WMI, ou quando a informação precisa ser inserida manualmente. Esses arquivos podem ser criados, por exemplo, quando a sua equipe de implantação de hardware fornecer um novo sistema. O técnico de implantação pode navegar em um aplicativo HTML no sistema e inserir todas as informações de ativos a serem utilizadas para atualizar um banco de dados de gerenciamento de ativos. Esse aplicativo cria dinamicamente um arquivo NOIDMIF e permite que o técnico baixe o arquivo para a pasta de coleção de arquivos NOIDMIF. Esse arquivo NOIDMIF pode conter todas as informações inseridas pelo técnico e ser incorporado no banco de dados do SMS.
Os arquivos NOIDMIF e IDMIF têm apenas algumas diferenças. Um arquivo IDMIF contém um cabeçalho exclusivo que fornece as informações de arquitetura e uma identificação exclusiva. Os arquivos IDMIF podem ser utilizados para incorporar dispositivos que não sejam do sistema no SMS como suas próprias entidades. Por exemplo, um script pode ser usado para criar sistemas no SMS que sejam na verdade impressoras e gravar informações sobre elas no banco de dados do SMS.
Os arquivos NOIDMIF e IDMIF são armazenados em locais padrão, os quais são escolhidos pelas chaves do Registro. Na maior parte do tempo, ele são %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF e ...\IDMIF, supondo-se que o agente SMS estava instalado no local padrão. Se o agente estiver instalado em um local personalizado, os diretórios MIF devem estar em %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF e ...\IDMIF. Mas se houver dúvida quanto aos locais desses diretórios, você pode encontrar os locais relacionados nas seguintes chaves do Registro:
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
Os arquivos MIF sempre têm o mesmo formato, independentemente das informações coletadas. Observando o arquivo MIF mostrado na Figura 1, você verá que o arquivo consiste em um único componente que contém vários grupos e um único atributo em cada grupo. Todas as seções são necessárias, embora você não precise ter mais de um grupo ou entrada de atributo. Você pode analisar isso como se cada grupo no arquivo MIF fosse uma linha de dados da seção nomeada no inventário de hardware e cada atributo no grupo fosse uma coluna dessa linha.
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
O LocalAdmin.vbs de exemplo, que é mostrado na Figura 2, é um VBScript bem simples. Ele verifica o diretório NOIDMIF, exclui o arquivo MIF temporário, se houver, cria o arquivo MIF temporário, grava as informações coletadas por meio de uma simples consulta WMI recursivamente no arquivo, exclui o arquivo MIF que existe na pasta de coleção NOIDMIF e, em seguida, finalmente move o NOIDMIF temporário para a pasta de coleção NOIDMIF.
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
Enquanto os arquivos MIF proporcionam uma forma fácil de ampliar o Inventário de Hardware do SMS, há algumas questões a serem consideradas ao usá-los. Os MIFs são processados em cada ciclo de inventário de hardware. Mas como esses arquivos são criados, coletados, analisados e finalmente colocados no inventário, a exibição das informações contidas em um MIF pode ser adiada no inventário em até um ciclo de inventário de hardware. Isso significa que se uma empresa tiver ciclos de inventário de hardware de um dia, os dados no banco de dados do site podem estar com dois dias de atraso. Portanto, você deve considerar com atenção quando os programas que criam arquivos MIF são publicados e quando o ciclo de inventário de hardware é executado.
Digamos que uma empresa chamada Contoso tenha ciclos de inventário de um dia, os quais são executados à meia-noite. À 1h de segunda-feira, o VBScript será executado, criando um arquivo NOIDMIF que contém a saída de uma verificação do rootkit. Essa saída é coletada à meia-noite e relatada ao ponto de gerenciamento. O administrador do SMS da Contoso verificará a informação no noite da quarta-feira, em torno de 22h e detectará que a informação está com 45 horas de atraso. Isso ocorre devido ao fato de o administrador do SMS não refletiu bastante sobre as alternativas na publicação do programa utilizado para criar o arquivo NOIDMIF.

Arquivos MOF
simplesmente são mais complicados do que os MIF. Além disso, têm vantagem sobre os MIFs devido ao fato de inserirem suas informações diretamente na WMI e se tornarem parte do processo de coleta de dados padrão do agente de inventário de hardware. Dessa forma, você não precisa publicar um VBscript várias vezes para obter informações, poupando o seu tempo e incomodação. Em vez disso, você pode publicar o MOF uma vez por computador e estará compilado.
Os arquivos MOF também têm a vantagem de as informações serem as mais atuais em relação ao restante das informações no inventário de hardware. Sempre que o Hardware Inventory Agent passar pelo ciclo, as classes e provedores detalhados no arquivo MOF são consultados e as informações retornadas rapidamente. Quando você precisar de informações rapidamente, você pode executar um pacote que contenha o seu arquivo MOF e VBScript, começando um inventário de hardware. As informações necessárias serão então obtidas em um ciclo de diretiva do programa publicado.
Há três classificações de arquivos MOF: os arquivos MOF de um espaço para nome e classe WMI existente, arquivos MOF para uma classe adicional com um provedor WMI existente e arquivos MOF para uma classe adicional que não tem um provedor WMI.
Os arquivos MOF contêm duas partes. A primeira parte é a seção de definição do espaço para nome. É aí que as informações do provedor WMI são identificadas. A segunda seção contém os atributos de relatório do SMS. Essa seção informa o Hardware Inventory Agent onde procurar e processar as informações contidas nas classes WMI mencionadas. Como os arquivos MOF lidam diretamente com WMI, recomendo que você reserve um tempo e verifique o Microsoft WMI Software Development Kit (SDK) se pretende trabalhar com esses arquivos (consulte go.microsoft.com/fwlink/?LinkID=83121 para obter mais informações).
Cada uma das classificações mencionadas anteriormente dos arquivos MOF pode ser estática ou dinâmica. Por exemplo, você teria um arquivo MOF estático se o procedimento de criação da empresa tiver compilado um arquivo MOF que contenha informações relativas a quem criou o sistema, que tipo de servidores foram usados, quais as versões iniciais, a data em que a máquina foi desenvolvida e assim por diante. As informações nunca precisam ser atualizadas e, portanto, elas podem ser inseridas diretamente no arquivo MOF e compiladas na WMI usando o mofcomp.exe. Depois que isso ocorrer, a área na qual o Hardware Inventory Agent está verificando precisará ser ampliada adicionando as informações de grupo e classe ao arquivo sms_def.mof no servidor de site.
Um arquivo MOF dinâmico é semelhante ao arquivo MOF estático, exceto que em vez de gravar informações coletadas diretamente na WMI, os dados são coletados por meio de um provedor de WMI. Um provedor de WMI é um plug-in que permite que um aplicativo ou serviço insira informações diretamente na WMI. Esse provedor permite acesso dinâmico a outras áreas da WMI e do sistema, como o Registro, locais de arquivo e informações do Windows Installer.
Em termos de trabalho com arquivos MOF, a forma mais fácil de aprimorar o inventário de hardware é ter mais informações no catálogo de inventário que já existem na WMI. Isso pode ser feito ampliando o sms_def.mof ou ativando classes de relatório adicionais que atualmente estão desabilitadas. O arquivo sms_def.mof está localizado na pasta \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv. Todos os dispositivos na empresa utilizarão o novo sms_def.mof no seu próximo ciclo de diretiva da máquina e começaram coletando e relatando as informações.
O próximo na linha, em termos de dificuldade, está usando um provedor de WMI existente, mas criando uma nova classe. Um exemplo dessa abordagem é mostrado na Figura 3. Nesse exemplo, ao usar o provedor do Registro interno, a classe CU_Desktop é criada com uma propriedade dinâmica consultando HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper no dispositivo local. Depois que o arquivo MOF for compilado no cliente, as informações contidas no SMS_Def_Extension.mof (consulte a Figura 4) precisarão ser acrescentadas ao sms_def.mof. O arquivo contém informações independentemente de o SMS efetuar relatórios sobre elas, nome do grupo, ID de classe, que classe o Hardware Inventory Agent deve verificar na WMI para obter as informações a serem relatadas e, finalmente, os valores reais.
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
Os arquivos MOF também têm a capacidade de acessar informações oferecidas pelos provedores de WMI que não estão incluídas nos sistemas por padrão. Para usar esses provedores, o provedor de WMI deve primeiro ser distribuído e instalado antes de o arquivo MOF ser compilado no cliente e o sms_def.mof.

Resumindo
Os arquivos MIF e MOF files são potentes ferramentas para coleta de informações rápidas e substanciais. Esses formatos de arquivo fornecem a estrutura para introduzir facilmente as informações no banco de dados do SMS sem modificar diretamente as tabelas. Com imaginação suficiente, praticamente tudo pode passar por inventário e relatório. Ainda melhor, as situações problemáticas podem ser evitadas à medida que os administradores agirem proativamente para obter informações vitais.
Compreenda que os arquivos MIF e MOF exigem certo tempo. No entanto, eles são recursos úteis disponíveis, os quais podem ajudá-lo a aprender como usar esses arquivos. Para os iniciantes, verifique Documentação e SDK da WMI, bem como o Guia de operações do Systems Management Server 2003. Se você se esforçar para compreender esses conceitos, o que você obtiver do inventário SMS ampliado ultrapassará em muito o que você inserir nele.

Wes Dobry está localizado em Orlando, Flórida, onde trabalha como consultor e Administrador de rede para uma empresa de grande porte na área de saúde. Você pode contatá-lo pelo email wesdobry@wesdobry.com.


 Gerenciamento: Implantando atualiza&#231;&#245;es personalizadas de software com o SMS 2003 R2
Gerenciamento Steve Rachui

Implantando atualizações personalizadas de software com o SMS 2003 R2
Visão geral:
  • Novos recursos de gerenciamento de atualização no SMS 2003 R2
  • A Ferramenta de Edição de Atualizações Personalizadas
  • A Ferramenta de Estoque de Atualizações Personalizadas

Quando precisar implantar atualizações personalizadas em seus sistemas, como aplicativos de linhas de negócios ou hardwares especializados, você não terá a vantagem de um processo gerenciado e automatizado como teria com as atualizações do Windows. Pelo menos, você nunca teve. Agora, graças ao Systems Management
Server (SMS) 2003 R2, você pode utilizar esses mesmos recursos gerenciados de atualização para implantar suas próprias atualizações personalizadas. O SMS 2003 R2 oferece vários recursos novos, inclusive uma atualização para o Device Management Feature Pack, links para o Operating System Deployment (OSD) Feature Pack e muitos recursos que aprimoram o monitoramento da segurança. O produto possui uma ferramenta de varredura para Avaliação de Vulnerabilidade, que é fundamental para compreender as vulnerabilidades potenciais existentes no sistema e na rede, como, por exemplo, pontos fracos na configuração do SO, nas senhas de usuários e nas configurações do IIS e SQL Server™. Ele também inclui uma ITCU (Inventory Tool for Custom Updates, Ferramenta de Estoque de Atualizações Personalizadas) e uma CUPT (Custom Updates Publishing Tool, Ferramenta de Edição de Atualizações Personalizadas). Neste artigo, abordarei essas duas ferramentas para ajudá-lo a implantar as suas próprias atualizações personalizadas com facilidade e eficiência.

A Ferramenta de Edição de Atualizações Personalizadas (CUPT, Custom Updates Publishing Tool)
Antes de instalar e usar o SMS 2003 R2, a hierarquia, inclusive clientes, deve ser atualizada para o SMS 2003 Service Pack 2 (SP2). Para usar a CUPT, você precisa atualizar para o Microsoft® Management Console (MMC) 3.0. Não é necessário instalar a CUPT no servidor de site do SMS, mas ela deve ser instalada, pelo menos, no Windows® XP, e requer o SQL Server 2005 para hospedagem do seu banco de dados; se o SQL Server 2005 não estiver disponível, deve ser instalado o SQL Server Express Edition. A CUPT é fundamental para introduzir e gerenciar atualizações personalizadas no sistema SMS; além disso, ela possui recursos para testar catálogos criados antes da sua publicação no SMS.
As atualizações personalizadas são apresentadas em duas formas: atualizações que são oferecidas por fabricantes terceirizados para softwares produzidos por eles; e atualizações criadas internamente que são específicas de um determinado ambiente. A CUPT é a ferramenta utilizada para gerenciar ambos os tipos. É mais fácil utilizar as atualizações personalizadas oferecidas por terceiros; portanto, vamos iniciar desse ponto. No momento em que escrevi este artigo, três empresas estavam produzindo catálogos de atualização que podem ser utilizados para a verificação e distribuição de patches apropriados no SMS: Adobe, 1e e Citrix. As empresas participantes podem ser visualizadas selecionando-se os catálogos de parceiro de atualizações personalizadas, como mostrado na Figura 1.
Figura 1 CUPT em ação
Figura 1 CUPT em ação (Clique na imagem para diminuir a exibição)
Figura 1 CUPT em ação
Figura 1 CUPT em ação (Clique na imagem para aumentar a exibição)
Usar as atualizações fornecidas por parceiros nada mais é do que baixar os catálogos e adicioná-los ao SMS. Primeiramente, baixe as atualizações necessárias; em seguida, escolha a opção no menu Ação para importar as atualizações. Um assistente solicitará a localização dos arquivos .cab recém-baixados. Quando o assistente tiver sido concluído, as novas atualizações estarão visíveis na CUPT para configuração adicional e publicação no servidor de site do SMS. Lembre-se, porém, de que cada atualização deve ser sinalizada para publicação. Se uma atualização não for sinalizada, ela não será incluída quando a solicitação para publicação for realizada. Esse procedimento pode ser realizado em massa, como mostrado na Figura 2. Observe que a coluna na extrema direita deve ter a sinalização habilitada para que a atualização seja publicada.
Figura 2 Configurando o sinalizador de publicação
Figura 2 Configurando o sinalizador de publicação (Clique na imagem para diminuir a exibição)
Figura 2 Configurando o sinalizador de publicação
Figura 2 Configurando o sinalizador de publicação (Clique na imagem para aumentar a exibição)
Se necessário, é possível personalizar mais detalhadamente cada atualização obtida por download. Para fazer isso, basta selecioná-la e escolher Editar. No entanto, tenha cuidado ao personalizá-la, pois uma configuração inadequada pode causar resultados inesperados e insatisfatórios.
Depois de sinalizar as atualizações, é necessário publicá-las. É possível fazer isso de duas formas: publicando a atualização em um arquivo .cab externo para uso posterior; ou sincronizando as atualizações selecionadas com o banco de dados do site do SMS para uso imediato. Para efetuar a sincronização com o banco de dados do site do SMS, é necessário fornecer as informações de configuração, como o nome do Servidor do Site e o caminho de origem do pacote (consulte a Figura 3).
Figura 3 Informações de sincronização
Figura 3 Informações de sincronização (Clique na imagem para diminuir a exibição)
Figura 3 Informações de sincronização
Figura 3 Informações de sincronização (Clique na imagem para aumentar a exibição)
É possível localizar esta tela selecionando o nó Atualizações Personalizadas e, em seguida, escolhendo Configurações no menu Ação. Depois de fornecer um nome de servidor de site acessível e o caminho apontando para o diretório de origem para a Ferramenta de Estoque de Atualizações Personalizadas, o código e o status do site serão atualizados.
Com as opções de sincronização definidas, a CUPT agora está pronta para efetuar a sincronização com o Servidor de Site do SMS. Para executar a sincronização, selecione a opção de publicar atualizações no menu Ação. Isso iniciará o assistente de publicação. Para publicar as atualizações no banco de dados do SMS para uso imediato, certifique-se de que a opção para sincronização com o Banco de Dados de Site do Systems Management Server esteja selecionada. Felizmente, essa etapa é fornecida com alguma assistência visual: se as configurações de sincronização ainda não tiverem sido definidas, essa opção estará esmaecida.
Depois da conclusão do assistente, as atualizações personalizadas estarão disponíveis para ação no console de administração do SMS. A inicialização do Distribute Software Updates Wizard oferece uma opção para trabalhar com qualquer atualização personalizada disponível.
Agora que você já sabe como é o processo para utilização das atualizações produzidas pelos fornecedores para produtos terceirizados, que tal saber mais sobre as atualizações personalizadas para software oferecido por fornecedor quando não houver mais atualizações pré-empacotadas disponíveis? É aí que você perceberá o real valor da CUPT. Com a CUPT, é possível criar atualizações personalizadas completas com critérios-alvo detalhados abrangendo praticamente qualquer situação.
Não é difícil criar uma atualização personalizada, mas requer que o administrador compreenda como aplicar o patch do software, quais critérios utilizar para determinar se um patch é aplicável e quais regras-alvo devem ser utilizadas para focalizar a atualização. As regras-alvo são definidas separadamente do processo de criação da atualização. Elas podem ser visualizadas selecionando-se a opção Gerenciar Regras no menu Ação.
A criação de uma atualização personalizada é iniciada selecionando-se o item Criar Atualização, no menu Ação, o que iniciará um assistente para o qual você fornecerá os detalhes da atualização personalizada. Este artigo não abordará os detalhes de como criar uma atualização personalizada, mas ele o instruirá sobre como selecionar as propriedades em uma das atualizações personalizadas de terceiros importada, a fim de que você compreenda o que é necessário em cada campo ao criar a sua própria atualização. As propriedades de uma atualização de terceiros configurada são mostradas na Figura 4.
Figura 4 Propriedades de uma atualização de terceiros
Figura 4 Propriedades de uma atualização de terceiros (Clique na imagem para diminuir a exibição)
Figura 4 Propriedades de uma atualização de terceiros
Figura 4 Propriedades de uma atualização de terceiros (Clique na imagem para aumentar a exibição)
Com o uso do processo de criação de atualizações personalizadas, é possível fazer muito mais do que apenas atualizações; também é possível configurar o software para que seja distribuído aos sistemas cliente. Embora isso funcione, é importante salientar que não é uma abordagem recomendada nem é o uso pretendido da CUPT.

A Ferramenta de Estoque de Atualizações Personalizadas (ITCU, Inventory Tool for Custom Updates)
A ITCU é uma nova ferramenta de estoque que funciona com catálogos de atualização personalizada. Como as ferramentas de verificação anteriores a ela, a ITCU cria coleções, pacotes e anúncios personalizados, os quais são utilizados para implantar as ferramentas de verificação em clientes SMS na empresa. Assim como com as ferramentas de verificação anteriores, a ITCU recuperará o catálogo (nesse caso, o catálogo de atualizações personalizadas), a partir de um ponto de distribuição acessível do SMS, executará a verificação com base nos dados do catálogo, inserirá os resultados dessa verificação no Instrumento de Gerenciamento do Windows (WMI, Windows Management Instrumentation) e relatará os resultados por meio do estoque de hardware. A principal diferença no processo de verificação é o catálogo utilizado.
A introdução do SMS 2003 R2 acrescenta uma poderosa ferramenta ao atual arsenal de segurança do SMS. Antes disso, os administradores nunca tinham conseguido aproveitar a infra-estrutura existente do SMS para aplicar patch em aplicativos terceirizados e personalizados. O SMS R2 é uma inclusão bem-vinda para os administradores de gerenciamento de patch.
Portanto, agora você tem duas ferramentas à sua disposição para gerenciar as atualizações de software a partir de outras fontes que não sejam da Microsoft. A capacidade de gerenciamento e a conveniência que a CUPT e a ITCU oferecem garantirão que as suas atualizações personalizadas ocorram tranqüilamente, da mesma forma que ocorrem com as atualizações do Windows que você já utiliza.
Recurso de gerenciamento de atualizações
  • TechNet: gerenciamento de atualizações
  • Webcast: É agora! SMS 2003 R2
  • Dez princípios do gerenciamento de patches da Microsoft

Steve Rachui é Engenheiro de Suporte de Gerenciamento no grupo de Atendimento Microsoft. Ele tem oferecido suporte ao SMS desde a versão 1.2 e pode ser contatado pelo email steverac@microsoft.com.


 Do editor: Podemos estar errados...
Do editor
Podemos estar errados...

UMA DAS PRINCIPAIS DIFERENÇAS entre a impressão e a Web é que uma vez que algo está impresso, isso é para sempre. Quando você disponibiliza parte de uma informação na Web e precisa atualizá-la posteriormente, basta você acessá-la e alterar o que for necessário. Não há mistério algum.
A impressão, é claro, é diferente. Depois que o material estiver impresso, não há volta. Mais de 100 mil cópias a serem impressas, e independentemente do que tiver sido inserido nas páginas é isso que estará na biblioteca na versão final (ou até a próxima alteração). Além disso, a impressão oferece uma progressão natural mensal, e você sabe que a edição mais atual terá as mais recentes novidades e artigos.
Agora que a revista também é fornecida integralmente online depois de sua publicação, isso apresenta um novo problema. De um ponto de vista de um usuário que faça pesquisas online, todo o conteúdo no nosso site da Web está online ao mesmo tempo. Portanto, como você saberá se está consultando a informação mais recente?
, você verá a divulgação completa de todas as alterações efetuadas nos artigos depois de sua publicação. Destacamos cinco motivos para atualizar uma informação: informação técnica, editorial, informação nova, informação desatualizada e segurança.
Por exemplo, o artigo “Técnicas para simplificar a criação de imagens da área de trabalho”, o qual foi publicado em maio de 2006, mencionava uma ferramenta chamada CNIC que ainda não estava disponível. Quando a CNIC foi disponibilizada, adicionamos uma atualização na página de correções e uma atualização do editor no artigo publicado online. Para acessar as novas informações basta clicar no link de atualização do editor.
Como você pode ver, embora cada edição impressa da TechNet Magazine seja substituída por uma nova a cada mês, a nossa diretiva de correções ajuda a garantir que o artigo se mantenha relevante com o passar do tempo. - JOSHUA TRUPIN

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Luis Botero, Derek Del Conte, John Doyle, David Feldman, Scott Hinsley, Jesper Johansson, Brian Mohr, Michael Murgolo, John Orefice, Mark Russinovich, Matt Steele, Fergus Stewart, Jason Stolarczyk, Jim Truher e Alan von Weltin.


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

Sincronização de arquivos e diretórios
Allway Sync
allwaysync.com

Não importa que tipo de trabalho de TI você tenha, as chances de que você gaste muito tempo movendo arquivos e diretórios de um local para outro – independentemente de uma área de trabalho para uma chave de USB ou de servidor para servidor na rede. Freqüentemente, é importante manter esses diretórios sincronizados, a fim de garantir que você não esteja criando duplicatas desnecessárias e que esteja trabalhando com a versão mais recente dos arquivos. Às vezes, você pode precisar sincronizar arquivos e diretórios em várias máquinas, como quando implantar arquivos XML ou HTML estáticos em um conjunto de servidores da Web. O Allway Sync do Usov Lab é uma ferramenta útil para gerenciar esses tipos de tarefas.
O Allway Sync oferece a você a verdadeira sincronização n-way, a partir da replicação unidirecional de arquivos e diretórios para uma opção bidirecional de vários diretórios. O aplicativo não somente permite que você mantenha unidades locais e recursos em rede na sincronização, mas também oferece suporte à sincronização automática para dispositivos removíveis, como chaves de USB e unidades ópticas regraváveis. Você pode configurar o Allway Sync para que ele inicie automaticamente quando o dispositivo estiver conectado à sua máquina.
Outras opções de início automático para sincronização incluem iniciar quando forem detectadas alterações em arquivos, quando você fizer logon ou logoff, quando o Allway Sync for iniciado ou em intervalos de tempo especificados. Você pode até mesmo vincular a sincronização a uma tarefa agendada por meio da GUI do aplicativo.
Sincronização de arquivos e pastas com o Allway Sync
Sincronização de arquivos e pastas com o Allway Sync (Clique na imagem para diminuir a exibição)
Sincronização de arquivos e pastas com o Allway Sync
Sincronização de arquivos e pastas com o Allway Sync (Clique na imagem para aumentar a exibição)
Todas as modificações e exclusões de arquivos são controladas no banco de dados local do aplicativo; o Allway Sync oferece muitas opções para controle de versão de arquivos modificados e exclusão de arquivos em conflito, inclusive remover os itens definitivamente, movê-los para a lixeira ou movê-los para uma pasta específica.
Para cada trabalho, você pode especificar vários filtros de inclusão ou exclusão, a fim de obter os arquivos necessários e ignorar aqueles que você não precisa. Você pode personalizar as ações que gostaria que o Allway Sync realizasse quando ele detectar avisos ou erros, bem como configurar uma ação diferente para cada tipo de aviso ou erro. Por exemplo, você pode escolher repetir automaticamente uma cópia no caso de erro, bem como configurar não somente o número de repetições automáticas, mas também o retardo entre as repetições, a fim de acomodar qualquer latência de rede ou problemas de conectividade a curto prazo.
Você pode configurar a verbosidade do recurso de registro em log do aplicativo, a fim de garantir o recebimento do máximo de informações sobre os seus trabalhos. As configurações do aplicativo podem ser importadas e exportadas via XML, de forma que seja fácil mantê-las em backup ou transferi-las para outro computador. Além disso, um recurso divertido para os ávidos por novidades, o aplicativo também fornece uma janela de estatísticas fácil de usar (acessível por meio do menu Ajuda). Essa ferramenta útil pode efetuar a sincronização dos seus arquivos em um piscar de olhos e é muito acessível.
Preço: gratuito para uso pessoal. US$ 29,99 para uso comercial.

Mapeamento e monitoramento da sua rede
LANState Pro
10-strike.com/lanstate

O acesso rápido ao status e à disponibilidade dos recursos da sua rede é vital para um ambiente proativo de operações de TI. Quando surgir um problema, você precisará ter conhecimento disso antes de qualquer outra pessoa. A ferramenta útil para mapeamento e monitoramento da rede, LANState Pro, da 10-Strike Software, pode ajudá-lo com recursos de rápida visualização e gerenciamento de LAN para redes baseadas em Windows®.
Quando iniciar o aplicativo para monitorar a sua rede, você pode selecionar o Assistente de mapeamento de rede, o qual permite que você verifique o seu ambiente de rede ou um intervalo de endereço IP para hosts aplicáveis. Se preferir, você pode adicionar os hosts manualmente. Assim que o mapeamento da rede for criado, o LANState começará automaticamente as verificações de status que você configurou, como verificação da porta TCP ou de ping ICMP. Os hosts responsivos são codificadores por cor, enquanto os não responsivos estão esmaecidos. Você pode então organizar o seu mapeamento em agrupamentos lógicos apropriados para a sua configuração, bem como alterar quaisquer elementos visuais, como descrições e afins.
Criação de agrupamentos lógicos de rede com o LANState Pro
Criação de agrupamentos lógicos de rede com o LANState Pro (Clique na imagem para diminuir a exibição)
Criação de agrupamentos lógicos de rede com o LANState Pro
Criação de agrupamentos lógicos de rede com o LANState Pro (Clique na imagem para aumentar a exibição)
As ferramentas de desenho e edição são um pouco complicadas, mas assim que o seu mapeamento for concluído, você pode salvá-lo em um arquivo e não será preciso recriá-lo. Além das verificações da porta TCP e de ping ICMP, você pode configurar o LANState Pro para que ele verifique a existência de uma pasta ou arquivo, o tamanho de um arquivo, ou quanto espaço em disco está livre em um host remoto em um intervalo configurável e tempo limite. Clicar com o botão direito do mouse em um host abrirá um menu de contexto, o qual permite que você obtenha mais informações do sistema do host remoto, bem como execute uma rota de rastreamento, envie um ping, faça uma verificação padrão ou envie uma mensagem pela rede.
A visualização das informações do sistema mostra tudo, desde os endereços MAC NIC e endereços IP vinculados a compartilhamentos de rede, serviços e contas locais. A maioria das informações no nível de sistema operacional requer as permissões apropriadas e portas abertas no sistema remoto, mas você pode obter uma boa quantidade de dados a partir de chamadas de RPC. Além disso, se tiver tais permissões, você também pode enviar sinais remotos de acionamento e desligamento para os hosts remotos.
Preço: US$ 249,95 por licença de usuário.

Script da linha de comando
Crítica do livro
www.syngress.com

Assistentes interativos e GUIs de configuração podem realmente simplificar tarefas complexas. Mas se você for um profissional de TI, essas interfaces podem atrasar as suas tarefas e nem sempre fornecem a granularidade suficiente ou controle da tarefa. Felizmente, esse nível de controle quase sempre está disponível por meio da CLI (Command-Line Interface, interface da linha de comando). Familiarizar-se com as ferramentas incluídas com o Windows e saber como personalizar o prompt de comando para facilitar as tarefas administrativas pode poupar tempo, aumentar a eficiência e fornecer controle mais preciso. A obra How to Cheat at Windows System Administration Using Command Line Scripts, de Pawan K. Bhardwaj (Syngress Publishing, 2006), pode ajudá-lo a dominar a CLI e os utilitários do sistema operacional.
Esse livro fornece orientações sobre a personalização do shell de comando, usando arquivos em lote para a automatização e o processamento de lotes, bem como para a administração da CLI de tarefas agendadas. Assim que você dominar essas seções, o livro introduzirá os utilitários incluídos no sistema operacional do Windows, a fim de ajudá-lo a gerenciar discos, arquivos e diretórios. Você também terá uma interessante visão geral dos comandos dos Serviços de Diretório, como DSQuery e DSMod, os quais, em combinação, com os recursos de processamento em lote apresentados nos capítulos anteriores, pode poupar grande parte do tempo utilizado para administrar grandes estruturas de diretório.
Você também aprenderá mais sobre os comandos de rede do Windows – de Netstat a Pathping –, os quais estão à sua disposição; além disso, você terá uma visão geral das ferramentas de conexão remota, como TFTP, RSH e RCP. Novamente, combinando essas ferramentas com os recursos obtidos na primeira seção do livro sobre automatização e tarefas agendadas, você poderá definitivamente aumentar a sua produtividade. Resumindo, embora não seja uma referência abrangente para os utilitários do Windows, o livro de Bhardwaj é um acréscimo útil aos seus livros de consulta.
Preço: US$ 39,95 direto.

Teste de confiabilidade de hardware
BurnInTest
passmark.com/products/bit.htm

Independentemente de você estar envolvido na produção de PCs personalizados, execução de atualização de componentes de hardware para a sua base de clientes ou apenas na criação de um conjunto de desktop super-admin, é fundamental garantir que os novos componentes serão executados com confiabilidade antes de você fornecê-los aos seus usuários. O BurnInTest, da PassMark Software, faz isso executando vários testes de carga diferentes nos componentes que você especificou, a fim de garantir que eles não falharão antes da entrega.
Como com todos os testes de software de gravação, o aplicativo tenta “exercitar” o hardware, exercendo carga nos componentes de sistema selecionados, em um esforço para simular um longo ciclo de atividade em um curto período de tempo. A idéia é detectar todos os erros subjacentes antes de um sistema ou dispositivo ser colocado em serviço. O BurnInTest permite que você teste tudo, desde as CPUs e memória de placa gráfica a discos rígidos e gravadores de CD.
O aplicativo é muito fácil de usar e configurar, permitindo que você altere os ciclos de tarefas e preferências de cada teste da unidade de componente em determinada configuração. Assim que você tiver definido a sua configuração de teste, você pode salvar as suas preferências para uso posterior, acelerando a próxima interação de teste que você pode precisar executar por alguns meses.
Cada um dos testes apresenta um ciclo de tarefas configurável, de forma que você pode definir um valor de carga de 1 a 100 para cada componente sendo testado. Por exemplo, você pode testar operações matemáticas da CPU em uma carga de 75% e, simultaneamente, testar uma carga de 90% na memória do sistema. Você também pode informar ao BurnInTest para que ele seja interrompido depois de um número definido de minutos ou ciclos operacionais.
O aplicativo permite que você teste até 20 discos rígidos, unidades de disquete e/ou unidades ópticas simultaneamente, de forma que você possa testar em lote as unidades antes de distribuí-las ao ambiente do seu cliente. Isso pode poupar grande parte do seu tempo durante o upgrade de um componente do sistema, pois você pode testar cada novo componente uma só vez sem precisar testar cada sistema individualmente. Considero interessante o fato de o programa fornecer verificação de parâmetro SMART.
A Professional Edition oferece suporte a uma variedade de testes de auto-retorno para portas USB 2.0, paralela e serial. (Os dispositivos de auto-retorno de hardware estão disponíveis para compra na PassMark.) Essa versão do BurnInTest pode ser executada a partir de CD ou unidade de chave USB, o que se soma à credibilidade dos testes sendo executados, reduzindo o impacto do aplicativo no sistema sendo testado.
Preço: US$ 49 Professional Edition; US$ 24 Standard Edition.

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.


 P&amp;R do SQL: Recriando &#237;ndices, comprimento da fila de disco e muito mais
P&R do SQL
Recriando índices, comprimento da fila de disco e muito mais
Editado por Nancy Michell

P Como são recriados os índices do SQL Server? Preciso saber como o DBCC DBREINDEX consome todo o meu espaço em disco e por que ele não é liberado quando o comando falha. O tamanho do meu banco de dados é de 90 GB e a maior tabela é de 70 GB.
Quando executo o DBCC DBREINDEX, deixando 10% de espaço livre, ele consome todo o espaço disponível em disco e o comando falha. Embora inicialmente o arquivo do banco de dados seja de 90 GB, quando o comando do DBCC falha, o arquivo do banco de dados cresce para 160 GB e os 70 GB adicionais nunca são liberados; eu preciso reduzir manualmente o banco de dados várias vezes para recuperá-lo.
Quando o comando funciona, o tamanho do arquivo do banco de dados também é de 160 GB, mas o espaço é automaticamente liberado poucas horas depois da redução automática. Seria aceitável executar uma desfragmentação em vez de DBREINDEX para consumir menos espaço? Não tenho índices agrupados e estou usando o modo de recuperação simples.
R No nível mais simples, os índices são recriados construindo-se uma nova cópia do índice e, em seguida, excluindo a antiga. Isso significa que, essencialmente, há duas cópias do índice por um breve período de tempo. A criação do novo índice exigiria tanto espaço do arquivo de banco de dados quanto o índice original e, se a recriação exigisse uma operação de classificação, um adicional de 20% do tamanho do índice seria necessário para a classificação.
Portanto, o pior caso seria que a recriação de um índice exigiria 1,2 a mais de espaço que o índice antigo. Se o arquivo do banco de dados não tiver espaço livre suficiente, o arquivo precisará crescer para que a operação continue. É possível que, se o crescimento automático não estiver habilitado ou não houver espaço suficiente no volume do disco, não haja espaço livre suficiente disponível e a operação de recriação falhará.
Independentemente de a operação falhar ou não, o espaço adicional alocado para o arquivo do banco de dados não é liberado depois da conclusão da operação de recriação. A suposição é de que o espaço será utilizado para operações regulares de banco de dados.
A execução da redução (manual ou automaticamente) é quase garantida para criar a fragmentação de índice devido ao modo como o algoritmo funciona. Para obter mais detalhes, consulte Mecanismo de armazenamento do SQL Server. A redução automática pode ser especialmente prejudicial se o banco de dados precisar liberar espaço para operações regulares, pois você pode obter um ciclo de crescimento automático-redução automática-crescimento automático-redução automática, o qual pode causar estragos na fragmentação e no desempenho.
O uso de DBCC INDEXDEFRAG (ou ALTER INDEX ... REORGANIZE no SQL Server™ 2005) apresenta a vantagem de praticamente não utilizar espaço adicional de arquivo do banco de dados, mas pode demorar mais e gerar muito mais registro em log da transação do que uma recriação de índice. O DBCC INDEXDEFRAG é sempre registrado em log por completo, independentemente do modo de recuperação em uso, enquanto que no modo de recuperação simples uma recriação de índice será sempre registrado em log em massa. Há uma variedade de prós e contras para cada método e eles são explicados mais detalhadamente no whitepaper sobre práticas recomendados de desfragmentação de índice do SQL Server.
Antes de tomar a decisão de como corrigir a fragmentação, primeiramente decida se deseja realmente corrigi-la. Dependendo do tipo de operações para as quais o índice for utilizado, a fragmentação pode não ter efeito no desempenho e, portanto, corrigi-la será uma perda de recursos. O whitepaper apresenta isso em detalhes.
Resumindo: certifique-se de que você escolha o método mais apropriado de remoção de fragmentação para o seu ambiente e que essa remoção esteja auxiliando no desempenho de consulta.

P Configurei o espelhamento do banco de dados com êxito entre as duas instâncias do SQL Server 2005. Meu aplicativo está conectando-se ao SQL Server usando um login do SQL Server e foi criado usando ADO e cliente nativo SDL. Minhas configurações de conexão e da cadeia de caracteres da conexão especificam as informações corretas, inclusive o parceiro apropriado de failover. Além disso, criei todos os mesmos login no servidor de espelhamento, como eles existem no servidor principal. Mediante o teste de uma falha do banco de dados, o espelhamento supõe com êxito que a função principal e tudo o mais estão corretos na instância do SQL Server. (Eu posso até mesmo me conectar ao espelhamento usando o meu login do Windows®.) No entanto, a reconexão do aplicativo falha com o seguinte erro:
Cannot open database "<db name>" requested by the login. The login failed.
Parece que o login não está associado ao usuário no novo banco de dados principal (originalmente o espelhamento). Executo sp_change_users_login para sincronizar os usuários e logins do banco de dados e obtenha uma mensagem afirmando que corrigi vários usuários órfão. Então, o meu aplicativo se reconecta com êxito ao novo servidor principal. Tentei vários failovers e sempre vejo o mesmo comportamento – a associação entre o login e o usuário é perdida.
Há uma forma de configurar a instalação do espelhamento para que isso não seja um problema?
R Sim. O problema é devido ao fato de que os SIDs (Security Identifiers, identificadores de segurança) do SQL Server que efetuam login em cada servidor não correspondem, mesmo que os nomes de login sejam os mesmos. Isso não é um problema com os logins Windows/usuário do domínio/grupo, pois os SIDs para esses logins são criados com base no SID de domínio para usuário/grupo e, portanto, serão os mesmos para determinado usuário/grupo não importando a qual SQL Server o usuário/grupo foi adicionado.
Para fazer com que a etapa de sincronização sp_change_users_login não seja necessária, você precisará criar os logins do SQL Server no servidor de espelhamento, não somente com o mesmo nome, mas também com o mesmo SID como no servidor principal. Você fará isso usando a especificação de SID na instrução CREATE LOGIN ao criar os logins no servidor de espelhamento, como a seguir:
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
Você pode recuperar o SID para cada login do servidor principal ao consultar a exibição de catálogo sys.sql_logins. Um exemplo de uma consulta que irá gerar uma instrução CREATE LOGIN real para cada login SQL Server/Windows em determinado servidor é mostrada na Figura 1.
Figure 1 Geração da instrução CREATE LOGIN (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

P Qual deve ser o meu comprimento médio da fila do disco? Por exemplo, se eu tenho 20 eixos físicos separados da SAN (Storage Area Network, rede da área de armazenamento) com configuração RAID 01, como faço para calcular o comprimento médio da fila do disco? Seria o comprimento médio da fila do disco/20 ou o comprimento médio da fila do disco/2?
R Primeiramente, você deve verificar a latência de disco antes de perder tempo com o comprimento médio da fila do disco em um ambiente SAN. Mas isso realmente depende do que você está tentando descobrir. Veremos o porquê em um momento.
A explicação desse contador (do Perfmon) é "O comprimento médio da fila do disco é o número médio de solicitações de leitura e gravação que são colocadas em fila para o disco selecionado durante o intervalo de amostra”. Será um disco físico ou contador de disco lógico, de forma que o número obtido dependerá de como o armazenamento subjacente é apresentado ao sistema operacional.
Vejamos o seu caso agora: você tem 20 eixos em uma configuração RAID 01, o que significa que você distribuiu e colocou em espelhamento (ou colocou em espelhamento e distribuiu, dependendo de como você lê 01 ou 10). O ponto essencial sobre a sua matriz de armazenamento é que há 10 eixos no conjunto de distribuição.
Mas está faltando a informação essencial, como qual o tamanho da distribuição, o quão grandes são as suas gravações e que tipo de E/S você está emitindo (leitura, gravação, seqüencial ou aleatória).
Ignore essas informações faltando por enquanto, se o comprimento médio da fila do disco for 10, então o sistema operacional colocará em fila 10 E/Ss para a matriz do disco. Teoricamente, isso poderia ser uma E/S para cada um dos 10 conjuntos espelhados na distribuição ou poderia ser 10 E/Ss todas em um disco. Você não tem como saber isso.
É aí que a informação faltando entraria. Vamos supor que o tamanho da sua distribuição seja de 64 KB, o tamanho da sua gravação seja de 8 KB e você fará um bloco completo de gravações seqüenciais. Esse é um cenário típico de atividade de armazenamento do SQL Server. Nesse caso, há uma boa chance de que oito dos E/Ss sejam encaminhados todos para o primeiro disco e os dois restantes sejam encaminhados para o próximo disco. Portanto, se você estiver tentando imaginar o comprimento da fila do disco por disco para esse cenário, seria 8 para o primeiro disco, 2 para o segundo disco e 0 para os oito discos restantes na matriz.
Agora, vamos mudar o cenário para um tamanho de distribuição teórico de 8 KB e um tamanho de bloco de gravação de 64 KB – e manter o comprimento da fila do disco em 10. Nesse caso, cada bloco de 64 KB é distribuído em 8 discos, de forma que um E/S é gravado em 8 discos e 10 E/Sss em fila são distribuídos em 80 gravações de disco em todos os 10 discos na matriz. Se você estiver tentando calcular o comprimento da fila do disco na matriz, será de 8 para cada disco na matriz.
Sejamos realistas e vamos acrescentar outro nível de incerteza nesse cenário. Na maioria dos casos, o seu armazenamento SAN estará conectado ao servidor usando uma ou mais HBAs no servidor, um número de fibras para conectar a HBA à SAN, um número de portas na extremidade dianteira da SAN e talvez algum tipo de comutador de fibra na malha entre o servidor e a SAN. Então, acessaremos a estrutura interna dos barramentos na SAN e veremos como os discos estão conectados às portas na frente da SAN.
Qualquer fila que você estiver vendo relatada no Perfmon pode ser um sintoma de alta latência ou fila em qualquer um desses pontos entre onde o sistema operacional avalia o comprimento da fila do disco e a superfície dos discos. É por isso que você deve verificar a latência e basear quaisquer decisões nesse contador em vez de no comprimento médio da fila do disco.

P Estou usando a replicação transacional e sei que muitas filas estão sendo alteradas manualmente em uma tabela no assinante, de forma que estou obtendo erros quando o editor está tentando atualizar uma fila que não existe mais no assinante.
Eu preciso saber se há alguma forma por meio da replicação para apenas reinicializar essa tabela do editor, em vez de reaplicar todo o instantâneo novamente. Verifiquei a função tablediff, que parece ser o que eu preciso, mas não sei se ela interage com a replicação.
Por exemplo, a tablediff obtém um instantâneo da tabela do editor e a compara com o equivalente da assinatura? Preciso interromper a replicação para usar o utilitário tablediff para garantir a consistência dos dados? O mais preciso saber?
R Primeiramente, a tablediff não obtém um instantâneo literal da tabela de publicação ou assinatura. Em relação ao seu cenário específico, há algumas opções que você pode analisar.
A primeira seria interromper temporariamente a replicação e executar o utilitário. Se você estiver preocupado com o fato de os usuários tentarem efetuar modificações nos dados, você pode usar os parâmetros -sourcelocked e –destinationlocked, os quais aplicam um bloqueio exclusivo nas tabelas quando o utilitário estiver em execução. Se isso for inaceitável, outra opção seria verificar os parâmetros -rc e -ri enquanto a execução de replicação é mantida. Isso executaria a tablediff uma só vez e, depois, ela seria executada consecutivamente nos erros que detectar, eliminando os erros que poderiam ser decorrentes dos atrasos na propagação da replicação. No entanto, esteja atento, pois com essa opção, dependendo do seu atraso de replicação, você pode não necessariamente obter todas as linhas alteradas pelo assinante.

Meus agradecimentos aos seguintes profissionais de TI da Microsoft por seus conhecimentos técnicos: Sunil Agarwal, Chad Boyd, David Browne, Gilles Comeau, Emmanuel Dreux, Amanda Foote, Matt Hollingsworth, Paul Mestemaker, Uttam Parui, Paul Randal, Dennis Tighe e Steven Wort.


 Destaque de utilit&#225;rio: Autoruns
Destaque de utilitário
Autoruns
Lance Whitney
Faça download do código deste artigo: Autoruns (490KB)

Um computador característico executando o Windows® carrega uma matriz de itens na inicialização, inclusive arquivos, drivers, tarefas e serviços. Em algum momento, é provável que você precise visualizar e talvez desabilitar determinados itens da inicialização – para solucionar um conflito, rastrear malware na seqüência de início automático, para reduzir o tempo de inicialização ou liberar memória e recursos do sistema.
O Utilitário de configuração do sistema (msconfig.exe) permite que você visualize e desabilite vários arquivos e serviços de inicialização, mas há muitos que ele não captura – objetos auxiliares ou barras de ferramentas do navegador e extensões do shell do Windows Explorer. Além disso, o msconfig não compartilha muitos detalhes sobre esses itens. Para saber mais sobre um método melhor para visualizar e gerenciar todos os itens carregados na inicialização, verifique o Autoruns do Sysinternals.
O Autoruns, escrito por Mark Russinovich e Bryce Cogswell, é um utilitário gratuito que detecta todos os itens da inicialização – também conhecido como uma geração de imagens – em um computador baseado no Windows. Você pode visualizar todas as imagens armazenadas nas pastas de inicialização, o Registro e outras áreas que gostaria de ocultar (veja a Figura 1).
Figura 1 Visualizando itens da inicialização com o Autoruns
Figura 1 Visualizando itens da inicialização com o Autoruns (Clique na imagem para diminuir a exibição)
Figura 1 Visualizando itens da inicialização com o Autoruns
Figura 1 Visualizando itens da inicialização com o Autoruns (Clique na imagem para aumentar a exibição)
O Autoruns mostra o nome e a localização de cada imagem. Para arquivos, ele exibe o caminho do diretório; para entradas do Registro, você obtém a chave exata. Além disso, o Autoruns fornece o nome do editor e uma breve descrição, com base nos dados de versão do item. Clicar duas vezes em uma entrada o conduzirá para o diretório ou chave do Registro; clicar com o botão direito do mouse abrirá um menu suspenso com mais opções, inclusive um comando Propriedades, o qual exibirá a janela padrão Propriedades do Arquivo com as informações completas da versão. Uma opção para “Incluir locais vazios” mostra todas as áreas de inicialização de um computador, independentemente de terem entradas ou não no momento. Também é possível selecionar outras contas de usuário no computador para visualizar os seus ambientes de inicialização.
Você pode verificar a assinatura digital de uma entrada por meio do comando Verificar, o qual consulta os sites da Web com CRLs (Certificate Revocation Lists, listas de certificados revogados), a fim de determinar se uma imagem será assinada digitalmente e se a assinatura é válida. Outra opção para “Ocultar entradas assinadas da Microsoft” exclui as entradas já assinadas pela Microsoft, o que permite que você se concentre nas imagens de terceiros.
A lista completa de itens da inicialização pode ser exportada para um arquivo de texto – útil se você quiser desabilitar itens e precisar de um instantâneo do seu ambiente de atualização antes de ajustá-lo. Em seguida, para ver as suas alterações, você pode comparar o arquivo exportado com a sua configuração revisada da inicialização.
Veja a seguir apenas algumas das categorias de inicialização que o Autoruns abrange:
Logon inclui as pastas de inicialização do usuário e todos os usuários, bem como as chaves Executar localizadas no Registro.
Explorer inclui uma lista das extensões do shell, barras de ferramentas e execuções de instalação ativa do Explorer.
Internet Explorer inclui os objetos auxiliares do navegador, bem como as barras de ferramentas e as extensões do Internet Explorer®.
Provedores de LSA inclui a autenticação, notificação e pacotes de segurança de autoridade de segurança local.
No Autoruns, é possível excluir definitivamente um item de inicialização ou apenas desabilitá-lo. Uma opção de Pesquisa Online ajuda você a detectar quais itens é possível desabilitar com segurança. Essa opção executa uma pesquisa na Internet por páginas da Web que descrevem um item ou sua categoria e, em seguida, o aconselha se ele deve ser removido ou não da inicialização. Ao desabilitar um item, o Autoruns o move para um local de backup no Registro ou no disco rígido.
O Autoruns funciona bem em todas as versões do Windows, inclusive na edição de 64 bits do Windows XP e do Windows Server® 2003. Obtenha uma cópia em microsoft.com/technet/technetmag/code06.aspx.

Lance Whitney é consultor de TI, instrutor e redator técnico. Ele já passou horas incontáveis ajustando estações de trabalho e servidores Windows. No início da carreira, era jornalista e deu um tiro no escuro no mundo TI há aproximadamente 15 anos.


 The Cable Guy: Configura&#231;&#245;es da Diretiva de Grupo sem fio para Windows Vista
The Cable Guy
Configurações da Diretiva de Grupo sem fio para Windows Vista
Joseph Davies
Esta coluna inclui informações de pré-lançamento sobre o Windows Server "Longhorn" que estão sujeitas a alterações.

Como um administrador, provavelmente o seu trabalho seja um pouco mais fácil se você puder configurar e distribuir centralmente configurações de rede sem fio em todos os computadores na sua rede do Active Directory. Felizmente, o Windows oferece suporte a uma extensão especial da Diretiva de Grupo para Configuração de Computador que permite que você faça isso. Ela é
chamada de extensão de Políticas de Rede Sem Fio (IEEE 802.11), com suporte em computadores executando o Windows Vista™, o Windows® XP, o Windows Server® 2003 e a próxima versão do Windows Server, cujo codinome é “Longhorn”.
Veja como funciona. Seja ao participar do domínio ou ao iniciar (em uma base contínua depois disso), esses sistemas operacionais baixam automaticamente as configurações sem fio nessa extensão da Diretiva de Grupo e as aplica. Você pode configurar as políticas sem fio para um objeto da Diretiva de Grupo a partir do nó a seguir no snap-in do Editor de Objeto de Diretiva de Grupo: Configuração do Computador | Configurações do Windows | Configurações de Segurança | Diretivas de Rede Sem Fio (IEEE 802.11).
A Figura 1 mostra a localização do nó das Diretivas de Rede Sem Fio (IEEE 802.11) para um domínio do Windows Server cujo codinome é "Longhorn" ou para um domínio do Windows Server 2003, que já tenha tudo seu esquema ampliado com os arquivos de extensão 802.11Schema.ldf e 802.3Schema.ldf (descritos no site microsoft.com/technet/network/wifi/vista_ad_ext.mspx).
Figura 1 Nó das Diretivas de Rede Sem Fio (IEEE 802.11)
Figura 1 Nó das Diretivas de Rede Sem Fio (IEEE 802.11) (Clique na imagem para diminuir a exibição)
Figura 1 Nó das Diretivas de Rede Sem Fio (IEEE 802.11)
Figura 1 Nó das Diretivas de Rede Sem Fio (IEEE 802.11) (Clique na imagem para aumentar a exibição)
Por padrão, não há Diretivas de Rede Sem Fio (IEEE 802.11). Para criar uma nova diretiva, clique com o botão direito do mouse em Diretivas de Rede Sem Fio (IEEE 802.11) na árvore do console e, em seguida, clique em Criar uma nova diretiva do XP ou clique em Criar uma nova diretiva do Windows Vista. Para cada tipo de diretiva, você pode criar somente uma única diretiva, mas cada diretiva pode conter configurações para várias redes sem fio.
Para a diretiva do Windows XP, as configurações de diretiva são muito semelhantes às descritas na minha coluna em julho de 2003. No entanto, há novas opções para redes sem fio sem difusão, métodos de autenticação WPA2 (Wi-Fi Protected Access) e configurações de roaming rápido para autenticação de WPA2. Para oferecer suporte a essas novas configurações, os computadores executando o Windows XP Service Pack 2 (SP2) devem instalar o Atualização para Cliente com Conexão sem Fio do Windows XP SP2 localizada no site support.microsoft.com/kb/917021.
A diretiva do Windows Vista contém configurações de diretiva específicas para clientes sem fio do Windows Vista e do Windows Server “Longhorn”. Se ambos os tipos de diretivas sem fio estiverem configurados, os clientes sem fio do Windows XP e do Windows Vista utilizarão somente as suas próprias configurações. Não há configurações de diretiva do Windows Vista, os clientes sem fio do Windows Vista utilizarão as configurações do Windows XP. Este artigo descreve as configurações que podem ser configuradas com a diretiva sem fio do Windows Vista.
Na guia Geral de uma diretiva de rede sem fio do Windows Vista, você pode configurar um nome e uma descrição para a diretiva, especificar se o serviço de Configuração Automática de WLAN está habilitado e configurar a lista de perfis de rede sem fio e suas configurações na ordem preferida (consulte a Figura 2). Você também pode exportar um perfil como um arquivo XML ao selecionar o perfil e clicar em Exportar. Para importar um arquivo XML como um perfil sem fio, clique em Importar e especifique a localização do arquivo.
Figura 2 Propriedades da diretiva de rede sem fio
Figura 2 Propriedades da diretiva de rede sem fio (Clique na imagem para diminuir a exibição)
Figura 2 Propriedades da diretiva de rede sem fio
Figura 2 Propriedades da diretiva de rede sem fio (Clique na imagem para aumentar a exibição)
A Figura 3 mostra a guia Permissões de rede para uma diretiva de rede sem fio do Windows Vista com suas configurações padrão. Essa guia é nova para o Windows Vista e permite que você especifique redes sem fio pelo nome e se deseja permitir ou negar acesso a elas. Por exemplo, você pode criar uma Lista de permissão contendo nomes de redes sem fio, também conhecida como Identificadores de conjunto de serviço (SSID, Service Set Identifiers) para os quais um cliente sem fio do Windows Vista têm permissão para estabelecer uma conexão. Isso é útil para administradores de rede que querem que computadores laptop da organização sejam conectados a um conjunto específico de redes sem fio, que pode incluir a rede sem fio da organização e provedores de serviços de Internet.
Figura 3 Guia Permissões de rede
Figura 3 Guia Permissões de rede (Clique na imagem para diminuir a exibição)
Figura 3 Guia Permissões de rede
Figura 3 Guia Permissões de rede (Clique na imagem para aumentar a exibição)
Com uma lista de negações, é possível especificar por nome o conjunto de redes sem fio, para as quais o cliente sem fio não tem permissão para se conectar. Isso é útil para evitar que computadores laptop gerenciados se conectem a outras redes sem fio que estejam dentro do alcance – por exemplo, quando uma organização ocupa um andar de um edifício e há outras redes sem fio de outras organizações nos andares vizinhos. Você também pode impedir que computadores laptop gerenciados se conectem a redes sem fio não protegidas conhecidas usando uma lista de negação. Para criar uma lista ou especificar as redes sem fio individuais que terão acesso concedido ou negado, clique em Adicionar para acrescentar uma rede sem fio por nome e especificar se será permitida ou negada.
Na guia Permissões de rede, também há configurações para impedir conexões a redes ad hoc ou sem fio no modo de infra-estrutura. Você também pode permitir que usuários visualizem as redes sem fio configuradas como negadas, bem como habilitar que qualquer usuário crie um perfil para todos os usuários. Um perfil para todos os usuários pode ser usado para conectar-se a uma rede sem fio específica por qualquer usuário com uma conta no computador. Se essa configuração estiver desabilitada, somente os usuários no grupo Administradores da rede ou Operadores da rede podem criar perfis sem fio para todos os usuários no computador.

Propriedades do perfil de rede sem fio
Para gerenciar um perfil de rede sem fio a partir da guia Geral da diretiva de rede sem fio do Windows Vista, selecione um perfil existente e clique em Editar, ou clique em Adicionar e especifique se o novo perfil sem fio será para uma rede ad hoc ou sem fio no modo de infra-estrutura.
Para criar um novo perfil sem fio, comece pela guia Conexão nomeando o perfil e criando uma lista de nomes de rede sem fio às quais ele se aplica (consulte a Figura 4). Você pode adicionar novos nomes digitando o nome em Nome(s) de rede (SSID) e clicando em Adicionar. Você também pode especificar se o cliente sem fio usando esse perfil tentará automaticamente se conectar às redes sem fio nomeadas no perfil quando no intervalo (sujeito à ordem de preferência da lista dos perfis sem fio na guia Geral da diretiva do Windows Vista). Além disso, você pode indicar se deseja desconectar-se automaticamente da rede sem fio se uma rede sem mais preferida for disponibilizada, e indicar se as redes sem fio nesse perfil são redes sem difusão (também conhecidas como redes ocultas).
Figura 4 Guia Conexão
Figura 4 Guia Conexão (Clique na imagem para diminuir a exibição)
Figura 4 Guia Conexão
Figura 4 Guia Conexão (Clique na imagem para aumentar a exibição)
Na guia Segurança, mostrada na Figura 5, você pode configurar os métodos de autenticação e criptografia para as redes sem fio no perfil. A seleção dos métodos de criptografia depende da sua escolha do método de autenticação. As opções para cada um são apresentadas na Figura 6.
Figure 6 Métodos de segurança (Close Figure 6)

Métodos de autenticação
Aberta
Compartilhada
Wi-Fi Protected Access (WPA)-Personal
WPA-Enterprise
WPA2-Personal
WPA2-Enterprise
Open with 802.1X
Métodos de criptografia
WEP (Wired Equivalent Privacy)
TKIP (Temporal Key Integrity Protocol)
AES (Padrão Avançado de Criptografia)
Figura 5 Guia Segurança
Figura 5 Guia Segurança (Clique na imagem para diminuir a exibição)
Figura 5 Guia Segurança
Figura 5 Guia Segurança (Clique na imagem para aumentar a exibição)
Se decidir selecionar WPA-Enterprise, WPA2-Enterprise ou Open with 802.1X como o método de autenticação, você também pode configurar o método de autenticação de rede (o tipo EAP [Extensible Authentication Protocol]), o modo de autenticação (reautenticação do usuário, autenticação do computador, autenticação do usuário ou de convidado), o número de vezes que as tentativas de autenticação podem falhar se abandonada e se é possível armazenar em cache as informações do usuário para conexões subseqüentes. A última configuração especifica que os dados de credencial do usuário sejam removidos do Registro quando ele fizer logoff. Isso fará com que as credenciais do usuário sejam solicitadas (como o nome de usuário e a senha) quando ele fizer logon novamente.
Para configurar as definições avançadas de segurança para os métodos de autenticação WPA-Enterprise, WPA2-Enterprise ou Open with 802.1X, clique em Avançado. A Figura 7 mostra a caixa de diálogo das configurações avançadas de segurança padrão.
Figura 7 Caixa de diálogo Configurações avançadas de segurança
Figura 7 Caixa de diálogo Configurações avançadas de segurança (Clique na imagem para diminuir a exibição)
Figura 7 Caixa de diálogo Configurações avançadas de segurança
Figura 7 Caixa de diálogo Configurações avançadas de segurança (Clique na imagem para aumentar a exibição)
Na seção IEEE 802.1X, você pode especificar o número de mensagens de início EAP sobre LAN (EAPOL) sucessivas enviadas quando não houver resposta inicial das mensagens de início-EAPOL recebidas, bem como o intervalo de tempo entre a retransmissão de mensagens de início-EAPOL quando não houver resposta à mensagem de início-EAPOL enviada anteriormente que foi recebida. Você também pode definir o período para o qual o cliente sendo autenticado não executará qualquer atividade de autenticação 802.1X depois de ter recebido uma indicação de falha de autenticação do autenticador, além do intervalo para o qual o cliente sendo autenticado deverá aguardar para retransmitir quaisquer solicitações 802.1X depois que a autenticação 802.1X fim a fim tiver sido iniciada.
O SSO (Single sign-on, logon único) permite que você configure quando a autenticação 802.1X ocorrerá em relação ao logon do usuário, bem como para integrar o logon do usuário e as credenciais de autenticação 802.1X no servidor de logon do Windows. Na seção de SSO, há configurações para executar a autenticação sem fio imediatamente antes ou depois do processo de logon do usuário, bem como para especificar o número de segundos de atraso da conectividade antes de o processo iniciar. Você também pode indicar se deseja solicitar ao usuário campos adicionais de entrada, caso o método de autenticação requeira que o usuário digite credenciais adicionais e por quanto tempo exibir esses campos, bem como se as redes sem fio desse perfil utilizarão uma LAN virtual (VLAN) para a autenticação do computador ou usuário.
Na seção Roaming rápido, você pode configurar as opções de pré-autenticação e cache PMK (Pairwise Master Key, chave mestre de paridade). A seção Roaming rápido aparece somente quando você selecionar WPA2-Enterprise como o método de autenticação. Com o cache PMK, os clientes sem fio e pontos de acesso sem fio (APs, access points) armazenam em cache os resultados das autenticações 802.1X. Portanto, o acesso é muito mais rápido quando um cliente sem fio efetua roam de volta para um AP sem fio, para o qual o cliente já foi autenticado. Você pode configurar um tempo máximo para manter uma entrada no cache PMK e o número máximo de entradas. Com a pré-autenticação, um cliente sem fio pode executar uma autenticação 802.1X com outros APs sem fio no seu intervalo enquanto ainda estiver conectado no seu atual AP sem fio. Se o cliente sem fio efetuar roam em um AP sem fio, o qual já sido pré-autenticado, o tempo de acesso será substancialmente maior. Você pode configurar o número máximo de vezes para tentativas de pré-autenticação com um AP sem fio.
Para obter mais informações sobre o suporte sem fio no Windows, consulte microsoft.com/wifi. Para obter mais informações sobre a Diretiva de Grupo do Windows, consulte os recursos no site microsoft.com/gp.

Joseph Davies é redator técnico da Microsoft, e vem ensinando e escrevendo sobre tópicos de sistema de redes Windows desde 1992. Escreveu cinco livros para a Microsoft Press e é autor da coluna mensal The Cable Guy da Technet (em inglês).


 Windows PowerShell: Filtrando e formatando dados
Windows PowerShell
Filtrando e formatando dados
Don Jones

Não há dúvida de que o Windows PowerShell pode, sem muito esforço de sua parte, retornar um grande volume de informações importantes. Por exemplo, considere o simples cmdlet Get-WMIObject, o qual pode ser utilizado para retornar uma lista de serviços no computador local. A visualização padrão, a qual apresenta o status, o nome e o modo de inicialização dos
serviços em execução, é essencialmente uma visualização da linha de comando do console Serviços. O Windows PowerShell™ simplesmente facilita muito mais o acesso.
No entanto, há informações muito mais úteis disponíveis para serviços do que apenas as exibidas na visualização padrão. Tente executar este comando:
$s = get-wmiobject win32_service
$s[0] | gm
A primeira linha do comando retorna uma coleção de todos os serviços (ou, mais especificamente, todas as instâncias da classe Win32_Service da Instrumentação de Gerenciamento do Windows® ou WMI), armazenando-a na variável $s. A segunda linha utiliza o primeiro serviço nessa coleção (número zero ordinal, indicado em colchetes) e o canaliza para o cmdlet Get-Member, o qual abreviei usando o seu alias, gm. A saída resultante mostra todas as propriedades e métodos disponíveis para esse tipo de dados. Decidi utilizar a classe Win32_Service no WMI, em vez de o cmdlet Get-Service cmdlet interno no Windows PowerShell, pois na verdade o WMI expõe mais informações do que o objeto ServiceController do Microsoft® .NET, inclusive a propriedade StartName. Essa propriedade informa o nome da conta de usuário na qual o serviço está sendo executado. É possível verificar o nome de uma única instância, como a primeira, da seguinte forma:
PS C:\> $s[0].StartName
LocalSystem
No entanto, a consulta aos serviços pelo seu número ordinal na coleção não é muito útil, pois os serviços não estão em uma ordem determinada. (Geralmente, eles são apresentados em ordem alfabética, mas nem sempre.) De uma perspectiva do gerenciamento, é provável que você esteja mais interessado em uma lista com todos os serviços e a conta que cada um deles está utilizando para fazer logon. Digamos que isso seria útil, por exemplo, para uma auditoria de conformidade. Vamos fazer uma breve pausa e verificar o que a WMI está fornecendo por padrão. Utilizarei um alias Get-WMIObject abreviado, gwmi (consulte a Figura 1).
Figure 1 Usando o gwmi (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
Obviamente, esse é apenas um exemplo, mas é possível ver que a saída não é de fato ideal para um relatório de gerenciamento. As informações que quero obter são o nome do serviço e o StartName, que é a conta na qual o serviço está sendo executado. Além disso, quero que o relatório tenha um formato mais legível, em vez de uma lista com aparência um tanto desajeitada. É exatamente nesse ponto que os formidáveis cmdlets de formatação e filtros de dados do Windows PowerShell exercem sua função.

Como obter os dados necessários
Iniciarei filtrando os dados do Get-WMIObject, de forma que as propriedades nas quais estou interessado sejam exibidas. A melhor forma de fazer isso é utilizar o cmdlet Select-Object do Windows PowerShell ou seu simples alias, select. O alias select foi desenvolvido para aceitar uma coleção de objetos – como a coleção retornada pelo Get-WMIObject – e exibir apenas as propriedades desejadas desses objetos. Isso significa que posso canalizar a saída de gwmi para selecionar e especificar as duas propriedades nas quais estou interessado. A Figura 2 mostra os resultados, os quais incluem as propriedades Name e StartName formatadas perfeitamente como uma tabela.
Figura 2 Visualizando apenas as propriedades Name e StartName em uma tabela
Figura 2 Visualizando apenas as propriedades Name e StartName em uma tabela (Clique na imagem para diminuir a exibição)
Figura 2 Visualizando apenas as propriedades Name e StartName em uma tabela
Figura 2 Visualizando apenas as propriedades Name e StartName em uma tabela (Clique na imagem para aumentar a exibição)
No entanto, se eu estivesse produzindo esse relatório para uma auditoria de conformidade, ele realmente teria muito mais informações. Alguns dos serviços estão desabilitados; portanto, provavelmente não importará para qualquer pessoa que ler a saída qual conta os serviços desabilitados teoricamente utilizariam. Por esse motivo, quero filtrar todos os serviços que tenham um tipo de inicialização Disabled – que é a propriedade StartMode da classe Win32_Service.
O Windows PowerShell executa a filtragem de objetos usando o cmdlet Where-Object ou seu alias abreviado, where. O cmdlet where aceita uma coleção de objetos de entrada e executa cada um deles por meio de um scriptblock, a fim de determinar se cada objeto estará presente ou não na saída do cmdlet com base em um conjunto de critérios definidos. Cada objeto que atender aos critérios produzirá uma comparação True e será incluído na saída; os objetos que produzirem um valor False não serão incluídos.
Dessa forma, defini que desejo somente objetos cuja propriedade StartMode seja igual a Disabled. Nos termos do Windows PowerShell, essa avaliação seria semelhante ao seguinte:
$object.StartMode –eq “Disabled”
É claro que $object é apenas um exemplo. Na verdade, não estou escrevendo um script e, portanto, não tenho uma variável nomeada $object. No entanto, no scriptblock utilizado pelo where, eu tenho o uso de uma variável especial nomeada $_, a qual representa o objeto sendo atualmente avaliado pelo cmdlet. Dessa forma, o meu scriptblock teria o seguinte formato:
$_.StartMode –eq “Disabled”
Posso testar isso facilmente:
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
É claro, nesse rápido teste, a saída está aparecendo novamente no estilo de lista padrão. E, para conservar o espaço, incluí somente um serviço nesse exemplo. Porém, você observará que essa saída é retroativa. Incluí serviços desabilitados, em vez de excluí-los. Fiz isso devido ao fato de ter obtido retroativamente o meu scriptblock: eu preciso incluir todos os serviços nos quais o StartMode não é igual a Disabled, como mostrado pela seguinte modificação no meu exemplo:
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
Isso é melhor! Agora que a saída contém somente os serviços nos quais estou de fato interessado, posso novamente canalizá-la para selecionar e especificar apenas as propriedades que desejo:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
Esse recurso de canalizar os dados de um cmdlet para outro e ainda para outro realmente ilustra os recursos do Windows PowerShell. Ainda não escrevi um script, mas já executei a filtragem em um complexo conjunto de dados para obter somente a saída que desejo.

A aparência correta
Você deve ter em mente que a saída de select ainda consiste em vários objetos. Quando tento recuperar uma tabela perfeitamente formatada usando o Windows PowerShell, isso é na realidade a reprodução do PowerShell.exe desses objetos. Em outras palavras, o Windows PowerShell sabe que eu, como um mero humano, não posso visualizar os objetos; portanto, ele os processa como texto. Nesse caso, ele processou os objetos como uma tabela, com uma coluna para cada propriedade, como ilustrado na Figura 2.
Isso seria suficiente para os meus objetivos de auditoria. Mas, por outro lado, talvez não. Cada pessoa tem necessidades diferentes – o Windows PowerShell não pode presumir quais sejam essas necessidades específicas. Em vez disso, ele oferece as ferramentas para que você formate a saída do modo que lhe seja mais conveniente. Quatro cmdlets internos – Format-List, Format-Custom, Format-Table e Format-Wide – foram desenvolvidos para aceitar uma coleção de objetos (como a coleção retornada por select) e formatar tais objetos de várias formas. O Format-Table é basicamente o que o Windows PowerShell já utiliza para formatar a saída do meu cmdlet select. Para obter uma aparência diferente, vamos tentar o Format-List:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
O resultado é de certa forma semelhante a este exemplo:
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
O cmdlet Format-Wide foi desenvolvido para produzir uma lista com várias colunas, por padrão, da primeira propriedade de cada objeto. Por exemplo, utilize esta linha:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
Ela produz uma lista de nomes de serviço, que não é o que eu desejo. A saída não apresenta o StartName (consulte a Figura 3), que é uma parte importante da informação que eu preciso no meu relatório de auditoria.
Figura 3 A saída exibida usando o cmdlet Format-Wide omite a principal informação – o StartName
Figura 3 A saída exibida usando o cmdlet Format-Wide omite a principal informação – o StartName (Clique na imagem para diminuir a exibição)
Figura 3 A saída exibida usando o cmdlet Format-Wide omite a principal informação – o StartName
Figura 3 A saída exibida usando o cmdlet Format-Wide omite a principal informação – o StartName (Clique na imagem para aumentar a exibição)
Como estou lidando somente com duas propriedades, é provável que Format-Table ou Format-List seja aceitável. Mas é improvável que uma auditora fique satisfeita em visualizar essas informações na tela. Ela provavelmente preferiria um arquivo de algum tipo.

Exportando dados
Sendo assim, como um auditor gostaria de visualizar os dados? A saída da lista de serviços e nomes de login em um arquivo CSV (Comma-Separated Values, valores separados por vírgulas) deve ser suficiente, pois o arquivo pode ser facilmente aberto no Microsoft Excel®. Para criar um arquivo CSV, basta canalizar a sua saída para um cmdlet Export-CSV do Windows PowerShell:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
É claro que no mundo atual o CSV parece um pouco desatualizado. Talvez os seus auditores prefiram que os dados sejam exibidos como uma página da Web em um servidor de intranet. Para fazer isso, comece convertendo a saída para HTML, usando o cmdlet ConvertTo-HTML:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
O formato HTML bruto é de difícil visualização; portanto, precisarei escrever a saída em um arquivo:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
O resultado, mostrado na Figura 4, é uma página HTML bem formatada, a qual pode ser divulgada em qualquer servidor da Web sem a necessidade de modificações adicionais.
Figura 4 A saída exibida como uma página HTML bem formatada
Figura 4 A saída exibida como uma página HTML bem formatada (Clique na imagem para diminuir a exibição)
Figura 4 A saída exibida como uma página HTML bem formatada
Figura 4 A saída exibida como uma página HTML bem formatada (Clique na imagem para aumentar a exibição)

Apenas os fatos (relevantes)
O Windows PowerShell oferece fácil acesso a uma ampla variedade de dados de gerenciamento. No entanto, em seu estado bruto, esses dados nem sempre são úteis do ponto de vista dos negócios.
Ao filtrar os dados (usando where), escolher as propriedades desejadas do objeto (usando select) e aplicar uma opção de formato apropriada (como Format-Table ou Format-List), você pode rapidamente transformar esses dados de gerenciamento em informações úteis com muito pouco esforço. E, finalmente, exportando os dados para um formato de arquivo que possa ser facilmente compartilhado, você pode usar essas informações além da sua área de trabalho e comunicar informações importantes a outras pessoas na sua empresa.

Don Jones é o diretor de projetos e serviços da SAPIEN Technologies e co-autor do Windows PowerShell: TFM (SAPIEN Press). Entre em contato com Don em seu site em www.ScriptingAnswers.com.


 Ei, Equipe de Scripts!: Gerenciando ingenuamente usu&#225;rios e grupos locais
Ei, Equipe de Scripts!
Gerenciando ingenuamente usuários e grupos locais
A Equipe de Scripts da Microsoft
Faça download do código deste artigo: HeyScriptingGuy2007_04.exe (151KB)

Como posso gerenciar descritores de segurança em arquivos e pastas?

Acredite ou não, houve um tempo – há muito tempo é claro – que a Equipe de Scripts realmente não era tão inteligente. Nós sabemos que é difícil de acreditar, mas – o que você quer dizer com não é tão difícil de acreditar? E o que você quer dizer com não foi há muito tempo? Por quê? Nós lhe diremos – ah, OK. Obviamente você viu um dos autores da Equipe de Scripts tentando conectar uma TV nova um dia desses.
Em sua defesa, no entanto, esse específico membro da Equipe de Scripts argumentaria que conectar uma TV nova não é algo importante para a ciência espacial; na verdade, é uma ciência mais complicada. Basta ver que conectar a própria TV envolve três cabos de vídeo e um par de cabos de áudio; no topo disso você terá então que conectar um videocassete, um DVD e um Xbox®, para não mencionar as indicações de conjuntos aleatórios de números em remoto “universal” para tentar e conseguir reconhecer todos esses dispositivos. Comparado a isso, colocar um satélite em órbita em torno do planeta Marte é muito fácil!
Notavelmente, a Equipe de Scripts na verdade tenta obter todas essas conexões da forma correta. No entanto, quando ele ligou tudo, nada aconteceu. Obedientemente, ele verificou duas, três vezes cada conexão. Ele havia lido todos os manuais de usuário e até mesmo verificado o manual online para ver se poderia ter alguma informação faltando. Nada. Ele estava quase sacrificando um MP3 player quando percebeu que não havia concluído a etapa principal: conectar o cabo na tomada da parede.
Observação: você pode estar pensando se é tão difícil conectar todas as coisas da Família de Scripts, talvez a Família de Scripts é que tenha muitas coisas. Na verdade, esse membro da Equipe de Scripts concordaria com isso. No entanto, a qualquer momento que a família decidir adquirir mais itens, esse membro da Equipe de Scripts perderá de 2 a 0. Não, deveria ser de 2 a 1, mas é 2-0. Por algum motivo, o Pai do membro da Equipe de Scripts nunca parece participar das escolhas da família, e não tem nenhuma função nesse caso.
Na resposta à sua próxima dúvida, sim, ele tentou. Mas as Nações Unidas recusaram enviar monitores de eleição para a causa da Equipe de Scripts.
É claro, agora que pensamos sobre isso, não era muita coisa, afinal de contas a Equipe de Scripts (bem, o membro da nova TV em específico) não era burra nem ingênua. Por exemplo, quando eles estavam planejando o Guia de Scripts da Microsoft® Windows® 2000, eles pediram ajuda de vários... especialistas... no momento de concluir os capítulos dos livros. Um dos capítulos que não foi aprovado foi o capítulo sobre gerenciamento de usuários e grupos locais. “Gerenciar usuários e grupos locais?!?”, disseram os especialistas. “Por que isso está sendo considerado? Quem se importa com o gerenciamento de usuários e grupos locais?”.
Bem, para grande parte da nossa decepção descobrimos que todos (com a possível exceção de nossos “especialistas” internos) se preocupam com usuários e grupos locais. Cada semana recebemos toneladas de emails de pessoas perguntando como fazer coisas como adicionar um usuário a um grupo local, excluir um usuário de um grupo local ou alterar a senha do Administrador local em um computador.
Está certo, o Repositório de Scripts da Central de Scripts apresenta alguns scripts de exemplo que mostram como executar essas tarefas, mas a maioria desses scripts funciona em computador uma só vez. Isso não é o suficiente: as pessoas querem saber como fazer isso em várias máquinas, e tudo ao mesmo tempo. Alterar a senha do administrador local em um computador em más condições? Mantenham contato com o mundo real, Equipe de Scripts – queremos fazer isso em todos os nossos computadores ou em todos os computadores em uma unidade organizacional ou em todos os nossos servidores de email ou – bem, você entendeu!.
Considerando o fato de que o Guia de Scripts ter sido publicado em 2003, isso significa que gastamos praticamente quatro anos sendo incomodados com as mesmas mensagens de email. “Aqui está outro leitor perguntando como ele pode ler os nomes do computador a partir de uma planilha do Excel® e alterar a senha do administrador local em cada um desses computadores”, um dos membros da Equipe de Scripts recentemente lembrou. “O que podemos fazer em relação a isso?”
Bem, levamos quatro anos, mas finalmente descobrimos! A Figura 1 mostra exatamente o que podemos fazer em relação a isso.
Figure 1 Finalmente eu descobri! (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
Observação: Como você pode ver, não levamos quatro anos para escrever esse script por ele ser muito difícil; levamos quatro anos para escrevê-lo pelo fato de sempre demorarmos para fazer quase tudo. É por isso que você nunca quer perder as festas anuais de final de ano da Equipe de Scripts; afinal de contas, você nunca sabe quando, ou se, no ano seguinte terá festa.
O que temos aqui é um script que apresenta os nomes de computadores a partir de uma planilha e, em seguida, altera a senha do administrador local em cada um desses computadores. Para realizar essa mágica, iniciamos com facilidade, supondo que você tenha uma planilha muito simples, uma que se pareça com a Figura 2. (Caso contrário, crie uma agora mesmo.)
Figura 2 Lista obrigatória de computadores
Figura 2 Lista obrigatória de computadores (Clique na imagem para diminuir a exibição)
Figura 2 Lista obrigatória de computadores
Figura 2 Lista obrigatória de computadores (Clique na imagem para aumentar a exibição)
Como você pode ver, não há nada de especial aqui. Na coluna 1 (coluna A), listamos os nomes de todos os computadores que têm as senhas que precisamos alterar. Na coluna 2 (coluna B), simplesmente controlamos a data e a hora que a senha do administrador em cada computador foi alterada. Isso facilita para você manter as guias ativadas independentemente de as senhas do administrador estarem todas sincronizadas.
Em relação ao script por si só, resolvemos tudo rapidamente com a instrução On Error Resume Next. Geralmente, não nos importamos de incluir tratamento de erros em nossos scripts. Não por sermos contrários ao tratamento de erros; em vez disso, é pelo fato de tentarmos manter os nossos scripts breves e fáceis de acompanhar. No entanto, nesse caso, a instrução On Error Resume Next é fundamental. Afinal de contas, o nosso script está tentando se conectar a pontos em computadores diferentes. O que acontece se um desses computadores estiver desligado? Bem, com o tratamento de erros, não acontecerá nada. É claro, ocorrerá um erro, mas o script poderá ignorá-lo e continuar. Sem o tratamento de erros aconteceria a mesma coisa que aconteceu com o membro da Equipe de Scripts quando ele ligou a nova TV pela primeira vez: nada.
Em seguida, utilizaremos o bloco a seguir de código para criar uma instância do objeto Excel.Application, fazer com que essa instância do Excel esteja visível na tela e abrir a planilha C:\Scripts\Test.xls:
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
E, por último, mas não certamente menos importante, atribuiremos o valor 2 a uma variável do contador nomeada i. Utilizaremos essa variável para controlar a nossa atual linha na planilha.
Observação: então, por que i recebe o valor 2? É fácil: se você analisar na planilha detalhadamente você verá que os nossos dados na verdade começam na linha 2. A linha 1 é apenas a linha do cabeçalho.
Viu? Podemos não ser tão bons em conectar cabos YPbPr1, mas sabemos alguma coisa sobre scripts.
Bem, às vezes...
Agora estamos prontos para o trabalho. Primeiramente, configuramos um loop Do Until que executará até encontrar uma célula vazia na coluna 1. E sim, isso significa que não importa o que mais você faça, você não pode deixar nenhuma linha em branco na coluna 1. Se o seu script encontrar uma linha em branco, ele assumirá que foi atingido o final dos dados, de forma que o loop (e o script) será encerrado. E apesar de haver formas de solucionar isso, é muito mais fácil apenas evitar ter linhas em branco em qualquer parte da planilha.
Dentro do loop, começamos atribuindo o valor encontrado na linha da célula i, coluna 1 para uma variável nomeada strComputer. (Lembre-se, a primeira vez no loop i é igual a 2; portanto, estaremos trabalhando com o valor na linha 2 da célula, coluna 1.) Utilizamos então essa linha de código para criar uma referência de objeto (objUser) para a conta do administrador no computador representado pela variável strComputer:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
Se algo for errado com esse script, você verá isso nesse momento. Por exemplo, suponha que estejamos tendo problemas de rede, suponha que o computador tenha sido desligado ou que um dos membros da Equipe de Scripts tenha conectado o DVD de forma errada e tenha ocorrido um blecaute em toda a região ocidental dos Estados Unidos. Se qualquer uma dessas coisas acontecer, não poderemos efetuar uma conexão ao computador. É por isso que verificamos imediatamente o valor do objeto VBScript Err:
If Err = 0 Then
Se o objeto Err for igual a 0, isso significa que tivemos problema para conectar o computador (e com a conta do administrador) sem qualquer problema. Se Err for igual a qualquer coisa além de 0, isso pode significar somente uma coisa: a nossa tentativa de conexão falhou. Nesse caso, nem tentaremos alterar a senha nesse computador; nem é necessário dizer, se não podemos fazer uma conexão, não poderemos alterar a senha.
Supondo que tudo ocorra bem e que não ocorram erros, executaremos as seguintes duas linhas de código:
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
Na linha 1, usamos o método SetPassword para atribuir uma nova senha (egTY634!alK2) à conta do administrador local. (E sim, sabemos: você não deve usar o nome do seu filho como uma senha.) Na linha 2, gravamos a data e a hora atual (usando a função VBScript Now) na linha da célula i, coluna 2. Observe que atualizamos a coluna Senha Alterada somente se você pudesse na verdade se conectar ao computador remoto e alterar a senha. Se não conseguirmos nos conectar a computador, então seu campo correspondente Senha Alterada nunca será atualizado; é dessa forma que podemos fizer quais operações tiveram êxito e quais não tiveram.
O que tudo isso significa? Isso significa que, na primeira vez que passar pelo loop, a nossa planilha se parecerá com a Figura 3.
Figura 3 Lista de computadores depois de redefinir a primeira senha
Figura 3 Lista de computadores depois de redefinir a primeira senha (Clique na imagem para diminuir a exibição)
Figura 3 Lista de computadores depois de redefinir a primeira senha
Figura 3 Lista de computadores depois de redefinir a primeira senha (Clique na imagem para aumentar a exibição)
Muita coisa para o computador 1. Agora precisamos apenas de uma limpeza antes de continuar:
Err.Clear
i = i + 1
Curtas como devem ser, essas linhas de código são muito importantes. (Como se a Equipe de Scripts fosse escrever qualquer linha de código que não fosse tão importante!). A primeira linha redefine o objeto Err como 0. Se não ocorrer erro, isso é redundante; afinal de contas, nesse caso o Err já será 0. Se um erro ocorrer, no entanto, o Err será igual a um valor diferente de 0. Nesse caso, é fundamental que o objeto Err seja redefinido manualmente. Por quê? Como esse é o objeto Error: ele somente controla os erros, ele não controla os êxitos. Por exemplo, suponha que tenha ocorrido um problema com o computador 1 e não possamos efetuar uma conexão. Visando o argumento, digamos que isso fez com que o objeto Error fosse definido como 99.
Agora, vamos supor que façamos um loop e consigamos nos conectar com êxito ao computador 2. Qual você acha que vai ser o valor de Err agora? É isso mesmo: você goste ou não, o Err ainda será definido como 99. Isso é devido ao fato de o valor do objeto Err ser alterado somente quando ocorre um erro; se não ocorrer erro, no entanto, o objeto Err manterá o seu atual valor sempre.
Isso realmente é importante para nós? Bem, deveria ser. Afinal de contas, tecnicamente não alteramos a senha em um computador se conseguirmos efetuar com êxito uma conexão; em vez disso alteramos a senha somente se Err for igual a 0. E – espere aí enquanto pegamos a calculadora – sim, você estava certo: 99 não é igual a 0 (exceto, é claro, nas eleições da Família da Equipe de Scripts, quando os 99 votos do Pai da Equipe de Scripts chegam a 0). E o que nos importa, mesmo que tenhamos feito a conexão para o computador 2, é que Err não seja igual a 0. E como Err não é igual a 0, nem mesmo tentamos alterar a senha do administrador local.
Em outras palavras, se o valor de Err sempre for alterado, você precisará redefinir esse valor para 0; caso contrário, o seu script acreditará que ocorreu um erro. E como você redefiniria o objeto Err de volta para 0? Você entendeu: basta chamar Err.Clear.
Em seguida, incrementamos o valor de i em 1. Por quê? Bem, na primeira vez em que foi executado o loop, a variável i igual a 2; isso pelo fato de desejarmos conectar ao computador listado na linha 2, coluna 1. Na segunda vez em que o loop foi executado, o objetivo era conectar ao computador listado na linha 3, coluna 1. Vendo como i é a variável que indica a linha que você quer trabalhar, precisamos fazer com que i seja igual a 3. E, como todos sabem, 2 + 1 = 3. (Ainda bem que ainda temos a calculadora, não é mesmo?) Somente então executaremos o loop e repetiremos o processo com o próximo computador na planilha.
Agora, muito bem, mas – veja como não somos mais tão ingênuos – estamos bem alertas de que esse script, por si só, raramente afetará o email que receberemos. “O lance do Excel foi interessante”, as pessoas dizem, “mas ainda preciso alterar a senha do administrador local em todos os computadores em uma unidade organizacional ou em todos os computadores listados em um arquivo de texto. Ou talvez eu queira obter um pop-up de uma lista de computadores e selecionar um de uma caixa de listagem. Ou talvez o que eu realmente gostaria de fazer fosse ...”
Relaxe. O seu desejo é o comando para a Equipe de Scripts. (Supondo que você queira esperar quatro anos para que o seu desejo se torne realidade.) No fim das contas, temos pontos de modelos de vários computadores publicados na Central de Scripts, modelos que tornam extremamente fácil a execução de um script em várias máquinas. Por exemplo, suponha que você queira alterar a senha do administrador local em todos os computadores em uma unidade organizacional. Ei, sem problemas. O modelo para execução de um script em todos os computadores em uma unidade organizacional seria semelhante à Figura 4.
Figure 4 Executando um script em uma unidade organizacional (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
Consulte a seção no modelo rotulada “Inserir seu código aqui?”. Tudo o que você precisa fazer é excluir o código de amostra localizado nessa seção e substituí-lo com o código (o qual você pode copiar desta coluna) para alterar a senha do administrador local. Em outras palavras, substitua o código de exemplo pelo código a seguir:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
Esse exemplo específico não registraria em log os resultados para você, mas você pode facilmente adicionar o código sozinho. Substitua o código de exemplo, altere a cadeia de caracteres da conexão LDAP://OU=Finance,dc=fabrikam,dc=com para que aponte para uma das suas unidades organizacionais e você estará pronto.
Para falar a verdade, publicamos esses modelos há um ano, imaginando que seria um dos itens mais populares da Central de Scripts. O que houve de errado: eles quase nunca foram usados, apesar de as pessoas nos escreverem quase todo dia perguntando como executar scripts em várias máquinas. Estamos supondo que ninguém sabia da existência desses modelos. Mas agora você sabe. Ou pelo menos você saberá se lhe dissermos onde encontrá-los: microsoft.com/technet/scriptcenter/scripts/templates. Hum, talvez seja por isso que nunca ninguém usou esses modelos...
Agora que a Equipe de Scripts não é mais tão ingênua quanto antes, isso também significa que eles não são mais tão burros e bobos como eram? Digamos assim: há não muito tempo um dos membros da Equipe de Scripts decidiu passar o final de semana consertando algumas coisas em casa. Quando ele voltou ao trabalho na segunda-feira, seu polegar estava tão machucado que não poderia estancar um sangramento e um grande arranhão na sua perna.
O que me faz pensar que realmente não foi tão mau assim! Pelo menos para um membro da Equipe de Scripts.

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: O Assistente de Configura&#231;&#227;o de Seguran&#231;a
Security Watch
O Assistente de Configuração de Segurança
John Morello
Esta coluna inclui informações de pré-lançamento sobre o Windows Server "Longhorn" que estão sujeitas a alterações.

A proteção dos servidores com eficiência e consistência é um desafio para muitas empresas de TI, especialmente para aquelas com grandes quantidades de máquinas dispersas em vários limites geográficos e organizacionais. Apesar de fortalecer um único servidor possa ser uma tarefa relativamente simples para um administrador experiente, a proteção de dezenas, centenas ou
até mesmo milhares de servidores é uma proposta bem diferente. Ao longo dos anos, muitas empresas estão utilizando suas próprias listas de verificação ou padrões internos para a segurança de servidor ou incorporaram orientações fornecidas pela Microsoft, pelo National Institute of Standards and Technology ou outros terceiros. Embora essa documentação possa ser tremendamente valiosa, a documentação por si só não é suficiente para permitir que as empresas realmente coloquem essas práticas recomendadas em ação em suas redes. Portanto, muitas optaram por manter as suas configurações de instalação padrão ou investiram tempo significativo e esforço para criar seus próprios scripts ou diretivas para proteção dos sistemas.
Com o advento do Security Configuration Wizard (SCW) no Windows Server® 2003 Service Pack 1 (SP1), a Microsoft agora oferece um método simples e compatível para proteção de servidores, reduzindo a superfície de ataque com base nas funções desempenhadas. Ao combinar os benefícios do SCW com a implantação centralizada e os recursos de gerenciamento da Diretiva de grupo, o SCW pode ser ampliado para as maiores empresas de TI. Na coluna deste mês, apresentarei uma visão geral de como as empresas de TI podem usar o SCW e a Diretiva de grupo para gerenciar seus servidores de forma mais segura e consistente, reduzindo os custos de implantação e operacionais.

O que é a SCW?
O SCW é um componente opcional, instalado através da opção Adicionar ou remover componentes do Windows®, disponível em todos os membros da família do Windows Server 2003 SP1, inclusive o Windows Server 2003 R2. Um administrador iniciaria executando o SCW em um servidor de destino para identificar as funções que o servidor atende. O SCW então auxilia o administrador na criação de uma diretiva de segurança, o que protege a máquina usando um esquema com menos privilégios. Em outras palavras, o SCW ajuda a garantir que somente esses serviços, recursos de aplicativo e portas necessárias para que os papéis funcionem estarão disponíveis; tudo que não seja especificamente necessário pelas funções que o servidor executa será desabilitado. Essa abordagem ajuda a reduzir a superfície de ataque do servidor de destino. Se você executar serviços que não sejam necessários para a função que o servidor executa, você aumenta o risco para o servidor sem qualquer ganho na capacidade ou funcionalidade. Desabilitar esses serviços reduzirá o risco e também pode aprimorar o desempenho do servidor.
Apesar de a Microsoft ter feito muitos avanços em segurança com o Windows Server 2003, reduzindo muito a superfície de ataque em comparação às versões anteriores do Windows Server, ele não foi desenvolvido no mesmo núcleo extremamente dividido por componentes que o Windows Vista™ e a próxima versão do Windows Server, cujo codinome é “Longhorn”. Portanto, em uma instalação padrão do Windows Server 2003, pode haver serviços habilitados e em execução que não sejam necessários em todas as configurações de função de servidor. Por exemplo, o serviço de Spooler de impressão é habilitado por padrão, mas não é necessário para uma máquina que esteja somente atuando como um servidor de banco de dados.

Tornando a segurança baseada em funções uma realidade
Ao longo dos últimos anos, a Microsoft lançou várias documentações com foco na segurança, as quais ajudam os administradores a compreenderem quais serviços são necessários em diferentes funções do servidor e fornecem modelos pré-criados para funções bem conhecidas como servidores da Web. No entanto, diretrizes como essas no Guia de segurança do Windows Server 2003 podem ser desafiadoras para implementar em ambientes de grande porte, especialmente quando os aplicativos utilizados nesses ambientes são com freqüência mais complexos que as instalações básicas do IIS ou SQL Server. Para complicar ainda mais a questão há uma grande variedade de aplicativos de terceiros que as empresas podem implantar, muitos dos quais têm dependências em várias funções e cujos requisitos de aplicativos e serviços não sempre bem definidos.
O SCW soluciona essas questões encapsulando todo o conhecimento sobre dependências e as práticas recomendadas contidas nos guias para um assistente direcionado ao administrador. Por exemplo, se um administrador estiver implantando um novo aplicativo da linha de negócios que requeira o SQL Server™ e o IIS, ele não precisará mais investir tempo significativo pesquisando no guia de segurança e em sua própria lista de dependências personalizadas. Em vez disso, ele pode instalar o aplicativo no servidor e iniciar o SCW. O SCW detectará quais serviços estão atualmente em execução e apresentará ao administrador uma lista das funções a serem escolhidas para o servidor. Dependendo da seleção dele, o SCW irá gerar uma diretiva que desabilitará todos os serviços desnecessários pela matriz de dependência das funções. O SCW também fornecerá opções para proteger o Registro, bloquear comunicações de rede desnecessárias e aplicar uma diretiva de auditoria eficiente. Depois de executar o SCW, o administrador pode salvar a diretiva do SCW como um arquivo XML e aplicá-la em qualquer outro servidor em execução no mesmo aplicativo da linha de negócios.
A execução do SCW fornece então três importantes vantagens em relação às abordagens tradicionais e mais manuais para proteger o Windows Server. Primeiramente, ele reduz extremamente (se não elimina) a necessidade de que um administrador consulte constantemente a documentação do produto, a fim de determinar os serviços e as configurações necessários para determinada carga de trabalho. Esse conhecimento é incorporado ao SCW e a interface direcionada a perguntas facilita que o administrador forneça os detalhes necessários. Em seguida, o SCW consolida a orientação para várias áreas, inclusive proteção de serviço, redução da superfície de ataque de rede, proteção de LDAP e serviços SMB, bem como bloqueio de IIS. Previamente, a execução dessas tarefas de configuração exigem utilitários separados, cada um com a sua própria interface e abordagem. Finalmente, como o SCW apresenta suas configurações em um arquivo de diretiva XML, ele pode ser usado em cenários “criar uma vez, aplicar várias”.. Independentemente de você estar implantando 1 ou 100 servidores para oferecer suporte a um determinado aplicativo da linha de negócios, a mesma diretiva do SCW será facilmente aplicada em todos eles. Isso torna as configurações de segurança mais consistentes e reduz os custos operacionais. Isso também facilita a reversão das diretivas do SCW.

Componentes do SCW
Para todos os recursos e benefícios, o SCW é na verdade uma ferramenta relativamente simples que consiste em três partes principais: a interface do assistente, a interface da linha de comando e o Security Configuration Database (SCD). Os administradores de empresas de pequeno e médio porte podem precisar interagir somente com a interface do assistente. Em ambientes maiores ou mais complexos, os administradores podem usar a interface da linha de comando para auxiliar na automatização das tarefas do SCW, como a transformação de uma diretiva do SCW em Objeto da Diretiva de Grupo (GPO, Group Policy Object). Geralmente, somente os administradores avançados que desejam criar suas próprias funções personalizadas do SCW modificarão o SCD.
A interface do assistente, mostrada na Figura 1, permite que os administradores criem, editem, apliquem e revertam configurações de segurança para um servidor de destino. Ele apresenta opções para os administradores em um fluxo de trabalho consistente, o qual examina primeiro os serviços e as configurações e, em seguida, a conectividade de rede e as diretivas de auditoria de segurança e, finalmente, as configurações de IIS.
Figura 1 Interface do SCW
Figura 1 Interface do SCW (Clique na imagem para diminuir a exibição)
Figura 1 Interface do SCW
Figura 1 Interface do SCW (Clique na imagem para aumentar a exibição)
A interface da linha de comando do SCW fornece três funções básicas. Ela permite que os administradores analisem e configurem vários servidores (locais ou remotos) e revertam as diretivas. Ela pode ser usada para converter automaticamente a diretiva do SCW baseada em XML em um GPO, o qual pode ser nativamente usado nas ferramentas de gerenciamento do GPO padrão, como o Console de Gerenciamento da Diretiva de Grupo. Finalmente, a ferramenta da linha de comando do SCW mostrada na Figura 2 é utilizada para registrar quaisquer extensões novas do banco de dados de configuração de segurança.
Figura 2 Ferramenta de linha de comando do SCW
Figura 2 Ferramenta de linha de comando do SCW (Clique na imagem para diminuir a exibição)
Figura 2 Ferramenta de linha de comando do SCW
Figura 2 Ferramenta de linha de comando do SCW (Clique na imagem para aumentar a exibição)
O SCD é simplesmente uma coleção de arquivos XML que detalham determinados serviços e configurações necessários para cada função do SCW. Esses arquivos estão localizados no %windir%\security\msscw\kbs. Por padrão, o SCW é fornecido com uma quantidade de funções principais do Windows Server, bem como com 12 funções de aplicativos predefinidas, inclusive: BizTalk®, Commerce Server, Exchange Server, Host Integration Server, Internet Security and Acceleration Server, Microsoft Identity Integration Server, Microsoft Operations Manager, Small Business Server, SharePoint® Portal Server, SharePoint Team Services, SQL Server e Systems Management Server. Cada função tem seu próprio arquivo XML (consulte a Figura 3). Sempre que uma nova definição de função for criada, o seu arquivo XML correspondente será posicionado em seu diretório. Os arquivos são XML padrão e podem ser lidos em qualquer visualizador de texto ou outro aplicativo que ofereça suporte a XML (consulte a Figura 4).
Figura 3 Funções predefinidas
Figura 3 Funções predefinidas (Clique na imagem para diminuir a exibição)
Figura 3 Funções predefinidas
Figura 3 Funções predefinidas (Clique na imagem para aumentar a exibição)
Figura 4 Arquivo de configuração da função
Figura 4 Arquivo de configuração da função (Clique na imagem para diminuir a exibição)
Figura 4 Arquivo de configuração da função
Figura 4 Arquivo de configuração da função (Clique na imagem para aumentar a exibição)

Combinando o SCW e a diretiva de grupo
Por si só, o SCW é uma excelente ferramenta, mas seu verdadeiro poder não é totalmente revelado até que seja combinado com a Diretiva de grupo. Desde o lançamento do Windows® 2000, as recomendações da Microsoft para proteção dos servidores do Windows tem sido concentrada no uso da Diretiva de grupo, a fim de fornecer aplicativo de diretiva consistente, persistente e gerenciado centralmente. Ao agrupar servidores em unidades organizacionais com base em suas funções, os administradores podem implantar configurações padrão de segurança em toda a empresa, em vez de no nível de máquina individual. Ao se desenvolver com base no acúmulo da diretiva de grupo padrão e na lógica do aplicativo, as empresas podem desenvolver uma hierarquia de função de servidor em camada, na qual várias diretivas mestre possam proteger centenas ou milhares de servidores individuais. Quando funções exclusivas de servidor exigirem variação das diretivas mestre, diretivas menores delta focalizadas em função podem ser criadas com maior proximidade na hierarquia da unidade organizacional para os próprios servidores. Isso permite que sejam feitas várias alterações para habilitar a funcionalidade específica por função sem precisar duplicar a diretiva mestre em sua totalidade, uma abordagem que fornece às grandes empresas os benefícios de uma diretiva gerenciada centralmente junto com a flexibilidade de adaptação a aplicativos específicos, quando necessário.
O verdadeiro desafio dessa abordagem é torná-la uma realidade. Para grandes empresas com muitos aplicativos e funções de servidor diferentes, a criação do conjunto correto de diretivas é difícil e demorada – ou era antes do SCW. Ao usar o SCW para gerar diretivas e anexá-las à unidade organizacional correta, você pode diminuir muito o tempo que leva para implantar a segurança com base em funções e hospedada em diretório nas cargas de trabalho existentes; além disso, você pode adotá-las posteriormente. Para melhor ilustrar como uma empresa deve fazer sua parte, vamos analisar uma implementação do SCW e de GPOs com base em função em uma grande empresa.

SCW na empresa
Para este exemplo, utilizarei a rede fictícia da Contoso. A Contoso possui um ambiente de TI amplo, complexo e geograficamente distribuído. Com o objeto de reduzir seus custos operacionais e aumentar a segurança de seus servidores, a Contoso segue as orientações da Microsoft para criar uma hierarquia da unidade organizacional com base em função, a qual separa e organiza os servidores com base na carga de trabalho. Para criar as diretivas a serem anexadas a essas unidades organizacionais, a Contoso utiliza o SCW.
Como o SCW não está instalado por padrão, a Contoso precisa habilitar especificamente o componente do SCW em sua imagem de instalação não assistida. Para fazer isso, será adicionada uma nova linha, SCW=On, na seção [Components] do Unattend.txt. Depois disso, todos os novos sistemas desenvolvidos com essa imagem terão o componente SCW instalado durante a configuração. Lembre-se de que simplesmente configurar o SCW para que seja instalado não aplica quaisquer diretivas a máquinas à medida que elas estiverem sendo desenvolvidas.
Para aplicar uma diretiva padrão durante o processo de instalação, a Contoso edita a seção [Commands] do arquivo cmdlines.txt na imagem para chamar o scwcmd com as seguintes opções:
scwcmd configure /p:ContosoBaselinePolicy.xml
O arquivo de texto e o arquivo XML devem estar no diretório $OEM$ da imagem. Por que a Contoso aplicaria uma diretiva da linha de base no momento da compilação em vez de simplesmente depender de uma anexada à unidade organizacional de nível superior no diretório? Ao aplicar uma diretiva no momento da compilação, a Contoso pode garantir uma linha de base consistente, independentemente de a máquina estar associada ao Active Directory®. Por exemplo, se um servidor for compilado para fins de teste, a aplicação da diretiva da linha de base durante o processo de compilação garante que ele, pelo menos, seguirá a diretiva de segurança padrão da empresa, mesmo se nunca estiver associado ao Active Directory de produção. Se o servidor for associado posteriormente ao Active Directory, a aplicação da Diretiva de grupo e o algoritmo precedente substituirão as configurações locais por aquelas do domínio ou nível da unidade organizacional (lembre-se de que a ordem de precedência do aplicativo de diretiva é local, site, domínio ou unidade organizacional).
Assim que o SCW tiver sido instalado, a Contoso pode começar a criar a sua diretiva da linha de base. A diretiva da linha de base deve ser aquela implantada no nível superior da hierarquia da unidade organizacional de segurança com base na função e geralmente será a diretiva mais restritiva na hierarquia. A idéia é ter uma segurança o mais padrão possível e, em seguida, abrir somente os serviços e portas para cargas individuais de trabalho, conforme necessário pelas funções desse servidor. Para isso, a diretiva da linha de base deve ser criado utilizando um servidor comum recentemente criado e adicionando a pilha Contoso padrão de ferramentas e utilitários de gerenciamento e, em seguida, executando o SCW nela. Por exemplo, depois da instalação básica do Windows ser concluída, a Contoso instalará (manualmente ou por meio do arquivo cmdlines.txt) suas ferramentas padrão de antivírus, backup, gerenciamento e monitoramento no servidor. Como cada uma dessas ferramentas provavelmente crie seus próprios serviços do Windows, tê-las no servidor antes de criar a diretiva de linha de base permite que o SCW esteja ciente de sua presença durante a fase de bloqueio do serviço.
Assim que o servidor for compilado, a Contoso executará o SCW nele. O SCW pode ser executado de forma local ou remotamente e quem estiver executando deve ser um membro do grupo de administradores locais da máquina. Se o SCW estiver sendo executado remotamente, ele fornecerá uma opção para especificar a conta do usuário a ser executada no host remoto; se estiver sendo executado localmente, você pode usar o runas.exe para realizar a mesma coisa. A primeira tarefa realizada pelo SCW é avaliar esses serviços em execução na máquina local e exibir quais funções estão atualmente instaladas (consulte a Figura 5).
Figura 5 Selecionar e visualizar as funções de servidor
Figura 5 Selecionar e visualizar as funções de servidor (Clique na imagem para diminuir a exibição)
Figura 5 Selecionar e visualizar as funções de servidor
Figura 5 Selecionar e visualizar as funções de servidor (Clique na imagem para aumentar a exibição)
Nenhuma função deve ser selecionada no servidor da linha de base da Contoso, pois a máquina foi desenvolvida para estar em um estado extremamente restrito. Depois que as funções que o servidor executa forem selecionadas, a próxima etapa é identificar os recursos de cliente necessários, a fim de habilitar a funcionalidade, como atualizações automáticas, Active Directory ou cliente FTP. Para a maioria das empresas, aceitar o padrão do SCW (como ilustrado na Figura 6) fornece importante funcionalidade (como a capacidade de participar de um domínio), ao mesmo tempo proibindo recursos menos críticos (como o cliente FTP).
Figura 6 Recursos instalados
Figura 6 Recursos instalados (Clique na imagem para diminuir a exibição)
Figura 6 Recursos instalados
Figura 6 Recursos instalados (Clique na imagem para aumentar a exibição)
O SCW continua, possibilitando que você selecione quais ferramentas administrativas específicas e serviços não padrão permitir. Esses opções de serviços não padrão são o motivo pelo qual você executa o SCW depois da instalação da pilha de gerenciamento do servidor Contoso padrão. Quando os aplicativos de antivírus, backup e outros relacionados estiverem instalados, o SCW poderá então ter conhecimento desses serviços e, portanto, incluí-los em suas configurações resultantes de diretiva.
A última questão na seção de proteção do serviço é como lidar com serviços não especificados. Esses são os serviços que podem ser encontrados em outros computadores nos quais a diretiva do SCW é aplicado, mesmo quando eles não estiverem sendo executados na máquina na qual a diretiva foi originalmente criada. Por exemplo, se a diretiva da linha de base for aplicada a um novo servidor com alguns aplicativos novos de terceiros, quaisquer serviços instalados por esse aplicativo serão tratados de acordo com a opção feita pelo administrador nesse ponto. O SCW permite que o administrador não altere o modo de inicialização do serviço ou o desabilite. Desabilitar é a opção mais segura, mas deve ser utilizada com cuidado, pois todos os serviços não permitidos explicitamente para execução serão impedidos de serem executados posteriormente. Por esse motivo, essa opção é a mais adequada para ambientes de alta segurança e bem gerenciados. Para outras partes de uma empresa, recomenda-se a opção de não alterar o modo de inicialização. Portanto, no exemplo da Contoso, essa foi a opção escolhida. Antes de concluir a parte de proteção do serviço de suas tarefas, o SCW apresenta ao administrador um relatório sobre quais serviços serão alterados.
Depois de concluir a proteção do serviço, o SCW fornece opções para limitar o acesso de rede de entrada. Como com a lista de serviços necessários para determinada função, a lista de partes necessárias para determinada carga de trabalho é incluída no banco de dados XML do SCW.
Os administradores podem configurar partes adicionais conforme a necessidade, bem como efetuar regras de porta por serviço, como mostrado na Figura 7. Para o servidor da linha de base da Contoso, somente os serviços mais básicos, como Área de trabalho remota, devem ser permitidos. Todas as outras exceções serão configuradas nas diretivas com base em função inferiores na hierarquia da unidade organizacional.
Figura 7 Visualizar e permitir portas
Figura 7 Visualizar e permitir portas (Clique na imagem para diminuir a exibição)
Figura 7 Visualizar e permitir portas
Figura 7 Visualizar e permitir portas (Clique na imagem para aumentar a exibição)
O SCW permite então que o administrador selecione as opções de Registro, como assinar um arquivo e tráfego de impressão. Novamente, na configuração da linha de base, a escolha dos padrões mais seguros é recomendada como a melhor prática.
O próximo conjunto de opções envolve a diretiva de auditoria do sistema. Na maioria dos sistemas, selecionar a opção Auditoria de atividades bem-sucedidas é a melhor; a auditoria de todas as atividades exige mais do processador e gera uma quantidade significativa de dados no log de auditoria. Quando houver suspeita de ataque ou for necessária uma análise mais detalhada, a auditoria de falhas pode ser habilitada na máquina específica.
Finalmente, o SCW apresentará ao administrador opções para proteção de IIS. Essas opções são semelhantes àquelas disponíveis na ferramenta de bloqueio de IIS e agora estão integradas diretamente na diretiva do SCW.
Depois da conclusão de todas as etapas, o SCW solicita que o administrador salve o arquivo XML. O arquivo salvo deve ser convertido para um formato que seja compreendido nativamente pela Diretiva de grupo. O Scwcmd.exe é utilizado para transformar o arquivo XML salvo em um GPO. Este é o comando a ser inserido:
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
Essa diretiva será automaticamente criada no Active Directory e pode ser anexada à parte superior da hierarquia da unidade organizacional de proteção com base em funções da Contoso.
Assim que essa diretiva for aplicada ao nível superior da hierarquia, as máquinas adicionadas à hierarquia da unidade organizacional herdarão as suas configurações. Quando uma máquina adicionada exigir modificações nessa diretiva (como um servidor IIS que requeira que o serviço W3SVC esteja em execução), os administradores da Contoso executarão novamente o SCW para essa nova função do servidor, transformarão essa nova política em um GPO e anexarão esse GPO à nova subunidade organizacional contendo o(s) servidor(es). Como o GPO mais próximo do servidor terá precedência, o resultado final será que todas as configurações da linha de base estarão posicionadas, exceto aquelas que requeiram modificações para habilitar a funcionalidade de função desejada para essa unidade organizacional (consulte a Figura 8).
Figura 8 Aplicativo de diretiva na Contoso
Figura 8 Aplicativo de diretiva na Contoso (Clique na imagem para diminuir a exibição)
Figura 8 Aplicativo de diretiva na Contoso
Figura 8 Aplicativo de diretiva na Contoso (Clique na imagem para aumentar a exibição)
O verdadeiro poder dessa abordagem fica claro em grandes empresas ou quando muitos servidores estão sendo implantados. Assim que a diretiva de SCW inicial for criada e anexada a uma unidade organizacional, os servidores subseqüentes simplesmente precisam ser adicionados a essa unidade organizacional e herdam automaticamente a diretiva de segurança apropriada. Dessa forma, assim que o conjunto inicial de diretivas for criado e adicionado ao Active Directory, a implantação de novos servidores ou a substituição dos existentes se torna um processo simples e rápido.

Olhando para o futuro
Na próxima versão do Windows Server "Longhorn", a Microsoft dividiu extremamente os componentes do sistema operacional, resultando em uma superfície pronta dinamizada e limitada em relação a ataques. Em vez de se focalizar no bloqueio da instalação mínima padrão, os administradores utilizarão a ferramenta Server Manager para adicionar essas funções e cargas de trabalho necessárias em cada servidor. O Server Manager funciona de forma muito semelhante ao SCW no que diz respeito ao fato de ter um banco de dados interno de dependências, o qual permite que o instalador adicione somente essas partes de funcionalidade necessárias para fornecer o serviço de função desejado. Além disso, a segurança com base em funções gerenciada centralmente usando a Diretiva de grupo, como discutido neste artigo, é aprimorada ainda mais pelo conjunto extremamente ampliado de recursos controlados por GPO. Resumindo, o Windows Server "Longhorn" eleva o conceito do SCW com flexibilidade aumentada e uma postura pronta ainda mais forte de segurança.
Recursos SCW
As seguintes páginas da Web o ajudarão a começar a usar o SCW:
  • Documentação do Assistente de configuração de segurança
  • Assistente de configuração de segurança do Windows Server 2003
  • Windows Server "Longhorn"

John Morello graduou-se 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 sênior de programa do grupo Windows Server e trabalha em segurança e tecnologias de acesso remoto.


 Os arquivos da &#225;rea de trabalho: When I’m x64
Os arquivos da área de trabalho
When I’m x64
Wes Miller

Há mais de cinco anos, o Windows XP tem sido disponibilizado no modo nativo para arquiteturas de 64 bits. Entretanto, a menos que você tenha sido um dos pioneiros no uso do processador Intel Itanium (o Windows XP para Itanium lançado no mesmo dia que o Windows XP), você já deve ter ouvido falar, mais recentemente, da disponibilidade dessa arquitetura no Windows XP e nas versões do Windows
Server 2003 para sistemas x64. O x64 – também chamado no setor de x86-64 – é o nome genérico para as arquiteturas AMD64 (AMD) e EM64T (Intel). Além disso, se você tiver adquirido um novo computador no ano passado ou não muito antes disso, há uma boa chance de que ele esteja equipado com a arquitetura de 64 bits, mesmo se estiver em um ambiente de 32 bits (o que é mais provável).
Atualmente, trabalho em uma pequena empresa de desenvolvimento em Austin, Texas. Devido à arquitetura de um de nossos produtos, estamos interessados em aproveitar alguns benefícios muito específicos da arquitetura x64 – muito semelhante à equipe do Microsoft® Exchange 2007, que se estabeleceu e começou a fornecer exclusivamente a arquitetura x64. Da mesma forma, a equipe de desenvolvimento e teste que gerencio executa implantações exclusivamente em versões x64 do Windows® XP e do Windows Server® 2003 para estações de trabalho de desenvolvimento, laptops, servidores e servidores de produção. Além disso, executo o Windows XP Professional x64 Edition no meu laptop pessoal para testar e depurar o nosso produto.
Curiosamente, a primeira resposta que recebo da maioria das pessoas quando menciono execução da versão de 64 bits do Windows – especialmente em um sistema móvel – é um olhar de estranheza. E quando estão familiarizadas com a computação de 64 bits, a reação é de descrença, relutância e espanto – devido à premissa comumente assumida de que é difícil agrupar drivers de dispositivo em sistemas de 64 bits. Na coluna deste mês, explicarei como e por que utilizo o Windows XP e o Windows Server 2003 em sistemas x64 no modo de 64 bits; além disso, descreverei alguns dos benefícios (e obstáculos) da implantação que você poderá ter. Também apresentarei alguns aspectos do suporte, da migração e da implantação do Windows Vista™ x64.

Um breve histórico
Como mencionado anteriormente, a origem do suporte a 64 bits no Windows realmente iniciou com o suporte ao processador Intel Itanium. (Embora o Windows estivesse disponível para o processador Alpha de 64 bits, o Windows nunca foi, de fato, de 64 bits quando executado no Alpha.) Não é oferecido suporte para o Itanium no Windows XP e no Windows Vista, de forma que a arquitetura de x64 atualmente é conduzida pela computação cliente do Windows de 64 bits. Uma ampla seleção de edições do Windows Server 2003 está atualmente disponível para x64, além do Itanium (o qual foi, essencialmente, relegado às cargas de trabalho de datacenter de ultra high-end) – uma tendência que espero que continue no lançamento da próxima versão do Windows Server, cujo codinome é “Longhorn”.
O suporte para o Windows na plataforma x64 foi disponibilizado no lançamento do Windows Server 2003 Service Pack 1 (SP1). Embora isso possa parecer um pouco confuso, também aconteceu quando a versão x64 do Windows XP foi disponibilizada – o que significa que os produtos de 32 bits e 64 bits do Windows XP são derivados de diferentes árvores de códigos no Windows. Embora os produtos de 32 bits atualmente tenham um segundo service pack disponível, a versão de 64 bits do Windows XP tecnicamente não possui qualquer nível de service pack (ou seja, você poderia considerá-la como tendo o SP1 para Windows Server 2003 já integrado).
Para executar a versão de 64 bits do Windows – o Windows XP, o Windows Server 2003, o Windows Vista ou o Windows Server “Longhorn” – os requisitos são, na verdade, os mesmos. Obviamente, primeiro você precisa ter um processador com capacidade para 64 bits. No caso da AMD, isso significa obter um sistema de um, dois ou quatro núcleos que aproveite a compatibilidade AMD64 (consulte http://www.amd.com/br-pt/Processors/ProductInformation/0,,30_118,00.html). Para a Intel, isso significa obter um sistema de um, dois ou quatro núcleos que aproveite o suporte EM64T ou a Arquitetura Intel 64 (acesse intel.com/technology/intel64). Observe que os detalhes são a parte maçante. Um sistema Intel Core Duo, por exemplo, não tem capacidade para 64 bits. Um sistema Intel Core 2 Duo tem capacidade para 64 bits – mesmo se for chamado de simplesmente Centrino Duo (como no caso do meu laptop).

Trabalhando com x64
Assim que tiver definido se o seu sistema oferecerá suporte no modo nativo a uma versão de 64 bits do Windows, você precisará lidar com o suporte do dispositivo. Infelizmente, por mais que a Microsoft tenha incentivado fornecedores e OEMs (por meio de, pelo menos, dois anos de sessões de WinHEC) para que criassem e certificassem drivers de 64 bits para seus dispositivos e sistemas, o maior desafio que você enfrentará ao usar o Windows x64 será encontrar drivers para dispositivos de hardware ou para software. Com base na minha experiência, você terá mais êxito se executar o x64 em um servidor, no qual o suporte necessário ao dispositivo é limitado; além disso, o benefício do x64 é mais lógico.
É muito difícil encontrar drivers para sistemas móveis e de desktop. Em geral, você terá mais sorte com um renomado provedor OEM ou com um sistema baseado em componentes de classe empresarial (em que a probabilidade de uso comercial fará com que o fornecedor ou OEM crie e ofereça drivers com capacidade x64).
Para o Windows Vista, felizmente essa situação é muito melhor. Em vez de um ambiente em que x86 é a arquitetura preferida e x64 é a arquitetura ignorada, devido à disponibilidade limitada de drivers para a maioria de hardware, ocorre o oposto. Para o Windows Vista, um fornecedor de dispositivos deve submeter os drivers x64 a testes de compatibilidade. Na verdade, os drivers x86 não precisam ser incluídos, mas certamente podem ser, se for o caso. Conceitualmente, isso significa que determinado hardware – especialmente os dispositivos que aproveitam os recursos do novo Windows Vista – pode, na verdade, ter suporte somente para o x64 Windows, e não para x86.
A realidade é que os drivers são apenas um dos problemas que você enfrentará ao tentar executar a versão de 64 bits do Windows no modo nativo. O problema maior é chegar lá (ou migrar) para iniciar, mas abordaremos isso posteriormente.

Por que 64 bits?
É claro que a AMD, a Intel e a Microsoft não migraram para a arquitetura de 64 bits somente por diversão. A migração para 64 bits oferece vários benefícios importantes. Como você pode observar na Figura 1, o aprimoramento mais importante oferecido pela arquitetura x64 é atender significativamente a uma maior capacidade de memória – até 16 terabytes (TB) versus 4 GB, que é a capacidade atendida pela versão de 32 bits do Windows. Observe que apesar de os indicadores de 63 bits atenderem a esse limite de 16 TB, eles têm acesso a apenas aproximadamente 8 TB.
Figure 1 Limites de espaço de endereço na memória (Close Figure 1)

Espaço de endereço | Windows 64 bits | Windows 32 bits
Memória virtual | 16 TB | 4 GB
Arquivo de paginação | 512 TB | 16 TB
Reserva de memória paginável | 128 GB | 470 MB
Reserva de memória não paginável | 128 GB | 256 MB
Cache do sistema | 1 TB | 1 GB
Além disso, as versões x64 do Windows fornecem prevenção de execução de dados (DEP) baseada em hardware – também disponível nos sistemas x86 com suporte NX (No Execute, não executar). Isso permite que uma solução acionada por hardware utilizada pelo Windows impeça estouros de buffer. Ela impede a execução de código a partir das páginas de dados na memória – consulte support.microsoft.com/kb/875352 para obter mais informações sobre esse tópico.
As versões x64 do Windows permitem o suporte nativo de CPUs com vários processadores ou núcleos, exatamente como as versões do Windows o fazem. Porém, uma das maiores complexidades da geração de imagens de um sistema Windows XP é eliminada pelo uso de uma única camada de abstração do hardware (HAL) em todas as instalações do Windows x64 – é o fim da dificuldade para identificar a HAL em uso em sistemas sem ACPI ou com uma única CPU.
Basicamente, como uma arquitetura, o Windows x64 permite que você use a sua infra-estrutura de gerenciamento e o software de 32 bits existentes (por meio de emulação), além do software de 64 bits com a capacidade de acesso a essa memória significativamente aprimorada. Na verdade, os únicos efeitos colaterais desagradáveis de migrar para o Windows x64 são: a total falta de suporte para aplicativos de 16 bits (inclusive “pegadinhas” como aplicativos de 32 bits com instaladores de 16 bits); problemas com aplicativos que não são executados de modo confiável quando a DEP baseada em hardware estiver habilitada (embora a DEP possa ser desabilitada por processo, e a equipe de Compatibilidade de aplicativos Windows corrija alguns aplicativos que não são executados corretamente com a DEP habilitada); e, finalmente, o fato de que na versão de 64 bits do Windows Vista, todos os drivers devem ser assinados digitalmente.
Esse último item foi acrescentado para ajudar a impedir violação com o kernel do Windows na memória, uma técnica freqüentemente utilizada por rootkits. A expectativa é que, como a x64 é a arquitetura para a qual a Microsoft está incentivando os fornecedores a desenvolverem drivers como prioridade (a fim de obter drivers por meio dos testes de qualidade de hardware do Windows), isso não é tão assustador para uma exigência, como poderia ser historicamente.
Há alguns outros pontos a serem observados ao se considerar o Windows para sistemas x64. Não há versões do Windows XP para sistemas x64 que tenham a funcionalidade incluída no Windows Media® Center Edition ou no Windows Tablet PC Edition. No entanto, isso será alterado no Windows Vista, no qual as versões x64 do Windows têm a mesma funcionalidade que as versões x86.

Virtualização
Um item que não mencionei é a virtualização. Não estou me referindo aos produtos de virtualização Microsoft Virtual PC ou VMWare PC; estou falando sobre a virtualização de sistema operacional para executáveis de 32 bits. Nas versões de 32 bits do Windows, os aplicativos de 16 bits são todos executados no contexto de NTVDM – uma máquina virtual MS-DOS®. Como mencionado anteriormente, não é oferecido suporte para aplicativos de 16 bits nas versões de 64 bits do Windows. Em vez disso, embora a maioria dos componentes integrados do Windows sejam executados no modo nativo como binários de 64 bits, alguns componentes e vários programas de terceiros são executados como aplicativos de 32 bits.
O Windows oferece uma camada de emulação totalmente nova, denominada Windows On Windows (WOW), a qual permite que esses aplicativos de 32 bits tenham uma exibição diferente do sistema operacional – na verdade, serão executados em uma versão de 32 bits do Windows. Na WOW, os aplicativos x86 exibem os Arquivos de Programas (X86) simplesmente como Arquivos de Programas. Do mesmo modo, o %WINDIR%\SysWOW64 aparece para aplicativos x86 como %WINDIR%\System32. Os aplicativos x86 exibem a chave do Registro HKLM\SOFTWARE\Wow6432Node como eles a exibiriam no próprio nó HKLM\SOFTWARE.
Ao usar a ferramenta Process Explorer, você pode espreitar outra perspectiva da virtualização. Como é esperado que muitos aplicativos de 32 bits interajam com binários integrados de 32 bits do Windows, vários desses binários são fornecidos em versões de 64 e 32 bits. Ao adicionar uma coluna extra ao Process Explorer, você pode facilmente visualizar isso. Na Figura 2, você observará duas instâncias de cmd.exe – uma versão de 32 bits e outra de 64 bits. Observe que na instância selecionada de 32 bits, você verá várias DLLs wow64* carregadas no processo de 32 bits. Essas DLLs mostram a execução da virtualização, a qual permite que aplicativos de 32 bits funcionem na versão de 64 bits do Windows. Além disso, observe que o diretório de trabalho (Caminho) está sendo utilizado pelas versões de 64 e 32 bits do cmd.exe.
Figura 2 O Process Explorer revela as versões de 32 e 64 bits do cmd.exe
Figura 2 O Process Explorer revela as versões de 32 e 64 bits do cmd.exe (Clique na imagem para diminuir a exibição)
Figura 2 O Process Explorer revela as versões de 32 e 64 bits do cmd.exe
Figura 2 O Process Explorer revela as versões de 32 e 64 bits do cmd.exe (Clique na imagem para aumentar a exibição)
Uma última observação sobre o tópico de virtualização – apesar de o Windows executar o explorer.exe como um aplicativo nativo de 64 bits, isso apresenta alguns prós e contras. O maior contra é que qualquer extensão do shell do Explorer deve ser recompilada para x64 para que funcione (a maioria não tem isso).
O oposto ocorre no Internet Explorer® – como padrão, ele é executado no modo nativo com a versão de 32 bits. Isso é feito principalmente para que a abundância de controles ActiveX® na Internet já em uso atualmente funcionem com êxito da forma como estão. Sem isso, como os aplicativos de 64 bits não podem carregar as DLLs de 32 bits ou drivers em processo, não há uma forma eficaz de carregar os controles ActiveX de 32 bits, o que compromete praticamente todos os controles ActiveX disponíveis no momento em um navegador de 32 bits – isso significa que uma parte considerável do conteúdo de Internet ficaria inacessível. Para visualizar isso na prática, tente carregar C:\Program Files\Internet Explorer\iexplore.exe em um sistema de 64 bits do Windows e acessar qualquer site que carregue conteúdo de controle ActiveX (até mesmo o Windows Update) – o resultado será variados graus de falha. O Windows Update (consulte a Figura 3) agora foi atualizado para abrir uma instância de 32 bits do Internet Explorer nessa situação. No futuro, certamente haverá algum conteúdo de controle ActiveX atualizado para aproveitar a versão de 64 bits do Internet Explorer. No entanto, como no momento a maioria dos sistemas Windows são executados puramente na versão de 32 bits do Windows, a necessidade de que o conteúdo de controle ActiveX seja atualizado não é fundamental. Essa mudança deverá demorar ainda um longo período para ser implementada.
Figura 3 Os controles de 32 bits do ActiveX falham na versão de 64 bits do Internet Explorer
Figura 3 Os controles de 32 bits do ActiveX falham na versão de 64 bits do Internet Explorer (Clique na imagem para diminuir a exibição)
Figura 3 Os controles de 32 bits do ActiveX falham na versão de 64 bits do Internet Explorer
Figura 3 Os controles de 32 bits do ActiveX falham na versão de 64 bits do Internet Explorer (Clique na imagem para aumentar a exibição)

x64 Windows na Pluck
Mencionei no início deste artigo que iniciamos a transição para o x64 Windows na Pluck. Efetuamos isso com três diferentes versões do Windows: Windows XP Professional x64 Edition, Windows Server 2003 Enterprise Edition x64 e Windows Vista x64.
A nossa empresa é pequena o suficiente, de forma que quando começamos a desenvolver o nosso produto mais recente, foi possível iniciar a migração para o Windows para x64, a fim de aproveitar os seus benefícios. Fazer isso significava garantir que todo o novo hardware solicitado tivesse capacidade para x64. Na verdade, são os recursos de memória expandida do x64, em combinação com a virtualização, que nos permitem executar o nosso produto da forma como fizemos. Todos os nossos servidores físicos são executados como servidores virtuais de 64 bits em um servidor host de 64 bits. Cada servidor host possui 16 GB de RAM, divididos entre os servidores virtuais hospedados nele (geralmente 2 GB para cada máquina virtual de teste ou VM, e 3 GB para cada VM de produção).
Ao usar sistemas de camada 1 e hardware virtualizado, conseguimos atingir praticamente 100% de suporte para o dispositivo. O meu laptop, por exemplo, possui três dispositivos que não têm drivers x64 disponíveis. Todos esses parecem ser dispositivos do tipo backplane, os quais não são fundamentais, e o sistema é executado normalmente sem a sua presença. O mais interessante é que uma instalação do Windows Vista RC1 x64 resultou exatamente no suporte para o mesmo dispositivo, embora o meu sistema tenha o logotipo Windows Vista Capable; certamente esses drivers faltando serão fornecidos em breve pelo fornecedor.
Como o nosso uso dos sistemas é basicamente restrito ao Microsoft Office, Visual Studio® e várias ferramentas adicionais utilizadas em nosso processo de desenvolvimento e criação, nós temos muitos aplicativos herdados que causaram problemas de compatibilidade na nossa migração. Apesar de uma considerável parte da nossa empresa utilizar versões de 32 bits do Windows, iniciamos a migração para 64 bits com o novo hardware e foi tudo relativamente tranqüilo.

Implantação e migração de x64
Há algumas considerações que se fazem necessárias em relação à implantação. A Microsoft fornece uma versão do Windows Pre-installation Environment (Windows PE) especificamente para a arquitetura x64. No entanto, como há paridade x86 nos sistemas x64, talvez você queira usar o Windows PE x86 na implantação – especialmente se estiver usando uma solução de geração de imagens. Se você estiver implantando o Windows XP usando uma instalação autônoma, o Windows PE precisará ser específico para a arquitetura – já que o winnt32.exe precisa ser executado na mesma arquitetura de implantação. Como o Windows PE não apresenta uma camada de compatibilidade para 32 bits, e o winnt32.exe em x64 é um aplicativo de 64 bits, a versão de 32 bits do Windows requer o Windows PE de 32 bits. O mesmo se aplica para as versões de 64 bits do Windows, as quais requerem o Windows PE de 64 bits.
Os Serviços de Instalação Remota (RIS) são diferentes nesse aspecto; por isso, utilizamos o RIS na Pluck. O RIS, começando com o Windows Server 2003 SP1, pode implantar as arquiteturas x64 e o x86 ou Itanium do Windows. Quando um sistema x64 se conectar a um servidor RIS, o servidor (na configuração padrão) oferecerá imagens RISetup x86 e x64 ou RIPrep. O RIS pode ser configurado para oferecer também aos clientes x64 imagens exclusivamente de x86 ou x64. A opção foi oferecida como padrão, a fim de fornecer a melhor experiência com o hardware x64.
Observe que eu não mencionei ainda a atualização. Há um bom motivo para isso. Infelizmente, a atualização de todo um sistema operacional de x86 para x64 é uma tarefa maciça. Por esse motivo – e devido à implantação limitada do Windows XP Pro x64 Edition – não é possível atualizar para o Windows XP x64 de qualquer versão x86, nem de qualquer versão do Windows XP (x86 ou x64) para o Windows Vista x64. O Windows Vista nos sistemas x64 é, como o Windows XP Pro x64 Edition anterior a ele, um produto somente para instalação limpa. Por esse motivo, muitas empresas consideram a migração para x64 somente quando uma atualização de hardware estiver envolvida – uma estratégia semelhante que várias empresas podem precisar realizar com o próprio Windows Vista (tornando a execução de duas tarefas ao mesmo tempo potencialmente uma execução lógica).
Mas isso não significa que os usuários ou empresas migrando do x86 Windows para o x64 Windows não tenham ferramentas prontamente disponíveis – eles certamente as possuem. As versões da Ferramenta de migração de perfil do usuário (USMT) para o Windows XP e para o Windows Vista foram ampliadas para oferecer suporte à migração (versus uma atualização em banda do sistema operacional) de uma instalação do Windows para outra. Atualmente, esse é o método predominante na maioria das empresas que implantam o Windows independentemente – limpeza e recarregamento, inclusive no mesmo computador –, de forma que o fato de utilizarem o mesmo mecanismo para migrar para o Windows em uma arquitetura totalmente nova não será um obstáculo tão difícil como antes.

Conclusão
Embora a migração gradual de nossa pequena empresa para o x64 possa ser consideravelmente mais fácil do que o amplo processo de migração enfrentado por grandes empresas, cada profissional de TI deve começar a considerar uma possível migração para a arquitetura x64. A realidade é que, embora a arquitetura x86 e as versões nativas x86 do Windows ainda estarão presentes na próxima década, a arquitetura x64 certamente será o futuro da computação empresarial. Com a Microsoft migrando totalmente para recursos x64 com o Exchange Server e outros produtos, você deve começar a analisar onde os sistemas x64 se encaixarão primeiramente na sua arquitetura, bem como onde eles serão adequados para o seu plano de migração para o Windows Vista, independentemente de você estar utilizando, no momento, o Windows XP ou o Windows Server 2003 no modo nativo nos seus sistemas x64.

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


 Por dentro da Microsoft.com: Usando os Servi&#231;os de Federa&#231;&#227;o do Active Directory
Por dentro da Microsoft.com
Usando os Serviços de Federação do Active Directory
Jim Guthrie

Na Microsoft, fornecemos uma extranet para proporcionar acesso aos parceiros comerciais a importantes recursos internos. A arquitetura da extranet requer que cada participante fora da organização tenha um conta de domínio exclusiva para esse espaço. Essa conta é criada e gerenciada pelos funcionários da Microsoft, e não pelos
parceiros, por motivos óbvios. No entanto, enquanto funcional, a experiência para o usuário pode ser menos satisfatória, e a carga na Microsoft para gerenciar todos esses usuários parceiros de certa forma faz uso intensivo de recursos.
Veja agora como funciona a extranet. Quando um cliente ou parceiro acessa um aplicativo, ele precisa inserir as suas credenciais. Durante a mesma sessão, se o usuário decidir acessar um recurso diferente, ele será solicitado novamente a inserir as suas credenciais. Isso continuará sempre que ele passar de um recurso para outro. Se o usuário tiver acessado um único aplicativo que usa vários recursos, como um banco de dados financeiro, ele precisaria autenticar cada recurso de forma independente. Isso pode ser uma experiência desgastante e complicada para os usuários.
Felizmente, ao usar os Serviços de Federação do Active Directory®, conseguimos solucionar o problema de várias autenticações com facilidade e isso se refletirá no seu uso. O ADFS é um componente do Windows Server® 2003 R2 que facilita a confiança entre duas ou mais empresas, a fim de permitir o compartilhamento de vários recursos e mantendo ao mesmo tempo a capacidade da empresa de gerenciar seu próprio conjunto de usuários. Nesta coluna, ilustrarei como a Microsoft pretende usar o ADFS para solucionar esse problema de extranet de vários recursos, o que lhe fornecerá mais informações necessárias para implementar uma solução semelhante. No entanto, antes de entrarmos em detalhes, veja a Figura 1 para se familiarizar com a terminologia básica do ADFS.
Figure 1 Terminologia do ADFS (Close Figure 1)

Termo | Definição
Federação | Um par de territórios ou domínios com uma confiança de federação do Active Directory.
Federation Service Resource (FS-R) | Efetua o roteamento de solicitação de autenticações de entrada para os recursos desejados e FS-A.
Federation Service Accounts (FS-A) | Fornece um token de conta a ser autenticado no FS-R.
Federation Service Proxy (FS-P) | Fornece uma camada de separação para os servidores FS a partir de tráfego de entrada da Internet.
Declaração | Uma instrução que o servidor faz (por exemplo, nome, identidade, chave, grupo, privilégio ou recursos) sobre um cliente.
Descoberta de território | Cada FS-A tem um domínio ou território, no qual as credenciais de logon são armazenadas. A descoberta de território define qual FS-A é utilizado para a sessão ADFS.

Uma solução ADFS
Quando um usuário tenta acessar um aplicativo com conhecimento de ADFS, o navegador é enviado para o Recurso do Serviço de Federação (FS-R, Federation Service Resource) para descoberta de território. Aqui o usuário selecionará qual conjunto de credenciais utilizará para a duração da sessão. Com base na descoberta do cliente escolhido, o usuário será redirecionado para o servidor das Contas do Serviço de Federação (FS-A, Federation Service Accounts). É nesse servidor que o usuário receberá um token de conta válido (em um cookie) que está baseado nas credenciais que ele inserir no formulário de um Windows Live™ ID (anteriormente, uma conta Passport), a autenticação integrada do Windows ou autenticação SSL (consulte a Figura 2). Nesse modelo, fica a cargo das empresas individuais manter o seu próprio servidor de federação de conta. No caso dos servidores parceiros da Microsoft, a carga no Microsoft.com é removida para gerenciar cada conta no ambiente. É claro que se você implementar esse nível de responsabilidade, será necessário selecionar cuidadosamente as empresas com as quais você será federado e garantir que elas estejam gerenciando ativamente as informações da conta.
Figura 2 Fluxo de ADFS
Figura 2 Fluxo de ADFS (Clique na imagem para diminuir a exibição)
Figura 2 Fluxo de ADFS
Figura 2 Fluxo de ADFS (Clique na imagem para aumentar a exibição)
A próxima interrupção na rota é voltar para o servidor FS-R para alterar o token da conta para um token de recurso. Em nossa configuração, esse token contém uma lista completa de permissões das concessões do usuário por meio de um processo de mapeamento de declarações realizado no FS-R. Assim que o token for recebido, o usuário terá o recurso de logon único nos aplicativos com ADFS pelo tempo em que a sessão estiver aberta ou até 24 horas por padrão (essa janela é configurável). O resultado é que você terá SSO habilitado para esses aplicativos com ADFS, resultando em uma experiência mais protegida e eficiente para o cliente. Para obter uma orientação completa do processo de autenticação ADFS, consulte o artigo de Matt Steele, da edição de julho de 2006 da TechNet Magazine intitulado “Simplifique o logon único usando ADFS”.
Para manter a segurança dos recursos corporativos da Microsoft, isolamos o lado em contato com a internet da extranet do lado corporativo, o que significa que cada servidor é potencialmente de hospedagem dupla. Permitimos uma confiança unilateral aos usuários internos corporativos e utilizamos os servidores para fornecer a proteção necessária. Além disso, temos um domínio separado para o espaço da extranet, no qual fornecemos acesso aos recursos necessários para os usuários externos.
Duas áreas de maior preocupação durante a implementação foram as alterações no arquivo de diretiva do ADFS e balanceamento de carga. O balanceamento de carga foi um desafio em nível global e local. Inicialmente na produção utilizaremos o balanceamento de carga global a partir dos nossos parceiros CDN (Content Delivery Network, rede de fornecimento de conteúdo) Akamai ou Savvis para os agrupamentos de servidor front-end da Web em duas regiões. Isso garantirá disponibilidade do sistema para os usuários finais mesmo na improvável hipótese de um par de servidores regionais ficar offline. Isso é realizado com a automação de failover baseada nos serviços de verificação de integridade do servidor fornecidos pelos CDNs. Além disso, temos o recurso de adicionar facilmente mais agrupamentos no futuro. Como uma economia de custos, as nossas implantações pré-produção foram escolhidas para não usar o serviço CDN.
No nível regional emparelhamos os servidores para failover local por meio do agrupamento de balanceamento de carga de rede (NLB, network load balancing). Não estamos usando recursos especiais de balanceamento de carga, de forma que isso poderia facilmente ser realizado com hardware; no entanto, novamente estamos usando a NLB para economia de custo. Essa configuração fornecerá a estabilidade para garantir que mais de 99,9% de duração em todos os ambientes compatíveis.
Outro desafio que enfrentamos foi garantir que o arquivo de diretiva ADFS, o backbone do ADFS, fosse corretamente distribuído em todo o nosso ambiente e que as alterações a ele também fossem replicadas. Para realizar isso, aproveitamos outro recurso interno do Windows Server 2003 R2 – DFS-R (Distributed File System-Replication, replicação do sistema de arquivos distribuído), um novo mecanismo de replicação multimestre baseado em estado. Em cada um dos servidores de back-end habilitamos uma associação de grupo DFS-R com uma replicação de malha completa, de 24 horas. Agora, não importa onde ocorrer a alteração no arquivo de diretiva, ele será distribuído a todos os servidores. À medida que controlamos como podemos alterar o arquivo, temos um serviço estável e extremamente disponível.
Tentamos garantir que todas as alterações fossem feitas no snap-in do ADFS. No entanto, na prática detectamos que devemos atualizar esse arquivo de forma manual ocasionalmente. Quando atualizar manualmente é importante lembrar que o ADFS controla a versão desse arquivo. Por isso, você deve incrementar o arquivo de forma que as alterações sejam refletidas no ambiente:
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
Você também precisa se lembrar que, como todo XML, os arquivos de XML de diretiva diferenciam maiúsculas de minúsculas. Em todo o arquivo XML de diretiva há muitas referências a aplicativos ou outros servidores ADFS e em todos os casos eles devem ser copiados literalmente de servidor para servidor. Observe que os seguintes exemplos comuns em que o primeiro, RevocationCheckFlags, foi manualmente inserido e o segundo é uma URL de aplicativo confiável modificada da IU:
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
Para um nível adicional de segurança utilizamos outro componente de ADFS, o Proxy do Serviço Federado (FS-P, Federation Service Proxy), que garante que o FS-Rs permaneça uma camada removida do acesso direto de solicitações de entrada da Internet. Um modo exclusivo com o qual temos implementado proxies no Microsoft.com é por meio do uso de um único conjunto de proxies para hospedar vários ambientes ADFS em nossa área de pré-produção. Curiosamente, durante a adaptação inicial da tecnologia, detectamos que precisamos fazer uma simples modificação na chave do Registro para que isso ocorra. A chave está localizada no HKLM\Software\Microsoft\WebSSO. A simples alteração do valor do diretório inicial nessa chave permitirá que você use o proxy para vários ambientes. O padrão era:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
Para alternar ambientes, a chave seria mudada da seguinte forma:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
A criação de um arquivo em lote pode simplificar o gerenciamento desse processo. Infelizmente, a atual versão do snap-in MMC do ADFS não oferece suporte para alternar ambientes, pois há uma relação de um para um entre o proxy e o recurso ou o servidor de conta. Essa é a única forma de maximizar a utilização dos servidores de proxy. O resultado final é que isso é uma tremenda economia de custo, pois limita o número de servidores físicos necessários, independentemente de quantos ambientes diferentes você escolha hospedar.
A partir do ponto de vista da arquitetura, estamos executando o nosso ambiente de pré-produção com máquinas virtuais – outra medida de economia de custo. Isso elimina a necessidade de adquirir e acomodar seis servidores adicionais. Até o momento, não tivemos problemas de desempenho. No entanto, para atender à demanda significativamente aumentada no ambiente de produção, escolhemos usar as máquinas físicas de alto desempenho.

Não apenas para o Active Directory
Não somente o Microsoft.com está usando as contas do Active Directory para autenticação, mas também temos realizado com êxito a integração com as contas do Windows Live ID. Detectamos que ao usar o Windows Live ID (WLID) 4.5, podemos usar uma conta individual do Windows Live ID para delegar acesso aos recursos da Microsoft usando uma transformação de declaração personalizada. Isso é uma grande vitória para atingir a autenticação SSO, pois não precisamos mais de uma conta de domínio específica.

Desafios restantes
O maior desafio que estamos enfrentando agora é o gerenciamento do ADFS para compartilhar certificados de assinatura de token. Estamos utilizando certificados padrão que permanecem geralmente válidos por um ano antes de exigir renovação. No momento da renovação cada um dos servidores apropriados precisará ser atualizado, o que terá impacto significativo no FS-Rs. Embora seja parcialmente gerenciável com 15 ou 20 federações, a escala poderia ser imaginada como em torno de pelo menos centenas, e não milhares. Isso exigiria uma equipe em tempo integral para o gerenciamento de certificados SSL para um único ambiente. Temos várias equipes tentando descobrir os melhores métodos para automatizar essa solução mas ainda não definimos um curso de ação.
Outro desafio é que nem todos os aplicativos estão prontos para reconhecer o ADFS. Isso exigirá programação para que os sites aproveitem a oportunidade do ADFS. Estamos trabalhando junto com a equipe do Microsoft® Office SharePoint® Services para garantir que a próxima geração do SharePoint seja compatível com as necessidades de implementação do ADFS.

Conclusão
Há vários fatores a serem considerados ao se tomar a decisão de mudar para um modelo ADFS. Um é o número de recursos que os clientes acessarão. O processo de definir uma confiança federada entre as organizações pode ser uma tarefa trivial, mas exige tempo e esforço para gravar, revisar e executar as diretivas de acesso aceitáveis. Portanto, se você tiver somente um recurso, o qual será acessado pelos clientes, você precisará decidir se o esforço é válido. No entanto, como o número de recursos cresce, os benefícios também aumentam.
Se você estiver procurando por mais informações, consulte Visão geral do ADFS e Serviços de Federação do Active Directory: um caminho para o gerenciamento de acesso e identidade federada.

Jim Guthrie trabalha para a Microsoft na equipe de Operações do Microsoft.com Operations, na qual além de trabalhar com ADFS, ele é Engenheiro de sistemas com a equipe de Suporte à Plataforma de Portal Empresarial.


 Anota&#231;&#245;es de campo: As alegrias (e as dificuldades) do aprendizado
Anotações de campo
As alegrias (e as dificuldades) do aprendizado
Mark D. Scott

Eu me lembro de como costumava ser quando surgia algo novo – a emoção de ter em minhas mãos a mais recente tecnologia antes da maioria das pessoas, de explorar completamente o produto, aprender como ele funcionava e fazê-lo funcionar. Eu tive sucesso sendo um pioneiro, aquele que detinha o conhecimento, o assistente que os outros procuravam para obter o conhecimento secreto.
Mas, em algum momento durante essa trajetória, a alegria se ofuscou. Não estou certo do que aconteceu. Talvez eu tenha me perdido nas frustrações de tentar fazer com que aplicativos de missão crítica funcionassem às 3h da manhã. É possível que eu o tenha deixado no nível básico utilizando a documentação do produto, a qual eu possa ter interpretado incorretamente, pois o servidor de email corporativo se foi (como nos tempos em que um servidor era suficiente). Ou talvez eu esteja apenas envelhecendo e me tornando cético. Não importa. O fato é que já não é mais tão interessante trabalhar até altas horas da noite como era há uma década ou mais. Mas isso não quer dizer que seja perfeitamente natural parar de aprender. Eu tive essa idéia reforçada há algum tempo.
Recentemente, migrei para o Microsoft® Outlook® 2007 e gostei bastante dele. Mas também sou assinante do MSN® Premium; meu ISP fornece minha assinatura como parte de seu serviço. Na versão anterior do Outlook, para acessar o meu endereço de email do MSN, eu precisava de uma parte especial do software denominada conector. Esse conector do software não funcionava com o Outlook 2007; portanto, entrei em contato com a equipe do MSN. A equipe do MSN me aconselhou a conversar com o meu ISP, o qual me disse que – eventualmente – não oferecia suporte ao Outlook Connector para MSN no Outlook 2007. Ou seja, email, chat e voz – demorava uma eternidade para obter essas informações.
Então, pensei – talvez eu não precise mais de um conector. Iniciei o Outlook 2007 e configurei uma nova conexão para o MSN sem usar o software conector. O Outlook acessou a Internet, localizou o servidor e configurou a conta sem dificuldades. Fiz isso em várias das minhas outras contas POP3. Assim, obtive acesso ao meu email e conheci um excelente recurso novo do produto.
Agora, qual o significado de tudo isso? Se alguém do suporte tivesse se preocupado em explorar o novo produto, muito provavelmente teria me dito que eu não precisava do conector e teria nos poupado grande parte do tempo.
Sendo mais direto, se eu tivesse primeiramente explorado o produto, com certeza eu mesmo teria encontrado a solução. Mas em vez disso eu simplesmente queria que alguém me desse a resposta. E como ninguém usou seu tempo para explorar algo que, afinal de contas, era importante em nosso cotidiano, perdemos muito tempo do que se cada um de nós tivesse investigado e resolvido o problema por conta própria – que foi exatamente o que acabei fazendo de qualquer forma.
As alterações tecnológicas põem fim às nossas ousadias. Para atuarmos como profissionais de TI, precisamos nos manter livres de pressuposições. O conhecimento que mais batalhamos para obter é o conhecimento que a nova tecnologia inevitavelmente substituirá – pois substituí-lo é o que facilita o uso da tecnologia. Não podemos usar esse conhecimento “oculto” como a nossa margem competitiva para sempre. A margem real não está no acúmulo de fatos antigos sobre como a tecnologia funcionava, mas sim na capacidade de dominar novos conceitos e técnicas. Ao aprendermos continuamente, fazendo do aprendizado parte de nossa rotina, refinaremos essas habilidades. Com a ampla variedade de novos produtos sendo infinitamente lançados, o aprendizado deve continuar sendo uma filosofia de vida.
Portanto, se você precisar entrar em contato comigo, sinta-se à vontade para me enviar um email para a conta da Microsoft ou do MSN – agora, eu recebo emails das duas contas no Outlook 2007!

Mark D. Scott é um consultor sênior da Microsoft Consulting Services. Ele trabalha junto aos seus clientes para ajudá-los a projetar e criar aplicativos focalizados em dados e em larga escala. Você pode contatá-lo pelo e-mail granddaddy2002@msn.com ou mascott@microsoft.com.


 Segredos do Windows: O poder dos bugs
Segredos do Windows
O poder dos bugs
Raymond Chen

No Windows 95, você acessaria a página Solução de problemas e selecionaria Desabilitar confirmações síncronas de buffer. Mas você sabe o que essa caixa de seleção faria? Ou para que ela serve?
O comportamento normal da função Commit do MS-DOS® era liberar todos os dados não gravados de um determinado arquivo no disco e, em seguida, aguardar até que os dados fossem confirmados como gravados antes de retornar. Com a opção Desabilitar confirmações síncronas de buffer selecionada, a chamada retornaria imediatamente, em vez de aguardar que os dados fossem gravados. É claro que isso era uma violação da especificação funcional, a qual requer que a chamada não retorne até que os dados sejam gravados. Isso aumentou o risco daquilo que o artigo 139669 da Base de Dados de Conhecimento chama eufemisticamente de “problemas de integridade de arquivo”, pois faz com que o programa que emitiu a solicitação de liberação considere que os dados estavam protegidos no disco, quando não estavam.
Um programa de banco de dados pode usar a função Commit para estabelecer pontos nos quais o estado do arquivo no disco seja um acordo com aquilo que o programa espera que esteja no disco. Se o computador ficar sem energia durante uma atualização, o programa de banco de dados pode usar as informações registradas no último ponto de confirmação, a fim de estabelecer novamente a integridade do banco de dados. Se a função Commit for retornada imediatamente depois de ter sido concluída, esse ponto de verificação de integridade seria perdido. O resultado seria que o banco de dados ficaria corrompido.
Por que essa opção foi disponibilizada se as conseqüências são tão horríveis? O motivo: um bug no Windows® 3.11.
Figura 1 Habilitando o comportamento com bugs no Windows Server 2003
Figura 1 Habilitando o comportamento com bugs no Windows Server 2003 (Clique na imagem para diminuir a exibição)
Figura 1 Habilitando o comportamento com bugs no Windows Server 2003
Figura 1 Habilitando o comportamento com bugs no Windows Server 2003 (Clique na imagem para aumentar a exibição)
O Windows 3.11 introduziu o “acesso a arquivos de 32 bits”, o qual era uma implementação de 32 bits da interface de E/S de arquivo de baixo nível. No entanto, a implementação da função Commit continha um bug que efetivamente ignorava as solicitações para liberar buffers de arquivo. Se você utilizasse um programa que liberava seus buffers de arquivo e fosse executado no Windows 3.11, a chamada de liberação não tinha efeito. Conseqüentemente, se você ficasse sem energia justamente no momento errado, o banco de dados era corrompido.
O pessoal trabalhando no sistema de arquivos do Windows 95 solucionou esse bug, mas os novos relatórios começaram a ser filtrados. O programa de contas a pagar de determinado usuário também ficou muito lento. Então, o programa de banco de dados de outro usuário se comportou da mesma forma. O que estava acontecendo?
O que acabou acontecendo foi que esses programas estavam constantemente emitindo chamadas de liberação. Os programadores observaram que as chamadas de liberação eram realmente rápidas no Windows 3.11; assim, eles as distribuíram livremente em seus programas. Gravavam um byte e o liberavam. Gravavam uma cadeia de caracteres e a liberavam. Como as liberações eram muito rápidas, o aplicativo poderia confirmar os dados no disco depois de cada operação sem degradação notável de desempenho. Mas assim que o bug foi corrigido no Windows 95, esses programas começaram a ser executados muito lentamente, pois as chamadas de confirmação estavam, de repente, fazendo o trabalho real.
É claro que se a equipe do sistema de arquivos não tivesse tomado qualquer medida, esses programas continuariam sendo executados lentamente e os usuários chegariam à conclusão de que o Windows 95 era o problema. “O Windows 95 parece uma carroça”, eles diriam uns aos outros. Por outro lado, se o sistema de arquivos retornasse para o comportamento anterior do Windows 3.11, estaria sendo reintroduzido um bug, o qual poderia causar esses irritantes “problemas de integridade de arquivos”.
Portanto, eles concluíram que a solução era deixar o bug corrigido, mas acrescentar uma caixa de seleção – apesar de escondida na página de solução de problemas – a fim de retornar ao comportamento do Windows 3.11. Essa caixa seria destinada aos usuários que durante a execução dos programas encontrassem problemas devido à correção do bug.
O que aconteceu foi que a história acabou se repetindo. No Windows Server® 2003, a equipe de E/S detectou um bug no qual as solicitações marcadas como FUA (Forced Unit Access, acesso forçado à unidade) perderiam essa marca e seriam executadas como E/S normal. Essa foi a versão moderna para ignorar as solicitações de liberação! Eles corrigiram o bug, mas deixaram uma opção para retornar ao comportamento anterior com bugs. A versão do Windows Server 2003 dessa caixa de seleção é chamada de “Ativar desempenho avançado”, mas agora é conhecida como apenas “Restaurar comportamento anterior com bugs”.

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. Curiosamente, ele é tão prevenido que não tira nem as etiquetas dos travesseiros.