 TechNet Magazine December 2006
TechNet Magazine December 2006
DECEMBER 2006
Exchange Server 2007

Pronto para mudar para o Exchange 2007? Você veio ao lugar certo. Neste mês mostraremos como se preparar para a atualização, como escrever scripts para gerenciar o Exchange usando o Exchange Management Shell e como obter o melhor do acesso de qualquer lugar e da troca unificada de mensagens quando você combina o Outlook Web Access e o Exchange 2007.

Além disso, você encontrará todos os aprimoramentos mais recentes do Exchange Server 2007 e do cliente do Outlook 2007, aprenderá como combater spams com mais eficácia com o Sender ID Framework e explorará os registros em diário no Exchange 2007 para obter um melhor controle e conformidade.
RECURSOS
Exchange Server 2007 Atualização da sua infra-estrutura para o Exchange 2007

Seja sua organização grande ou pequena, uma transição tranqüila para o Exchange Server 2007 requer planejamento antecipado. Com a estratégia certa, você pode evitar interrupções de serviço. Dê uma olhada nas etapas que você terá de seguir ao fazer a atualização.

Kate Follis Assuma o comando com o Exchange Management Shell

O Exchange Management Shell proporciona aos administradores uma interface robusta para administrar quase todos os aspectos do Exchange Server 2007. Obtenha uma visão geral de como começar a escrever scripts, integrar aplicativos e executar outras tarefas poderosas de gerenciamento com base na linha de comando.

David Strome Exchange & Outlook: Juntos são ainda melhores

Juntos, o Exchange Server 2007 e o Microsoft Office Outlook 2007 representam um salto quântico em termos de comunicações e colaboração. Descubra como se aprofundar na configuração simplificada, nos recursos de pesquisa aprimorados, na Unificação de Mensagens e muito mais.

Michael Khalili Fique sempre em contato com o Exchange 2007

A comunicação acabou de se tornar mais poderosa do que nunca. Veja como os recursos de Unificação de Mensagens e do Outlook Web Access integrados no Exchange Server 2007 permitem que você acesse todas as suas mensagens em um só lugar...de qualquer lugar.

Joshua Trupin Registros em diário mais sofisticados no Exchange 2007

O Exchange Server 2007 proporciona recursos mais flexíveis de registro em diário, facilita o monitoramento de contas específicas de usuários e atende às especificações de conformidade em uma grande organização.

David Strome A luta contra o spam e o phishing com o ID do rementente

A autenticação de emails integrada no SIDF (Sender ID Framework) está ganhando grande adesão, proporcionando grandes avanços no combate a mensagens de spam e phishing. Na verdade, mais de um terço do volume de emails do mundo já é autenticado e compatível com o SIDF. Veja como funciona.

Craig Spiezle e Alexander Nikolayev
COLUNAS
Do Editor

Tentando ajudar

Joshua Trupin Caixa de ferramentas

Novos produtos para profissionais de TI

Greg Steen Windows PowerShell

Comandos simples. Administração sofisticada

Don Jones Post-Mortem

Migração do Exchange 5.5

Whitney Roberts 		SQL Q+A

Como evitar reinícios, instalação de várias atualizações e muito mais

Editado por Nancy Michell Ei, equipe de scripts!

Cadê os suportes para copos?

A equipe de scripts da Microsoft Security Watch

Implantação de um PKI confiável globalmente

John Morello Os arquivos da área de trabalho

Por dentro do formato do Windows Imaging

Wes Miller Segredos do Windows

À espera do RunOnce

Raymond Chen


 Exchange Server 2007: Atualiza&#231;&#227;o da sua infra-estrutura para o Exchange 2007
Exchange Server 2007 Kate Follis

Atualização da sua infra-estrutura para o Exchange 2007
Visão geral:
  • O que há de novo no Exchange 2007
  • Preparação para atualização
  • Implantação baseada na função
  • Topologia de roteamento de mensagens

Eu dava aulas sobre migração do Exchange Server 5.5 para o Exchange 2000 Server. A aula começava às 8:30 da manhã e terminava lá pelas 6:00 da tarde. Eu costumava sair da sala de aula
esgotada. Havia muito trabalho de preparação apenas para migrar os recursos de diretório, além de muita confusão sobre o NTDSNoMatch e, às vezes, a confiança do Windows NT® 4.0 que se negava a ser confiável. Devido a restrições de tempo, mal tocávamos no assunto da administração do Exchange 2000 Server. Mesmo assim sempre havia alguns alunos mais ansiosos que pretendiam sair da aula na sexta-feira à noite e concluir a migração no final de semana. Eu avisava para não fazerem isso e aconselhava que dessem mais tempo ao planejamento, mas duvido que eles ouviam meus avisos.
A transição do Exchange 2000 Server ou do Exchange Server 2003 para o Exchange Server 2007 exige o mesmo tipo de cautela - você precisa planejar antes. O processo real de transição varia de uma organização para outra e com a complexidade da implantação atual, mas o processo de transição ainda exige diversas fases. Uma organização pequena pode passar por essas fases como um único projeto, enquanto que uma organização maior pode resolver introduzir as funções de servidor e o suporte ao Exchange de forma gradual e em modo de coexistência por algum tempo. O processo ponta a ponta foi criado para manter a funcionalidade e estabilidade do sistema de mensagens em todo o período de transição. Este artigo se concentra nas etapas essenciais necessárias para manter o fluxo de mensagens em toda a sua organização durante a atualização para o Exchange Server 2007.

Considerações
O primeiro requisito a ser observado é que o Exchange Server 2007 deve ser implantado em um hardware de 64 bits e não suporta uma atualização in-loco de qualquer versão anterior do Exchange. Você deve usar o método de atualização por giro para migrar seus serviços existentes de mensagens para o Exchange 2007. Além disso, a organização do Exchange deve estar operando no modo nativo para oferecer suporte à adição dos servidores Exchange 2007. Dessa forma, se a sua organização estiver utilizando atualmente o Exchange 5.5, você deverá executar uma atualização provisória para o Exchange Server 2003 antes de migrar para o Exchange 2007.
Existem algumas alterações importantes no Exchange 2007 que você deve levar em conta ao planejar sua transição. Por exemplo, o Exchange 2007 apresenta implantação com base em funções, o que permite a seleção dos serviços de mensagens que você deseja fornecer e implanta as funções de servidor específicas daqueles serviços. É possível implantar as funções de servidor individualmente em hardware dedicado ou instalar diversas funções no mesmo servidor físico administradas como entidades separadas. Consulte a barra lateral “Funções de servidor do Exchange 2007” para obter uma explicação de cada uma delas.
Funções de servidor do Exchange Server 2007
Caixa de correio A função de servidor Caixa de correio oferece armazenamento de mensagens para uma organização. O Exchange 2007 pode suportar até 50 armazenamentos por servidor. Esses armazenamentos podem ser implantados como 50 grupos de armazenamento individuais, ou podem ser criados 50 armazenamentos em um único grupo de armazenamento. A função de servidor Caixa de correio é a única função que pode ser implantada como um cluster. Portanto, para usar o cluster, você terá que instalar o servidor Caixa de Correio em hardware dedicado.
Acesso para cliente A função de servidor Acesso para cliente substitui a funcionalidade oferecida por um servidor front-end. Ela fornece acesso a caixas de correio para os clientes que acessam o Exchange usando POP3, IMAP4, Outlook® Web Access (OWA), RPC sobre HTTPS (agora conhecido como Outlook em Qualquer Lugar) e Exchange ActiveSync®.
Transporte de Hub Esta função oferece os serviços de transporte de mensagens SMTP e MAPI para a organização do Exchange. Cada mensagem enviada ou recebida pelos usuários de sua organização é processada por um servidor Transporte de Hub. Isso é ótimo porque garante que nenhuma mensagem ignore as regras baseadas no servidor ou nas diretrizes de registros no diário que são fornecidas por agentes acionados em diversos pontos da pipeline de transporte.
Unificação de mensagens Esta função oferece acesso por voz à sua caixa de correio. Ela se integra ao seu gateway IP/VoIP ou IP-PBX para oferecer acesso telefônico a mensagens e itens do calendário e permitir a transcrição de uma resposta. Esta função é nova no Exchange e não consegue interoperar com nenhuma versão anterior do Exchange.
Transporte de Borda O servidor Transporte de Borda normalmente é implantado em sua rede de perímetro. Ele oferece transporte de mensagens SMTP entre a organização do Exchange e a Internet, além de fornecer processamento anti-spam e antivírus usando os agentes de transporte. Agora você pode padronizar uma única tecnologia para os servidores das redes da organização e de perímetro. Esse modelo de interação de conexão remota simplifica a administração e permite integração fácil dos servidores de perímetro.

Examine sua topologia
Por onde começar então? É difícil descobrir aonde você vai, a menos que saiba onde está. Avalie seu ambiente atual e documente a topologia - não apenas o ambiente do Exchange, mas também do Active Directory®. Provavelmente você gostará de saber que o Exchange 2007 aboliu o roteamento de estado de vinculação e a topologia baseada em grupos de roteamento e conectores. Em vez disso, o Exchange 2007 aproveita o investimento que sua organização já fez no desenvolvimento da topologia do Active Directory. Como resultado, todos os dados de destinatários e configuração do Exchange são armazenados no Active Directory, a topologia de roteamento se origina na configuração de site do Active Directory e todas as funções de servidor usarão o reconhecimento de site para descobrir os serviços que são executados em outras funções de servidor.
Verifique se a topologia de site atual do Active Directory aproveita a rede física básica e se todos os sites do Active Directory têm subredes associadas, para depois documentar os sites existentes do Active Directory e os links de site IP. Documente também o lugar onde estão fisicamente todos os seus servidores do Exchange 2003, o grupo de roteamento e a estrutura do conector do grupo de roteamento.
Esta é a parte mais difícil do processo de transição: passar de uma infra-estrutura de roteamento do Exchange baseada nos grupos de roteamento para uma infra-estrutura de roteamento baseada em sites do Active Directory. Em geral, para uma organização pequena esse é um processo simples. Em uma organização grande com muitos grupos de roteamento e onde o Exchange 2003 e o Exchange 2007 coexistem, é preciso planejar cuidadosamente a fase provisória. A última coisa que você quer é que uma mensagem enviada para sua caixa de correio do Exchange 2003 por um usuário do Exchange 2007 que está do outro lado da sala seja roteada por meio de algum grupo de roteamento remoto em uma conexão com largura de banda baixa.
Vamos começar fazendo algumas suposições sobre sua topologia atual:
  • A organização do Exchange 2003 está sendo executada no modo nativo.
  • Você tem mais de um grupo de roteamento.
  • Você tem mais de um site do Active Directory.
A Figura 1 representa o diagrama de uma topologia do Exchange e do Active Directory. Lembre-se de que quanto mais detalhes você incluir em seus planos preliminares, melhor será o seu projeto.
Figura 1 Uma topologia do Exchange e do Active Directory
Figura 1 Uma topologia do Exchange e do Active Directory (Clique na imagem para diminuir a exibição)
Figura 1 Uma topologia do Exchange e do Active Directory
Figura 1 Uma topologia do Exchange e do Active Directory (Clique na imagem para aumentar a exibição)

Como o Exchange 2007 usa o Active Directory
Quando é iniciado, um servidor do Exchange 2007 é carimbado com um atributo de site que ajuda os outros servidores do Exchange 2007 a localizarem os serviços fornecidos por aquele servidor. Apenas o servidor Transporte de Hub pode usar o SMTP para transportar uma mensagem dentro da organização. Cada site do Active Directory que contém um servidor Caixa de correio também deve conter um servidor Transporte de Hub e, se os usuários de caixa de correio acessarem sua caixa de correio usando qualquer método diferente do MAPI, cada site também deverá conter um servidor Acesso para cliente. Sempre que uma mensagem precisar ser processada para entrega, ela passará por um servidor Transporte de Hub, o qual tomará uma decisão sobre o modo como a mensagem deverá ser roteada. Se a mensagem se destinar a um servidor Caixa de correio no mesmo site do Active Directory que o servidor Transporte de Hub, o servidor Transporte de Hub entregará a mensagem na caixa de correio. Se a mensagem se destinar a um servidor Caixa de correio que está em um site diferente, o servidor Transporte de Hub retransmitirá a mensagem diretamente para um servidor Transporte de Hub no site remoto.
O servidor Transporte de Hub utiliza as informações de custo do link de site IP do Active Directory para calcular a rota de menor custo para o site do Active Directory no qual a caixa de correio do destinatário está localizada. O algoritmo de seleção de rotas é muito semelhante ao Exchange 2003, mas ele se baseia nos custos do link do site IP em vez dos custos do conector do grupo de roteamento. Além disso, a mensagem não pára em cada servidor Transporte de Hub que existe pelo caminho. Ela vai diretamente da origem até o destino. Assim, por que se importar em calcular a rota de menor custo se ela depende da rede IP para transportar a mensagem? Existem algumas razões para isso. Uma é retardar a bifurcação da mensagem. Uma mensagem que está sendo enviada para mais de um destinatário pode precisar ser entregue aos servidores Caixa de correio em mais de um site do Active Directory. Em vez de bifurcar ou dividir a mensagem do primeiro servidor Transporte de Hub, o Exchange 2007 não divide a mensagem até ela atingir uma bifurcação no caminho de roteamento. Como resultado, a mensagem será retransmitida diretamente para um servidor Transporte de Hub no site do Active Directory que representa o ponto de bifurcação. Esse comportamento é conhecido como realização de fan-out atrasada.
A rota de menor custo também é usada para determinar em que fila colocar a mensagem caso o destino não possa ser atingido. Se um servidor Transporte de Hub do site de destino do Active Directory não puder ser alcançado, o servidor Transporte de Hub tentará entregar em um servidor Transporte de Hub no site do Active Directory mais próximo de acordo com o caminho de roteamento. A entrega da mensagem continuará ao longo da rota de menor custo até atingir um site do Active Directory onde houver um servidor Transporte de Hub disponível. Finalmente, se não houver nenhum servidor Transporte de Hub disponível ao longo da rota até o site Active Directory do destinatário, a mensagem será colocada em fila localmente. Esse método coloca a mensagem na fila mais próxima possível do ponto de entrega, ajudando a tornar o diagnóstico das falhas de rede mais determinístico. Esse comportamento é conhecido como fila no ponto de falha.
O Exchange 2003 funciona de modo completamente diferente. Ele calcula a rota de menor custo de um grupo de roteamento para outro, com base nos custos atribuídos aos conectores do grupo de roteamento. Um servidor bridgehead em cada grupo de roteamento ao longo do caminho de roteamento receberá e retransmitirá a mensagem. Se o próximo conector do caminho não estiver disponível, será feita uma tentativa para calcular uma rota alternativa. As mensagens de atualização do estado do link também são comunicadas em toda a organização do Exchange para notificar os outros servidores do Exchange de que a conexão caiu. Os servidores bridgehead tentarão rotear ao redor do conector com problemas até que uma notificação de estado de link seja recebida indicando que a conexão está funcionando.
O desafio de fazer a transição de uma grande organização é manter o fluxo de email durante o período de coexistência. Para atingir essa continuidade quando o Exchange 2007 é apresentado ao ambiente, todos os servidores do Exchange 2007 se tornam membros de um único grupo de roteamento. Isso significa que, seja qual for o site do Active Directory no qual está o servidor do Exchange 2007, o Exchange 2003 o verá como pertencendo àquele único grupo de roteamento. Isso permite estabelecer um conector do grupo de roteamento entre aquele grupo de roteamento e os grupos de roteamento do Exchange 2003 para que o Exchange 2003 possa calcular como rotear mensagens para o Exchange 2007. O Exchange 2007 também usará o conector do grupo de roteamento para determinar como entregar as mensagens ao Exchange 2003. Entretanto, o Exchange 2007 sempre preferirá rotear uma mensagem por meio de outro servidor do Exchange 2007 e nunca fará o backbone através de um grupo de roteamento do Exchange 2003 para atingir outro servidor do Exchange 2007.

Introdução do primeiro servidor do Exchange 2007
Quando instalar o primeiro servidor do Exchange 2007 na organização do Exchange 2003, você terá que selecionar um servidor bridgehead do Exchange 2003 com o qual será estabelecido o conector do primeiro grupo de roteamento.
A Figura 2 mostra como a introdução do primeiro servidor do Exchange 2007 afeta a topologia da organização.
Figura 2 Instalação do primeiro servidor do Exchange 2007
Figura 2 Instalação do primeiro servidor do Exchange 2007 (Clique na imagem para diminuir a exibição)
Figura 2 Instalação do primeiro servidor do Exchange 2007
Figura 2 Instalação do primeiro servidor do Exchange 2007 (Clique na imagem para aumentar a exibição)
Até aqui tudo bem. Observe que o custo padrão do conector do grupo de roteamento criado pelo Exchange 2007 é apenas 1. O email continua fluindo como sempre através dos servidores do Exchange 2003 e, se uma mensagem for enviada para um usuário no servidor do Exchange 2007 de qualquer servidor do Exchange 2003, ela fluirá através do grupo de roteamento Acapulco. Quando o conector do grupo de roteamento foi criado, o servidor bridgehead do Exchange 2003 que você selecionou se tornou automaticamente um membro do grupo de segurança universal ExchangeLegacyInterop e recebe as permissões corretas para enviar e receber mensagens de email de e para o Exchange 2007. Você sempre deve usar o novo RoutingGroupConnector do Shell de Gerenciamento do Exchange para criar um conector do grupo de roteamento sempre que um servidor do Exchange 2007 for especificado como um servidor de origem ou destino para o conector. Você também pode usar o cmdlet Set-RoutingGroupConnector para modificar a configuração de um conector do grupo de roteamento. Por exemplo, você pode adicionar servidores de origem e de destino ao conector do grupo de roteamento inicial para fornecer redundância. (Consulte o artigo de David Strome na Shell de Gerenciamento do Exchange nesta edição da TechNet Magazine para obter mais informações.)

Preparação para migrar algumas caixas de correio
A próxima etapa é migrar algumas caixas de correio dos servidores do Exchange 2003 para os servidores do Exchange 2007. Use o cmdlet Move-Mailbox para executar esta tarefa. Antes de descomissionar o domínio dos servidores do Exchange 2003, porém, você pode criar conectores Send e Receive no servidor do Exchange 2007 para substituir os conectores SMTP que foram definidos no servidor do Exchange 2003 e processar o roteamento para os espaços de endereçamento externos do SMTP.
No próximo diagrama, os recursos do grupo de roteamento Acapulco foram migrados para o Exchange 2007. O grupo de roteamento Acapulco pode ser descomissionado, mas isso significa que agora você tem que estabelecer um conector de grupo de roteamento para um grupo diferente. Na Figura 3 eu configurei o conector do grupo de roteamento para um servidor bridgehead do grupo de roteamento Norte Miami.
Figura 3 Configuração do conector de grupo de roteamento
Figura 3 Configuração do conector de grupo de roteamento (Clique na imagem para diminuir a exibição)
Figura 3 Configuração do conector de grupo de roteamento
Figura 3 Configuração do conector de grupo de roteamento (Clique na imagem para aumentar a exibição)
Vamos fazer a migração do grupo de roteamento Leste LA para o Exchange 2007. Esse é o tipo de situação na qual fica um pouco difícil manter o roteamento. Na Figura 4, o Exchange 2007 foi instalado no site Los Angeles e um segundo grupo de roteamento foi descomissionado, mas nenhum conector adicional de grupo de roteamento foi criado.
Figura 4 O Exchange 2007 instalado no site Los Angeles
Figura 4 O Exchange 2007 instalado no site Los Angeles (Clique na imagem para diminuir a exibição)
Figura 4 O Exchange 2007 instalado no site Los Angeles
Figura 4 O Exchange 2007 instalado no site Los Angeles (Clique na imagem para aumentar a exibição)
Se uma mensagem for enviada do servidor Exchange 2007 no site Los Angeles para o servidor do Exchange 2003 no grupo de roteamento Oeste LA, ele será primeiramente retransmitido para Acapulco, depois para Norte Miami, para Sul Miami e finalmente para Oeste LA. Se uma mensagem for enviada do servidor Exchange 2003 no grupo de roteamento do site Oeste LA para o servidor do Exchange 2007 no site Los Angeles, ele será primeiramente retransmitido para Sul Miami, depois para Norte Miami, para Acapulco e, finalmente, voltará a Los Angeles. Nossa!
Para evitar isso, precisamos adicionar um segundo conector do grupo de roteamento. A Figura 5 mostra a adição de um conector do grupo de roteamento de Oeste LA para o servidor do Exchange 2007 no site Los Angeles. Observação: se desejar evitar uma abundância de conectores de grupo de roteamento, verifique se o seu primeiro conector do grupo de roteamento está configurado em um site hub do Active Directory bem conectado.
Figura 5 Roteamento mais eficiente
Figura 5 Roteamento mais eficiente (Clique na imagem para diminuir a exibição)
Figura 5 Roteamento mais eficiente
Figura 5 Roteamento mais eficiente (Clique na imagem para aumentar a exibição)
Isso apresenta um problema que pode não ficar imediatamente aparente. Agora há mais de uma maneira de entrar e sair do grupo de roteamento do Exchange 2007. Como o grupo de roteamento do Exchange 2007 não usa o estado de link, agora existe um loop de roteamento potencial. O servidor do Exchange 2003 pode selecionar uma rota alternativa para desviar de um conector com problemas, enquanto o Exchange 2007 sempre selecionará a rota de menor custo. Para contornar esse problema, é necessário suprimir as mensagens menores de atualização do estado de link, as quais evitam as mensagens de estado de link que comunicam um estado de conector desativado, mas não evitam as mensagens de estado de link que comunicam alterações de configuração. Isso é importante, porque queremos que os servidores do Exchange 2003 conheçam os novos conectores de grupo de roteamento, mas não queremos que eles tentem calcular uma rota alternativa. O resultado final é que os servidores do Exchange 2003 exibirão a mesma fila no ponto de falha dos servidores do Exchange 2007.
Na Figura 6 fizemos a transição de mais recursos do Exchange 2003 para o Exchange 2007. As atualizações do estado de link foram suprimidas e os conectores do grupo de roteamento que mantêm um caminho de roteamento lógico foram estabelecidos cuidadosamente.
Figura 6 Mais migração de recursos do Exchange 2003 para o Exchange 2007
Figura 6 Mais migração de recursos do Exchange 2003 para o Exchange 2007 (Clique na imagem para diminuir a exibição)
Figura 6 Mais migração de recursos do Exchange 2003 para o Exchange 2007
Figura 6 Mais migração de recursos do Exchange 2003 para o Exchange 2007 (Clique na imagem para aumentar a exibição)
Entretanto, há outro problema. Criamos ilhas de estado de link em Redmond e Vancouver. Os emails podem fluir muito bem, embora passem por Miami, mas não há como Redmond e Miami comunicarem as alterações de configuração no estado do link. Para manter uma tabela de roteamento atualizada, você precisará configurar outro conector do grupo de roteamento entre Redmond e Vancouver. Você pode ajustar o custo desse conector do grupo de roteamento para que ele seja alto o suficiente para evitar que o Exchange 2003 faça o roteamento pela conexão, permitindo que as alterações de configuração no estado do link ainda sejam comunicadas.
Com planejamento cuidadoso, você pode desviar dos problemas que podem surgir da manutenção de duas topologias de roteamento do Exchange separadas. Você atingirá os resultados de conexão remota fazendo a transição de um grupo de roteamento de cada vez e passando para o próximo até executar apenas servidores do Exchange 2007.
Até agora, nos concentramos nas alterações de roteamento do Exchange 2007 e em como elas afetam sua transição. Existem algumas outras considerações a serem lembradas ao planejar a migração para o Exchange 2007.
Os servidores front-end do Exchange 2003 não podem acessar as caixas de correio do Exchange 2007. Entretanto, um servidor Acesso para cliente do Exchange 2007 não tem problemas em conectar você à sua caixa de correio do Exchange 2003. Ao usar o servidor Acesso para cliente do Exchange 2007, você simplesmente verá a mesma versão do OWA que o servidor de caixa de correio no qual sua caixa de correio está armazenada. Se você estiver implantando o Exchange 2007 em um hardware separado, o servidor Acesso para cliente deverá ser a primeira função introduzida em um site do Active Directory. Todos os servidores front-end do Exchange 2003 que fornecem acesso público pela Internet às caixas de correio devem ser substituídos pelos servidores Acesso para cliente do Exchange 2007 antes de quaisquer caixas de correio serem migradas para o Exchange 2007.
Já mencionamos que cada site que contém a função de servidor Caixa de correio também exige a função de servidor Acesso para cliente (se você tem clientes não MAPI - e quem poderia viver sem OWA hoje em dia?) e um servidor Transporte de Hub. Assim, para que suas funções de servidor compartilhem o hardware, verifique se incluiu o servidor Acesso para cliente na seleção de funções. Uma instalação típica incluirá as funções de servidor Transporte de Hub, Acesso para cliente e Caixa de correio - tudo o que você precisa para um ambiente do Exchange totalmente funcional.
Outra consideração sobre o processo de transição deve ser feita ao atualizar seu aplicativo cliente (Outlook). Você não poderá aproveitar totalmente todos os recursos do servidor do Exchange 2007 até que seus clientes tenham atualizado para o Outlook 2007. Isso inclui configurações de mensagens de ausência temporária avançadas e recursos de pastas de caixa de correio gerenciadas.
Você também precisa decidir quando implantar a função de servidor Transporte de Borda. Tecnicamente, pode-se substituir sua retransmissão SMPT de rede de perímetro e host inteligente atuais pelo servidor Transporte de Borda antes ou depois de introduzir quaisquer funções de servidor do Exchange 2007. Se você implantar primeiro o servidor Transporte de Borda, porém, a funcionalidade geral será limitada porque o Exchange 2003 não tem como replicar os dados do destinatário e de configuração que o servidor Transporte de Borda precisa do Active Directory para o ADAM (Modo de Aplicativo do Active Directory).
Após ter instalado pelo menos um servidor Transporte de Hub, você poderá implantar o servidor Transporte de Borda na rede de perímetro e inscrever o servidor Transporte de Borda no site do Active Directory no qual reside o servidor Transporte de Hub. O serviço EdgeSync do servidor Transporte de Hub replicará um subconjunto dos dados de destinatário do Active Directory para o ADAM.
Esses dados permitem que o servidor Transporte de Borda realize pesquisa de destinatário e agregação de lista segura, para que você aproveite totalmente os agentes anti-spam executados no servidor Transporte de Borda. Além disso, o EdgeSync criará os conectores Send que são necessários para o fluxo de email de ponta a ponta de e para a organização do Exchange e a Internet. Isso pode simplificar o processo de substituição dos conectores SMPT do Exchange 2003 que fornecem roteamento aos espaços de endereçamento externos.
Portanto, planeje sua transição para o Exchange 2007 e você encontrará a rota de forma direta e fácil.

Kate Follis é editora chefe de conteúdo da equipe de redatores técnicos do Exchange 2007. Seu grupo é especializado nas funções de servidor Transporte de Borda e Transporte de Hub. Antes da Microsoft, Kate trabalhou como Microsoft Certified Trainer por vários anos, dando aulas sobre Exchange e Active Directory.
© 2007 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..


 Exchange Server 2007: Assuma o comando com o Shell de Gerenciamento do Exchange
Exchange Server 2007 David Strome

Assuma o comando com o Shell de Gerenciamento do Exchange
Visão geral:
  • Como o Shell de Gerenciamento do Exchange funciona
  • Como usar os comandos cmdlets
  • Cmdlets vs.

Se você administra um ambiente do Exchange, estou certo de que já ouviu falar do Exchange Server 2007, que está prestes a chegar e inclui uma nova interface de linha de comando chamada Shell de Gerenciamento do Exchange. Desenvolvido com base na tecnologia Microsoft Windows PowerShell, o Exchange
Management Shell é uma robusta interface de gerenciamento que você pode usar para gerenciar cada aspecto do Exchange Server 2007 com base na linha de comando. Desse ponto em diante, você poderá interagir diretamente com o Shell de Gerenciamento do Exchange, escrever scripts para automação ou integrar seus aplicativos com o mecanismo subjacente. A Figura 1 mostra o shell em ação.
Figura 1 O Shell de Gerenciamento do Exchange
Figura 1 O Shell de Gerenciamento do Exchange (Clique na imagem para diminuir a exibição)
Figura 1 O Shell de Gerenciamento do Exchange
Figura 1 O Shell de Gerenciamento do Exchange (Clique na imagem para aumentar a exibição)
O Exchange Management Console simplesmente não usa o Shell de Gerenciamento do Exchange para executar operações; os assistentes mostram quais comandos estão em execução. Copie os comandos criados pelos assistentes e cole-os diretamente na linha de comando ou em um script. Depois de modificar os parâmetros de acordo com suas necessidades, teste seus scripts ou comandos usando o parâmetro WhatIf, que lhe permite ver os resultados antes de fazer alterações em seu ambiente.
O Shell de Gerenciamento do Exchange proporciona uma plataforma de script robusta e flexível que se integra às suas atuais soluções de script e permite comunicação nativa com origens de dados como COM e WMI (Instrumentação de Gerenciamento do Windows). Com base no .NET Framework, o Shell de Gerenciamento do Exchange usa o cmdlets £ a menor unidade de funcionalidade do Shell de Gerenciamento do Exchange £ para aceitar e retornar dados estruturados em vez de texto sem formatação. Em breve, veremos o cmdlets em mais detalhes.

Snap-in do Windows PowerShell
O primeiro passo para entender o Shell de Gerenciamento do Exchange é verificar como ele se relaciona com o Windows PowerShell™, uma interface de linha de comando totalmente nova, poderosa e flexível, baseada no .NET Framework. Ele alia os melhores recursos de outros shells a vários outros novos recursos. O Windows PowerShell foi projetado para ser um host de outros aplicativos, muito parecido ao MMC (Console de Gerenciamento Microsoft) que atua como um host para os vários snap-ins fornecidos com aplicativos. O Shell de Gerenciamento do Exchange é o primeiro snap-in do Windows PowerShell a ser lançado.
Snap-ins são coleções de cmdlets usados para administrar um aplicativo ou componente importante. Se você não carregá-los primeiro, não poderá usá-los. Por sorte, é extremamente fácil iniciar o snap-in do Shell de Gerenciamento do Exchange. Mas antes de abordar esse assunto, devo explicar alguns dos principais conceitos que você precisará entender ao ler este artigo e usar o Shell de Gerenciamento do Exchange.
Cmdlets - cmdlets são semelhantes a comandos internos de outros shells, por exemplo, o comando dir encontrado em cmd.exe. Como esses comandos conhecidos, os cmdlets podem ser chamados diretamente da linha de comando no Shell de Gerenciamento do Exchange e executados no contexto do shell, não como um processo separado. Diferentemente dos comandos em outros shells, os cmdlets têm nomes descritivos no formato verbo-substantivo. O verbo descreve a ação do cmdlet e o substantivo descreve o componente ou recurso em ação.
Você não precisa adivinhar o que um cmdlet faz. Quando vir o cmdlet Move-Mailbox (Mover-caixa de correio), você saberá exatamente para que ele serve.
Para consultar como os cmdlets diferem dos comandos comuns, consulte a barra lateral "Cmdlets vs. Commands", na seção .NET Framework 3.0 do Windows® SDK e que pode ser encontrada em windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx.
Parâmetros Identity e Positional. O parâmetro Identity pode ser usado com a maioria dos cmdlets relacionados ao Exchange. Ele proporciona acesso aos identificadores exclusivos que se referem a um objeto específico no Exchange Server 2007 para que você possa executar ações em um objeto específico do Exchange usando o valor exclusivo que faz mais sentido para você.
O parâmetro Identity é uma coleção de valores de outros parâmetros. Há uma garantia de que esses valores sejam exclusivos nesse conjunto de objetos. Você pode especificar os valores de outros parâmetros, como Name e DistinguishedName, ou eles podem ser gerados pelo sistema, como um GUID. Questões como a existência de outros parâmetros utilizados e o modo como são preenchidos dependem do objeto em referência.
O parâmetro Identity também é considerado um parâmetro posicional £ que permite especificar seu valor sem especificar o nome. Um parâmetro é posicional quando o atributo Parameter Position é um número inteiro. Esse número inteiro indica a posição na linha de comando onde o cmdlet poderá encontrar o valor do parâmetro. Como o parâmetro Identity é um parâmetro posicional residente na posição 0, que é a primeira posição, qualquer valor inserido nessa posição sem um nome de parâmetro é considerado um valor de parâmetro Identity. Isso reduz o número de pressionamento de teclas quando você digita comandos. Por exemplo
Get-Mailbox –Identity "Kim Akers"
executa a mesma ação de:
Get-Mailbox "Kim Akers"
Pipelining - Pipelining no Shell de Gerenciamento do Exchange é o ato de um cmdlet que usa a saída de outro cmdlet ao executar uma operação. Pipelining é feito com o uso do símbolo "|" (pipe ou barra vertical). Todos os verbos no mesmo conjunto de cmdlets-substantivos podem usar as informações em pipe de outro comando. Alguns conjuntos de cmdlets-substantivos permitem que você passe dados pelo pipeline para outro conjunto de cmdlets-substantivos.
Ao lançar mão de pipelining para encadear as ações de dois ou mais cmdlets, você poderá usar componentes menores e convertê-los em algo mais potente. Por exemplo, é possível usar um cmdlet para reunir dados, passá-los para um segundo cmdlet onde serão filtrados formando um subconjunto e de onde, finalmente, serão passados para um terceiro cmdlet que atuará apenas no subconjunto.

Como iniciar o Shell de Gerenciamento do Exchange
O modo mais simples de carregar o shell é clicar em Iniciar, clicar em Programas, Microsoft Exchange Server 2007 e, em seguida, clicar em Shell de Gerenciamento do Exchange.
O segundo modo de carregar o snap-in do Shell de Gerenciamento do Exchange é o manual, executado em uma seção do Windows PowerShell. Clique em Iniciar, Programas e, em seguida, clique em Windows PowerShell. Após a inicialização do sistema, execute o seguinte comando para carregar o Shell de Gerenciamento do Exchange:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Há algumas diferenças entre carregar o snap-in do Shell de Gerenciamento do Exchange usando a entrada pelo menu Programas e o modo manual através do cmdlet Add-PSSnapin. Quando você usa a entrada pelo menu Programas, além de carregar o snap-in do Shell de Gerenciamento do Exchange, carrega também um script do Windows PowerShell para configurar um ambiente de administração personalizado do Exchange. Se quiser configurar um ambiente administrativo semelhante depois de carregar o Shell de Gerenciamento do Exchange manualmente, altere a pasta de instalação do Exchange £ por exemplo, C:\Program Files\Microsoft\Exchange Server\Bin. Depois, execute o seguinte comando:
.\Exchange.ps1
Consulte o script Exchange.ps1 para ver como personalizar o ambiente do Windows PowerShell de acordo com suas necessidades. Ao carregar o Shell de Gerenciamento do Exchange, você verá algo semelhante à Figura 2.
Figura 2 Faixa de boas-vindas do Shell de Gerenciamento do Exchange
Figura 2 Faixa de boas-vindas do Shell de Gerenciamento do Exchange (Clique na imagem para diminuir a exibição)
Figura 2 Faixa de boas-vindas do Shell de Gerenciamento do Exchange
Figura 2 Faixa de boas-vindas do Shell de Gerenciamento do Exchange (Clique na imagem para aumentar a exibição)

Por onde começo?
Como o shell tem uma extensa matriz de cmdlets, o cmdlet Get-Help e o arquivo de Ajuda do Exchange Server 2007 serão recursos imprescindíveis. A seção Operations no arquivo de Ajuda do Exchange Server 2007 fornece vários procedimentos explicativos para execução da maioria das tarefas administrativas.
Basta digitar Get-Help para exibir informações gerais sobre como obter ajuda. Para encontrar ajuda sobre um determinado cmdlet, digite Get-Help seguido pelo cmdlet sobre o qual deseja obter informações. Você pode controlar as informações que serão apresentadas usando os parâmetros Detailed, Full e Example. Apenas adicione-os ao final do comando. Por exemplo, o Get-Helpnome do cmdlet – Full retorna todas as seções da ajuda disponíveis sobre esse cmdlet.
Se você quiser recuperar informações sobre um ou mais parâmetros de um cmdlet, poderá usar o parâmetro Parameters com Get-Help. Portanto, se quiser ver todos os parâmetros e as respectivas descrições no cmdlet Set-Mailbox que contém a palavra "quota," use o comando:
Get-Help Set-Mailbox –Parameter *quota*
Você pode desejar consultar uma lista de cmdlets que gerenciam uma função específica do servidor, um recurso do componente ou que afetem objetos em um determinado escopo de funcionalidade. O cmdlet Get-Help permite executar essas ações com três parâmetros: Role, Component e Functionality. Ao usar o cmdlet Get-Help com esses parâmetros, você deverá colocar os valores que especificar com esses parâmetros entre caracteres curinga, "*". Seguem exemplos de como chamar o Get-Help com cada parâmetro:
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
Para obter mais informações, o tópico "Getting Help" no arquivo de Ajuda do Exchange Server 2007 relaciona todos os valores de função, componente e funcionalidade que podem ser usados.

Como formatar a saída do comando
Por padrão, quando a saída é exibida na tela, o Shell de Gerenciamento do Exchange exibe somente um subconjunto das propriedades disponíveis de cada objeto. Entretanto, você pode obter acesso facilmente a todas as propriedades canalizando a saída de um comando para estes três cmdlets de formatação: Format-List, Format-Table e Format-Wide. Como é provável que você use Format-List e Format-Table regularmente, falarei sobre isso de forma mais específica.
O cmdlet Format-List pega a entrada do pipeline e coloca a saída em uma lista de colunas verticais com todas as propriedades especificadas de cada objeto. Você pode especificar quais propriedades deseja exibir usando o parâmetro Property (embora este seja um parâmetro posicional, ou seja, que exige a especificação apenas dos valores e não do nome do parâmetro). Se o cmdlet Format-List for chamado sem nenhum parâmetro especificado, todas as propriedades serão exibidas. Esse cmdlet quebra as linhas em vez de truncá-las. Um dos melhores usos do Format-List é substituir a saída padrão de um cmdlet de modo que você possa recuperar informações adicionais ou mais específicas. Por exemplo:
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
A Figura 3 mostra a saída desse comando.
Figura 3 Exemplo de saída do Format-List
Figura 3 Exemplo de saída do Format-List (Clique na imagem para diminuir a exibição)
Figura 3 Exemplo de saída do Format-List
Figura 3 Exemplo de saída do Format-List (Clique na imagem para aumentar a exibição)
O cmdlet Format-Table permite exibir itens no formato de tabela com cabeçalhos e colunas dos dados de propriedade. Por padrão, vários cmdlets, como Get-Mailbox e Get-JournalRule, usam o formato de tabela como saída. Entre os parâmetros do cmdlet Format-Table estão Properties e GroupBy. Esses parâmetros funcionam exatamente como no cmdlet Format-List. Para obter longas linhas de informações sobre propriedade exibidas completamente em vez de truncadas no fim de uma linha, use o parâmetro Wrap, deste modo:
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
Consulte a Figura 4 para ver a saída.
Figura 4 Exemplo de saída do Format-Table
Figura 4 Exemplo de saída do Format-Table (Clique na imagem para diminuir a exibição)
Figura 4 Exemplo de saída do Format-Table
Figura 4 Exemplo de saída do Format-Table (Clique na imagem para aumentar a exibição)
Se você incluir um caractere curinga, poderá vincular várias propriedades sem precisar digitar o nome de cada uma delas individualmente. Por exemplo, isto retorna todas as propriedades que começam com Email.
Get-Mailbox | Format-List Email*

Hora de praticar
Agora que você conhece os comandos básicos, por que não exercitar com os exemplos a seguir? Eles ilustram a força e a flexibilidade do Shell de Gerenciamento do Exchange e permitem que você coloque a mão na massa.
Com o comando do primeiro exercício, você criará 10 usuários, User1 a User10:
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
Vejamos em partes. O comando 1.0 gera números inteiros de 1 a 10 e os passa pelo pipeline ao cmdlet ForEach. O cmdlet ForEach age em cada objeto como o recebeu e executa os comandos dentro das chaves { } referentes a cada objeto. O comando Net User cria um novo usuário de domínio e o cmdlet Enable-Mailbox cria uma nova caixa de correio no "Mailbox Database" no servidor local. O ponto-e-vírgula separa os dois comandos para que possam ser colocados na mesma linha de comando. $_ variable é uma variável especial que contém o valor do objeto atual no pipeline. Neste exemplo, $_ variable contém o número inteiro que está no pipeline no momento.
No próximo exemplo, você poderá ver as caixas de correio residentes no servidor MBX e retornar as propriedades Name, Mailbox Database e Quota de cada caixa de correio.
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
O cmdlet Get-Mailbox retorna cada caixa de correio com o parâmetro Server e coloca a saída em pipe de cada objeto de caixa de correio para o cmdlet Format-Table. Por padrão, o cmdlet Format-Table exibe todas as propriedades retornadas por um cmdlet a menos que você especifique quais propriedades deverão ser exibidas. Aqui, somente as propriedades Name e Database, bem como todas as propriedades que contêm a cadeia de caracteres "quota", serão solicitadas. A Figura 5 mostra a aparência dessa saída.
Figura 5 Saída do comando Get-Mailbox
Figura 5 Saída do comando Get-Mailbox (Clique na imagem para diminuir a exibição)
Figura 5 Saída do comando Get-Mailbox
Figura 5 Saída do comando Get-Mailbox (Clique na imagem para aumentar a exibição)
Neste exemplo, você definirá o limite de quota de envio como 600MB para todos os usuários com email habilitado, em toda a organização, e que tenham a palavra "Gerente" no cargo.
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
O cmdlet Get-User é executado automaticamente e retorna todos os objetos de usuários no Active Directory, incluindo os usuários sem caixa de correio habilitada. Para recuperar um conjunto de objetos de usuários que podem ser usados pelo cmdlet Set-Mailbox, você precisa instruir o cmdlet Get-User a retornar somente os objetos de usuário do Active Directory que consistam em usuários com email habilitado. O parâmetro RecipientTypeDetails permite especificar o tipo de destinatário do Active Directory, neste caso, UserMailbox. Em seguida, é necessário recuperar o conjunto de usuários com email habilitado e o cargo de gerente. Neste exemplo, a propriedade Title de cada objeto de usuário do Active Directory é preenchida. Você pode usar esse valor para determinar quais usuários são gerentes usando o parâmetro Filter, que instrui o servidor a retornar somente os objetos do Active Directory que correspondam aos seus critérios. Isso se chama filtragem do lado do servidor. Uma vez definido, o conjunto de objetos passa para o cmdlet Set-Mailbox, que então define a propriedade ProhibitSendQuota de cada caixa de correio como 600MB.
Em seguida, testaremos o resultado de um comando para remover todas as caixas de correio que sejam membros de um grupo de distribuição. Este é o comando:
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
O primeiro cmdlet recupera os objetos de destinatário que sejam membros do grupo de distribuição Fourth Year Students. Então, somente os objetos de destinatário que correspondam ao RecipientType de "UserMailbox" passarão para o cmdlet Remove-Mailbox. Em vez de remover as caixas de correio, o cmdlet Remove-Mailbox exibirá a ação a ser realizada e os objetos sobre os quais executará alguma ação. O cmdlet Get-DistributionGroupMember recupera uma lista com todos os objetos de destinatário que sejam membros do grupo de distribuição "Fourth Year Students". Entretanto, como o cmdlet Remove-Mailbox funciona somente com usuários com email habilitado, você terá de excluir todos os tipos de destinatário, exceto os que tenham o parâmetro "UserMailbox". Diferentemente de outros cmdlets, o cmdlet Get-DistributionGroupMember não tem o cmdlet Filter, ou seja, você não poderá executar a filtragem do lado do servidor. Para cmdlets que não podem realizar a filtragem do lado do servidor (porque não vêem nenhum benefício em termos de desempenho), você pode usar o cmdlet Where para realizar a filtragem do lado do cliente, que recupera todos os objetos e executa a filtragem no computador local do cliente. O cmdlet Where permite somente a passagem de objetos que correspondam aos critérios especificados. Os objetos com RecipientType de "UserMailbox" são enviados para o cmdlet Remove-Mailbox. Esse cmdlet remove o objeto de usuário do Active Directory e marca a caixa de correio para remoção. Quando o parâmetro WhatIf é usado, o cmdlet Remove-Mailbox exibe um texto semelhante ao seguinte:
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
Se estiver satisfeito que o comando realize as ações desejadas, execute-o novamente sem o parâmetro WhatIf. Para determinados cmdlets, como os que têm o verbo Remove, o shell pedirá automaticamente confirmação antes de fazer alterações. Você tem a opção de seguir a alteração passo a passo, instruir o shell a não solicitar confirmação novamente ou cancelar processamento posterior. Para cmdlets que não implementam confirmação automaticamente, você pode forçar a confirmação usando o parâmetro Confirm.

Conclusão
Agora que você tem uma noção básica sobre o potencial do cmdlet, está pronto para experimentar e constatar como o Shell de Gerenciamento do Exchange e o Microsoft Windows PowerShell em suas futuras tarefas de gerenciamento de sistemas. Se quiser ler mais a respeito desses dois tópicos, consulte os seguintes recursos. Para obter informações sobre o Management Shell, consulte o arquivo de Ajuda do Exchange Server 2007 em go.microsoft.com/fwlink/?LinkId=69434, o centro de scripts do Windows Powershell em go.microsoft.com/fwlink/?LinkId=71134, e o blog da equipe do Exchange em msexchangeteam.com (em inglês).

David Strome foi redator técnico com o grupo de Instrução aos usuários do Exchange na Microsoft por pouco mais de um ano. Antes de entrar na Microsoft em Redmond, WA, David passou cerca de 10 anos desenvolvendo, implementando e administrando instalações do Exchange Server em várias empresas em British Columbia, Canadá. Ele pode ser contatado pelo email: dstrome@microsoft.com.


 Exchange Server 2007: Exchange &amp; Outlook: Juntos s&#227;o ainda melhores
Exchange Server 2007 Michael Khalili

Exchange & Outlook: Juntos são ainda melhores
Visão geral:
  • Instalação simplificada
  • Integração de correio de voz, fax e email
  • Pastas gerenciadas para conformidade

Há anos o Microsoft Exchange Server e o Outlook fornecem serviços de email confiáveis a milhões de pessoas, ajudam na colaboração mútua e no gerenciamento de calendários e facilitam a organização dos contatos. Alguns podem se perguntar o que essa combinação faria para melhorá-los ainda mais. Bem, o Exchange Server 2007
e o Microsoft Office Outlook 2007 serão lançados em breve e, juntos, oferecerão um salto quântico no âmbito das comunicações e da colaboração.
Os avanços oferecidos pelo Exchange Server 2007 e pelo Office Outlook® 2007 são visíveis desde o momento da instalação do cliente Outlook. Nas versões anteriores, o Outlook esperava que o usuário soubesse o nome do seu servidor de caixas de correio do Exchange, algo algo que representava um obstáculo para muitos usuários. Isso gerava chamadas freqüentes à assistência técnica ou scripts de inicialização complicados. Ambos os procedimentos aumentavam o custo e a complexidade da execução de um ambiente de troca de mensagens eficaz. Agora, com o serviço Web Descoberta Automática do Exchange, o Outlook poderá configurar automaticamente a conta se o cliente estiver inscrito no domínio. Se o cliente não tiver ingressado no domínio, será necessário que o usuário insira somente o nome, o email e a senha. O Outlook e o Exchange descobrirão o restante (consulte a Figura 1).
Figura 1 Configuração de conta
Figura 1 Configuração de conta (Clique na imagem para diminuir a exibição)
Figura 1 Configuração de conta
Figura 1 Configuração de conta (Clique na imagem para aumentar a exibição)
De modo semelhante, antigamente (ou quase isso), os usuários não só tinham de configurar o Outlook para o uso inicial, como também eram responsáveis por reconfigurá-lo sempre que mudassem para outro servidor de email. Mesmo quando recebem um email avisando sobre a iminente migração da caixa de correio, os usuários muito ocupados não costumam dar importância £ até que numa manhã descobrem que estão bloqueados do Outlook. A essa altura, mais uma chamada é feita ao suporte técnico. Os serviços Web Descoberta Automática resolvem isso também. Quando um usuário é movido de um servidor de caixa de correio para outro, o Outlook reconhece que a antiga configuração deixou de ser válida, consulta o serviço Web Descoberta Automática novamente e reconfigura o cliente para a nova caixa de correio. Todo esse processo é completamente transparente ao usuário final.

Reinvenção do calendário
No passado, a maior parte da lógica de calendário residia no Outlook. Cada atualização de reunião era tratada como um convite separado e, portanto, as notificações poderiam ser aceitas fora de ordem. Se duas atualizações de reunião fossem enviadas uma seguida da outra, e um destinatário aceitasse a segunda atualização antes da primeira, poderia ficar com informações desatualizadas em seu calendário. Além disso, acessar as informações do Outlook usando Smartphones ou PDAs poderia levar a informações de disponibilidade divergentes, de acordo com o método pelo qual os usuários visualizam os dados.
A solução foi mover toda a lógica de calendário do cliente Outlook para o Exchange Server 2007. Quando uma solicitação de reunião é recebida pelo servidor, a reunião é automaticamente colocada no calendário como provisória até que o usuário decida aceitar ou declinar o compromisso. Se alguma alteração de horário ou local da reunião for recebida, o compromisso será atualizado automaticamente e o convite antigo será marcado como desatualizado para que os usuários não o aceitem acidentalmente. Essa lógica é consistente entre todos os clientes £ Office Outlook, Outlook Web Access, Outlook Mobile ou outro cliente de terceiros. Portanto, somente as reuniões corretas e atualizadas permanecem presentes.
Com o calendário tão preciso e confiável, é possível oferecer um novo conjunto de ferramentas que aumentam a produtividade dos usuários. Antes, não era fácil agendar reuniões com vários funcionários ocupados. Os usuários tinham de encontrar horários livres para reuniões manualmente, percorrendo dias de informações para localizar um horário adequado para todos os participantes. Agora, o Assistente de Agendamento do Outlook 2007, mostrado na Figura 2, encontrará o melhor horário para todos. Depois de incluir os participantes obrigatórios e opcionais, bem como salas ou recursos desejados, o Assistente de Agendamento apresenta uma exibição codificada por cores com os melhores dias para a reunião. Quando uma data é escolhida, o mesmo esquema é usado para encontrar o melhor horário naquele dia.
Figura 2 Assistente para configuração
Figura 2 Assistente para configuração (Clique na imagem para diminuir a exibição)
Figura 2 Assistente para configuração
Figura 2 Assistente para configuração (Clique na imagem para aumentar a exibição)
O Assistente de Agendamento prioriza primeiro os participantes obrigatórios, depois os opcionais e, por fim, salas ou recursos necessários para determinar o horário ideal para a reunião. O Assistente de Agendamento também adapta facilmente questões como horário de trabalho flexível e diferentes fusos horários. Os usuários podem configurar seu próprio horário de trabalho, definindo a hora em que chegam e quando saem do escritório. Portanto, um funcionário que não acorda cedo, e não chega ao trabalho antes das 9 ou 10 horas da manhã, pode definir seu expediente a partir desse horário. Quando os outros precisarem agendar uma reunião, um horário mais cedo, por exemplo, 8 horas, não será sugerido. Se dois grupos em fusos horários diferentes £ digamos, um em Londres e outro em Los Angeles £ precisarem se reunir, serão sugeridos somente os horários incluídos nos dias úteis de ambos. Para os londrinos, a reunião será no fim da tarde e para os funcionários de Los Angeles, logo no primeiro horário da manhã, em vez de um compromisso às 2 horas da manhã no fuso horário de um local ou do outro.

Como encontrar uma agulha num palheiro
Com o passar dos anos, o número de emails que chegam à Caixa de entrada do usuário comum cresceu num ritmo alarmante. Embora há algum tempo uma caixa de correio de um local de trabalho típico pudesse conter somente algumas centenas de mensagens, hoje em dia algumas pessoas recebem o mesmo volume em um dia. Soterrada nessa avalanche de mensagens está uma profusão de informações essenciais às operações de qualquer empresa. Encontrar as informações corretas quando você precisa pode ser um desafio e tanto.
Os recursos de pesquisa do Office Outlook 2007 e do Exchange Server 2007 foram amplamente aperfeiçoados em relação às versões anteriores. Esteja o usuário no modo online ou cache, os mesmos algoritmos de pesquisa são aplicados à mensagem. No modo online, a solicitação de pesquisa é enviada ao servidor Exchange, onde a pesquisa é executada. O Indexador de Conteúdo do Exchange, que chega a ser 35 vezes mais rápido que o indexador do Exchange Server 2003, é usado para garantir que as mensagens sejam rapidamente encontradas e recuperadas. No modo cache, o Outlook usa a Pesquisa Instantânea, com base no Windows® Desktop Search 3.0, consolidando os mecanismos de indexação e reduzindo o tempo de CPU. A pesquisa pode ser feita no texto encontrado nos campos assunto, de, para, no corpo da mensagem ou até mesmo em anexos, conforme mostra a Figura 3.
Figura 3 Novas maneiras de pesquisar aquele email importante
Figura 3 Novas maneiras de pesquisar aquele email importante (Clique na imagem para diminuir a exibição)
Figura 3 Novas maneiras de pesquisar aquele email importante
Figura 3 Novas maneiras de pesquisar aquele email importante (Clique na imagem para aumentar a exibição)

Acesso em qualquer lugar com a Unificação de Mensagens
A Unificação de Mensagens do Exchange, um componente integrado do Exchange Server 2007, traz todos os tipos de comunicações empresarias para uma única Caixa de entrada, que inclui emails, correio de voz e fax. Nos sistemas tradicionais, o correio de voz está disponível pelo telefone, os emails pelo computador e o fax por uma máquina de fax dedicada. A Unificação de Mensagens do Exchange permite que o usuário escolha o melhor cliente para suas necessidades de acordo com local e horário específicos. No Outlook, as mensagens de voz e fax aparecem na Caixa de entrada, bem ao lado das mensagens de email. Quando selecionada, a mensagem do correio de voz contém um player incorporado para que possa ser reproduzida diretamente do painel de leitura (consulte a Figura 4).
Figura 4 Como reproduzir mensagens do correio de voz pelo Outlook
Figura 4 Como reproduzir mensagens do correio de voz pelo Outlook (Clique na imagem para diminuir a exibição)
Figura 4 Como reproduzir mensagens do correio de voz pelo Outlook
Figura 4 Como reproduzir mensagens do correio de voz pelo Outlook (Clique na imagem para aumentar a exibição)
O Outlook também permite a manipulação de mensagens em contexto. Geralmente, quando você ouve um correio de voz, faz algumas anotações em um pedaço de papel. Como não são associadas à mensagem, essas anotações podem ser perdidas £ o que está bem longe de ser um modelo de comunicação eficiente. Com a Unificação de Mensagens do Exchange, as anotações podem ser feitas diretamente no Outlook. Elas são mantidas com a mensagem e são indexadas como um texto que pode ser pesquisado, garantindo que as anotações sempre sejam exibidas no contexto desta mensagem do correio de voz. Portanto, podem ser localizadas rapidamente com a pesquisa aperfeiçoada do Exchange Server 2007 e do Office Outlook 2007.
O Outlook também pode gerenciar várias opções de correio de voz (consulte a Figura 5) permitindo, entre outras coisas, que os usuários alterem o PIN (Número de Identificação Pessoal) usando o próprio cliente. (A redefinição do PIN é a maior fonte de chamadas ao suporte técnico referentes aos sistemas de correio de voz.) Com as opções do Outlook, os usuários poderão gerar um novo PIN e o recebê-lo por email. Esse PIN oferece acesso único à interface de telefone da Unificação de Mensagens do Exchange e ao Outlook Voice Access, de onde será emitida uma solicitação de alteração do PIN.
Figura 5 A Unificação de Mensagens inclui uma opção de redefinição do PIN
Figura 5 A Unificação de Mensagens inclui uma opção de redefinição do PIN (Clique na imagem para diminuir a exibição)
Figura 5 A Unificação de Mensagens inclui uma opção de redefinição do PIN
Figura 5 A Unificação de Mensagens inclui uma opção de redefinição do PIN (Clique na imagem para aumentar a exibição)

Para segurança e proteção
Hoje em dia, as organizações enfrentam várias ameaças ao ambiente de troca de mensagens. O Outlook e o Exchange trabalham em conjunto para combater tais ameaças. O Spam é apenas uma dessas ameaças e o Office Outlook 2007 adiciona suporte aos Carimbos Postais do Outlook, uma nova maneira de combate ao Spam. O Outlook executa um pequeno quebra-cabeça computacional na saída de emails e anexa a resposta ao quebra-cabeça na mensagem. Em seguida, o Exchange verifica os resultados. Embora esses quebra-cabeças de computação usem um tempo relativamente baixo de CPU quando executados individualmente, como em um email legítimo comum, se a máquina de um remetente de Spams criar esses quebra-cabeças para um email em massa, a taxa em sua máquina será extrema. Portanto, uma mensagem com um Carimbo Postal para Emails do Outlook tem probabilidade muito maior de ser legítima do que uma mensagem sem esse recurso, e o Exchange considera esse aspecto ao determinar a validade de cada mensagem de email.
Além das antigas ameaças como Spams, novos esquemas legais estão mudando os requisitos dos sistemas de troca de mensagens. Regulamentações como a Lei Sarbanes-Oxley, o HIPPA e o Acordo de Basiléia II impõem regras rígidas para a retenção ou destruição de registros. Para atender a essa nova necessidade, o Exchange e o Outlook apresentam Pastas gerenciadas. Essas pastas são configuradas por um administrador para mensagens de um determinado tipo. No Outlook, o usuário final vê essas pastas com uma descrição do que cada uma deverá armazenar (consulte a Figura 6). As mensagens também podem ser enviadas automaticamente para uma determinada pasta com o uso das regras de transporte do Exchange. Quando armazenadas em uma determinada Pasta gerenciada, as mensagens passam a obedecer às diretrizes de arquivamento, retenção e validade dessa pasta e automaticamente serão tratadas de maneira coerente com a política da organização.
Figura 6 As pastas gerenciadas impõem o cumprimento das regras de email
Figura 6 As pastas gerenciadas impõem o cumprimento das regras de email (Clique na imagem para diminuir a exibição)
Figura 6 As pastas gerenciadas impõem o cumprimento das regras de email
Figura 6 As pastas gerenciadas impõem o cumprimento das regras de email (Clique na imagem para aumentar a exibição)
A despeito dos melhores esforços, vez por outra ocorrem violações de conformidade. Nesses casos, a rapidez na identificação e no reparo é imprescindível. A pesquisa rápida do Exchange torna-se uma ferramenta fundamental para os responsáveis pela conformidade de encontrarem indícios que levem à identificação de violações à conformidade. As pesquisas podem ser feitas em várias caixas de email a fim de rastrear e corrigir tais violações.

Um ambiente mais gerenciável
Juntos, o Exchange Server 2007 e o Office Outlook 2007 oferecem um sistema de troca de mensagens mais sofisticado que o das versões anteriores. Eles colocarão todas as comunicações vitais de sua empresa em um único local, facilitando sua localização e configuração, e aumentando a segurança e a conformidade. Juntos, levarão a colaboração e a comunicação a um novo patamar.

Michael Khalili é o gerente de produto do Exchange Server, responsável pelo Acesso para Clientes e pela Unificação de Mensagens. Entre outras atribuições, Michael também é responsável pela integração entre o Outlook e o Exchange.


 Exchange Server 2007: Fique sempre em contato com o Exchange 2007
Exchange Server 2007 Joshua Trupin

Fique sempre em contato com o Exchange 2007
Visão geral:
  • Aperfeiçoamentos para o Outlook Web Access
  • Unificação de mensagens no Exchange Server 2007
  • Segurança com o ISA Server 2006

Há alguns anos, a comunicação online era básica. Você enviava email através de POP3 e SMTP. Bem simples. Naturalmente, o mundo mudou. Hoje, as organizações precisam oferecer aos funcionários a
flexibilidade para trabalhar quando e como eles quiserem, e eles precisam fazer isso com segurança. O Microsoft® Exchange Server 2007 dispõe de vários recursos integrados que atendem a essas necessidades, incluindo o Microsoft Office Outlook® Web Access (OWA) e a Unificação de Mensagens. Vamos examinar esses dois componentes-chave do Exchange Server 2007 e como eles superam as versões anteriores para criar uma plataforma de comunicação mais avançada para as empresas atuais.
O OWA tem sido parte do Exchange desde a versão 5.5. Para ser honesto, as primeiras versões eram um pouco arcaicas. Elas representavam uma resposta ao problema de acesso à caixa de correio do Exchange com um navegador da Web, mas faziam isso sem grande parte da funcionalidade fornecida pelo Outlook.
Com o OWA aperfeiçoado que acompanha o Exchange Server 2003, as coisas começaram a melhorar para os usuários finais. A experiência com o navegador ficou muito mais natural, quase como se você estivesse trabalhando em um programa do cliente. O OWA para Exchange Server 2007 vai mais além, com uma regravação completa das versões anteriores, permitindo criar outras inovações técnicas recentes como o RPC sobre HTTP e o ASP.NET 2.0.
Por exemplo, veja como o OWA faz seu processamento. As versões anteriores do OWA foram processadas pelo servidor da caixa de correio, durante o processo de armazenamento. Isso adicionou carga extra ao servidor da caixa de correio, causando lentidão no sistema. O Outlook Web Access 2007, por outro lado, processa os dados através do ASP.NET, no CAS (Client Access Servers). Essa ação move o processamento da página para fora do servidor da caixa de correio, melhorando o desempenho.
O trabalho realizado no front-end também foi alterado. Nas versões anteriores do Exchange, as solicitações HTTP do OWA eram transmitidas por proxy ao servidor da caixa de correio apropriado. O Exchange Server 2007 reduz o tráfego associado ao OWA, buscando os dados diretamente no servidor da caixa de correio apropriado através do RPC. Este é o mesmo processo, mais ou menos, que permite que você use o Outlook em um cliente que não está em uma conexão de VPN (rede virtual privada) em sua empresa. As informações da caixa de correio são, em seguida, processadas pelo OWA. O Exchange Server 2007 também pode transmitir por proxy as solicitações do OWA, mas em vez de enviá-las diretamente aos servidores da caixa de correio, ele as encaminha aos outros servidores CAS.
A Figura 1 mostra a arquitetura do OWA no Exchange Server 2007.
Figura 1 Como o OWA acessa o recurso do Exchange Server
Figura 1 Como o OWA acessa o recurso do Exchange Server (Clique na imagem para diminuir a exibição)
Figura 1 Como o OWA acessa o recurso do Exchange Server
Figura 1 Como o OWA acessa o recurso do Exchange Server (Clique na imagem para aumentar a exibição)

Administração
A arquitetura remodelada do Exchange Server 2007 inclui opções expandidas para administrar o OWA. Você pode usar o Exchange Management Console ou o Exchange Management Shell. As definições da configuração são armazenadas em vários locais.
O Console de Gerenciamento do Exchange permite que você acesse a maior parte das definições de configuração possíveis, habilitando ou desabilitando os recursos usando segmentação, bloqueio de anexo, autenticação, e acessando recursos como o calendário, a Lista de Tarefas e a verificação ortográfica. Tudo que pode ser feito no Console de Gerenciamento do Exchange também pode ser feito usando as tarefas do Exchange Management Shell.
Além disso, o Shell de Gerenciamento do Exchange permite que você crie e exclua novos diretórios virtuais para o OWA. Você também pode obter um melhor controle sobre as configurações de segmentação por usuário e alterar a configuração do idioma padrão, entre outros.
O Registro do Windows é o armazenamento padrão para tempo limite de autenticação baseado em formulários. (Essas configurações não estão disponíveis através do Console de Gerenciamento do Exchange ou do Shell de Gerenciamento do Exchange.) Através do Active Directory® você pode acessar as configurações específicas do OWA, como bloqueio de anexo e segmentação. A Metabase do IIS contém algumas configurações (autenticação, GZIP) que influenciam o comportamento do IIS. E o web.config mantém as configurações do ASP.NET como "maxuploadsize", que controla o carregamento dos anexos do OWA.

Autenticação
O OWA fornece várias opções para autenticação no servidor. Após a configuração, a segurança assume como padrão a autenticação baseada em formulários. No entanto, isso pode ser aumentado de diversas formas, conforme necessário, para atender às necessidades da organização. O IIS executará a autenticação com o Active Directory para garantir que o usuário que surgir tenha direitos de domínio correspondentes. Você também pode usar a autenticação básica, a autenticação Digest, RSA SecurID ou até mesmo a entrada do SmartCard para acessar o email.
O nível mais alto de segurança para o OWA é o Windows Integrated, que combina Kerberos e NTLM. Na verdade, o Windows Integrated é necessário para acesso ao Web Part do Outlook Web Access 2007 e também para efetuar proxy de CAS entre os sites do Active Directory. Ele também fornece uma vantagem extra para usuários que acessam o OWA em uma intranet - fornece logon único com autenticação do cliente do Windows, dessa forma, você não terá que se conectar ao OWA, se já for um usuário confiável.
Se você usar a autenticação baseada em formulários, o padrão, o OWA automaticamente expirará após um período de inatividade. Dependendo da opção do usuário de computador público ou privado (quando solicitado no logon), o tempo limite pode ser de 15 minutos (para computadores públicos) ou pode ser no máximo de 8 horas (para um computador privado). A opção de computador público versus privado é importante para seus usuários, porque outras definições de segurança também podem ser configuradas de forma diferente, dependendo desta configuração. Você pode, por exemplo, bloquear anexos em computadores públicos ou alterar o tempo limite de autenticação. A autenticação baseada em formulários é, basicamente, um processo de quatro etapas que é mostrado na Figura 2.
Figura 2 Processo de autenticação
  1. Os clientes enviam a solicitação não criptografada ao servidor.
  2. Os servidores enviam um cookie criptografado de volta ao cliente.
  3. Os servidores continuam descartando e criando novas chaves de criptografia, mantendo as três chaves mais recentes na memória.
  4. Os clientes que enviam as solicitações com uma chave de criptografia desatualizada que ainda está na memória, obtém um novo cookie criptografado com a chave mais recente.
    -Ou-
    Os clientes que enviam as solicitações com uma chave de criptografia desatualizada, que foi descartada e expirada, devem efetuar logon novamente.

O msExchQueryBaseDN é o mecanismo usado para limitar a visualização de determinados usuários em uma subseção do catálogo de endereços no OWA. O msExchQueryBaseDN é estampado nos objetos do usuário do Active Directory e aponta para uma AL (lista de endereços) ou uma OU (unidade organizacional). Esta AL será usada como a GAL (lista de endereços global) do usuário e o usuário visualizará uma GAL, que inclui somente as contas do usuário desta OU. Você pode definir o msExchQueryBaseDN utilizando o LDAP.

Compatibilidade retroativa
O núcleo do Outlook Web Access no Exchange Server 2007 é o CAS. O modelo do CAS foi criado para fornecer a melhor interoperabilidade possível com servidores executando versões anteriores do Exchange. Para garantir que isso funciona, implante ou atualize seus servidores CAS antes de atualizar seus servidores da caixa de correio associados.
Um servidor do Exchange 2007 com a função de CAS pode ser usado para ser conectado às caixas de correio nos servidores Exchange 2000 e Exchange 2003. O RPC sobre HTTP e Exchange ActiveSync® continuarão funcionando com a atualização parcial do site. O OWA e o WebDAV também funcionarão se você acessá-los através dos diretórios virtuais /exchange, /public ou /exchweb. Você também pode criar diretórios virtuais OWA personalizados para essas versões anteriores do Exchange Server 2007.

O ISA Server 2006 - seu amigo
O Outlook Web Access executa várias etapas no Exchange Server 2007, mas ele pode ser aperfeiçoado mais ainda através do emparelhamento dele com o Internet Security and Acceleration (ISA) Server 2006.
O ISA Server 2006 é um gateway de margem de segurança integrado. Ao mesmo tempo em que ele ajuda a proteger seu site contra ameaças provenientes da Internet, ele também fornece acesso remoto seguro aos aplicativos e dados. Considerando que essa também é a meta do OWA, o emparelhamento dos dois fornece aquilo que há de mais fabuloso em relação aos conceitos, sinergia da computação. (Para obter informações básicas sobre o ISA Server, consulte microsoft.com/isaserver/2006 (em inglês).)
O ISA Server 2006 fornece várias vantagens para o administrador preocupado do Exchange. Por exemplo, o recurso Web Publishing Load Balancing (WPLB) permite que você equilibre as cargas usando os cookies HTTP. Você pode garantir a afinidade do cliente-servidor, mesmo quando o IP do cliente é alterado. O ISA Server 2006 também fornece a compactação e descompactação GZIP, que permite a você analisar o tráfego ou a compactação de descarregamento dos servidores Web. Com o ISA Server 2004, você tinha que fazer uma escolha: usar a compactação HTTP com o OWA ou usar a autenticação baseada em formulários com o ISA Server. Felizmente, o ISA Server 2006 dá suporte aos dois simultaneamente.
Além disso, você pode executar a conversão de link do OWA através do ISA Server. Se alguém coloca um link da intranet no email do OWA, o ISA Server pode convertê-lo em um link da Internet adequado. Isso pode ser muito útil, mas você precisa se lembrar de publicar os links da intranet para a mesma matriz do ISA que está publicando o OWA.
Talvez o mais importante seja que o ISA Server 2006 executa uma pré-autenticação para ajudar a proteger sua rede no perímetro. A pré-autenticação tem como objetivo garantir que nenhum tráfego HTTP não autorizado atinja seus servidores. Se o tráfego que estiver sendo direcionado para seu CAS for válido, o ISA Server se estenderá do perímetro até o domínio. (Os servidores do perímetro estão localizados fora do domínio da intranet, bloqueando o tráfego não pertencente. Seu CAS não deve ser implantado no domínio do perímetro, ele precisa estar no domínio da intranet, de forma que possa acessar as contas do usuário do Active Directory.)

Como solucionar problemas do Outlook Web Access
O Outlook Web Access 2007 apresenta novas ferramentas que melhoram o monitoramento e a solução de problemas. Uma tarefa de monitoramento é executada automaticamente no servidor CAS. A tarefa testa a conectividade de cada servidor da caixa de correio e também testa os logons do OWA. O Exchange Server 2007 também fornece mensagens muito mais detalhadas de log de eventos e contadores de desempenho.
O Exchange Server Best Practices Analyzer (veja nossa cobertura em microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange) (em inglês) foi aperfeiçoado para alertar os administradores sobre erros e avisos relevantes, se o OWA não for configurado corretamente. Você também pode produzir relatórios de uso do OWA para registros do IIS através da ferramenta LogParser (discutida na edição de outubro de 2006 microsoft.com/technet/technetmag/issues/2006/10/LogParser) (em inglês).

Unificação de Mensagens
Onde o OWA detecta necessidades de negócios móveis, a Unificação de Mensagens consolida diferentes formas de mensagem em um local unificado (por isso o nome inteligente). Até agora, o email reside no Exchange Server. Voz (chamadas telefônicas, correio de voz) está disponível em um servidor telefônico. Você obtém seu email de sua área de trabalho e seleciona o correio de voz através de seu telefone. E nem mesmo comecei a falar sobre as mensagens de fax!
A Unificação de Mensagens do Exchange Server 2007 permite que a organização envie email, dados de voz e fax para uma única caixa de entrada, onde os usuários podem acessá-la pelo Outlook e pelo OWA. A Unificação de Mensagens funciona de outra forma também: os usuários podem acessar o correio de voz, email, contatos e calendários pelo telefone com o Outlook Voice Access.
Para o administrador de sistemas, a Unificação de Mensagens simplifica o envio de mensagens, combinando suas infra-estruturas telefônicas e do Exchange para fornecer uma solução de armazenamento, um diretório e um transporte. O nível geral de complexidade é reduzido quando cada pessoa tem uma única caixa de correio.
A melhor parte disso tudo? Pode ser feito com os servidores existentes e se você conhecer o Exchange Server 2007 e a telefonia, a etapa de aprendizagem será muito simples. Os recursos da Unificação de Mensagens são integrados ao Exchange £ você usa o mesmo modelo de segurança e as mesmas caixas de entrada. Você pode inclusive acessar seu correio de voz e fax pelo OWA.
AFigura 3 mostra a arquitetura da unificação de mensagens no Exchange Server 2007 com a função do servidor de Unificação de Mensagens instalada. Dê uma olhada nisso (pode ser mais tarde) e, em seguida, vamos verificar a arquitetura da Unificação de Mensagens em mais detalhes.
Figura 3 A Unificação de Mensagens colaborando com comunicação de voz, fax e email
Figura 3 A Unificação de Mensagens colaborando com comunicação de voz, fax e email (Clique na imagem para diminuir a exibição)
Figura 3 A Unificação de Mensagens colaborando com comunicação de voz, fax e email
Figura 3 A Unificação de Mensagens colaborando com comunicação de voz, fax e email (Clique na imagem para aumentar a exibição)
Quando você estiver configurando a Unificação de Mensagens em uma empresa, há vários elementos a serem considerados. O Exchange Server contém objetos que representam hardware de telefonia. Esses objetos podem ter seus relacionamentos definidos dentro do ambiente do Exchange Server. Os objetos do sistema de Unificação de Mensagens do Exchange Server incluem o Servidor de UM, o Plano de Discagem de UM, o Gateway IP de UM e o Grupo de Busca de UM, bem como a Diretiva de Caixa de Correio de UM e o Atendedor Automático de UM. Vamos dar uma olhada como cada um desses objetos justificam sua existência.
O objeto Servidor de UM é criado no Active Directory onde a função do servidor UM está instalada. Isso permite que um administrador controle a configuração e as propriedades de uma implantação de Unificação de Mensagens do Exchange Server 2007. O Plano de Discagem de UM é a unidade administrativa básica dentro da Unificação de Mensagens, que representa como as extensões são usadas internamente. Todos os usuários dentro de um plano de discagem podem contatar todas as outras pessoas simplesmente discando seu ramal. Se vocês estiverem conectando-se a outros locais, cada um terá seu próprio plano de discagem.
O objeto Gateway IP de UM representa um gateway físico do protocolo VoIP, ou um protocolo SIP-PBX (Central Privada de Comutação Telefônica) habilitada por IP. Um servidor da unificação de mensagens pode receber chamadas de um dispositivo de gateway de IP/VoIP. Um Grupo de Busca de UM vincula um Gateway de IP a um UM Dial Plan. Após a configuração de um Grupo de Busca no PBX, um Grupo de Busca de UM será criado no Active Directory para representá-lo. Você pode configurar o Grupo de Busca para fornecer balanceamento de carga pelos gateways IP. Esses gateways, por sua vez, podem fornecer balanceamento de carga, associando um Grupo de Busca de UM exclusivo a vários gateways. As Diretivas de Caixas de Correio de UM são análogas para as classes de serviço do correio de voz. Elas incluem um Plano de Discagem e as propriedades que definem as políticas operacionais para usuários e grupos.
O Atendedor Automático de UM pode ser associado a um Plano de Discagem de UM exclusivo. Ele pode ser personalizado para executar várias tarefas, como um registro de prompt personalizado e definir tarefas para diferentes dias e horários. Os Atendedores Automáticos são incluídos no escopo usando as listas de endereços.
A Figura 4 mostra como esses seis objetos da Unificação de Mensagens trabalham juntos.
Figura 4 Interação dos objetos de telefonia da unificação de mensagens
Figura 4 Interação dos objetos de telefonia da unificação de mensagens (Clique na imagem para diminuir a exibição)
Figura 4 Interação dos objetos de telefonia da unificação de mensagens
Figura 4 Interação dos objetos de telefonia da unificação de mensagens (Clique na imagem para aumentar a exibição)

Como configurar
Depois que um usuário tiver uma caixa de correio do Exchange Server 2007, o administrador deverá ativá-la para Unificação de Mensagens. Para fazer isso, o administrador deve associar a caixa de correio a uma diretiva de Caixa de Correio de UM e a um ramal, dentro do Plano de Discagem. O PBX também deve ser configurado para rotear a chamada para a Unificação de Mensagens em um RNA (toque, sem resposta). O PBX roteará primeiro a chamada para o ramal do usuário. Em seguida, se ocorrer RNA, a chamada será roteada para o gateway VoIP e depois para o servidor de Unificação de Mensagens.
A Unificação de Mensagens é escalável. Você pode adicionar os canais de PBX comutados por circuitos e os servidores da UM que forem necessários para atingir a capacidade. Quando você usar os gateways VoIP, as chamadas baseadas em IP serão encaminhadas à Unificação de Mensagens do Exchange. Considerando que essa é uma nova funcionalidade para muitos negócios, você deve fazer uma análise completa da rede para verificar se a sua rede IP tem largura de banda para tratar dados e voz.
Um servidor comum de Unificação de Mensagens do Exchange Server 2007 pode tratar entre 50 e 200 chamadas de IP concorrentes e até 200 chamadas de fax e de voz de entrada (são definidas para 100 por padrão). Você pode criar servidores adicionais de Unificação de Mensagens se precisar de mais capacidade, ou se quiser aumentar sua tolerância a falhas.

Conclusão
Portanto, é isso! O Exchange Server 2007 fornece dois recursos, o Outlook Web Access e a Unificação de Mensagens, que juntos oferecem grandes vantagens a uma organização. O Outlook Web Access permite acesso seguro ao email de qualquer lugar e a Unificação de Mensagens permite que os usuários acessem email, correio de voz, mensagens de fax e outros dados da caixa de correio que podem ser armazenados na caixa de correio do Exchange 2007.

Joshua Trupin é editor executivo da MSDN Magazine e da TechNet Magazine. Ele escreveu vários artigos para MSJ, MIND, MSDN Magazine e TechNet Magazine e também um livro, Hoop Stats: The Basketball Abstract.


 Exchange Server 2007: Registros no di&#225;rio mais sofisticados no Exchange 2007
Exchange Server 2007 David Strome

Registros no diário mais sofisticados no Exchange 2007
Visão geral:
  • Regras de diário do Exchange Server 2007
  • O novo Journal Wizard
  • O que há em um relatório de diário?

Você já teve que registrar em diário as mensagens de email enviadas ou recebidas de um usuário específico e, depois, encontrar as mensagens que estava procurando juntamente com outras mensagens de outras 300 caixas de correio que
residem no armazenamento da caixa de correio? O Microsoft Exchange Server 2007 soluciona esse problema, permitindo o controle granular necessário.
Os registros no diário por destinatário, disponíveis com as CALs (Licenças de Acesso para Cliente) permitem determinar o destinatário do registro. Agora, com o uso das regras de registro no diário, você pode registrar apenas os destinatários e os remetentes que desejar. É possível restringir o foco a uma única caixa de correio ou expandi-la para incluir, por exemplo, todo o pessoal de um departamento de vendas. Suas caixas de correio não precisam estar no mesmo servidor, no mesmo site do Active Directory®, nem mesmo em uma organização do Exchange. Por meio da replicação do Active Directory, suas alterações serão aplicadas automaticamente a todos os computadores que executam a função de servidor Transporte de Hub em sua organização.

Como funcionam os registros no diário
No Exchange Server 2003, os registros no diário foram implementados em armazenamentos individuais de caixas de correio em cada servidor físico. Se você quisesse registrar no diário todas as caixas de correio de sua organização, você teria que configurar os registros no diário de cada armazenamento de caixa de correio. E se quisesse registrar no diário as mensagens de um único destinatário, teria que registrar todos daquele armazenamento de caixa de correio ou criar um novo armazenamento de caixa de correio especificamente para aquele usuário.
Os registros no diário do Exchange Server 2007 utilizam a nova topologia baseada em função do Exchange. Como mostra a Figura 1, todas as mensagens são processadas pelos servidores Transporte de Hub ao entrar ou sair dos servidores Caixa de Correio e Unificação de Mensagens, de outros sistemas do Exchange, de aplicativos de terceiros e da Internet. Todos os servidores Transporte de Hub contêm um agente de transporte chamado agente de registros no diário, que é responsável pela aplicação das regras de registro no diário às mensagens. Como o agente de registros no diário está localizado nos servidores Transporte de Hub, ele encontra e avalia cada mensagem antes que ela chegue a seu destinatário. O agente de registros no diário age nas mensagens após a categorização - isso garante o acesso a todos os atributos de destinatário e remetente da mensagem e, também, permite que o agente determine se a mensagem foi enviada diretamente para um destinatário, ou se ela foi recebida por meio da expansão do grupo de distribuição. Ele também pode dizer se o destinatário estava nas linhas Para, Cc ou Cco de uma mensagem que se originou dentro da organização do Exchange Server 2007.
Figura 1 Fluxo de email do servidor Transporte de Hub
Figura 1 Fluxo de email do servidor Transporte de Hub (Clique na imagem para diminuir a exibição)
Figura 1 Fluxo de email do servidor Transporte de Hub
Figura 1 Fluxo de email do servidor Transporte de Hub (Clique na imagem para aumentar a exibição)
O agente de registros no diário aplica as regras de registro no diário configuradas pelo administrador às mensagens, à medida que elas passam pelo servidor Transporte de Hub. Essas regras determinam se o agente capturará as informações sobre uma mensagem, encaminhando-as juntamente com a mensagem original para uma caixa de correio de diário. Esses dados são enviados em uma mensagem chamada relatório de diário.
Com as versões anteriores do Exchange, você precisava aplicar as configurações a vários servidores. Entretanto, quando você cria uma regra de diário no Exchange Server 2007, aquela alteração é aplicada a todos os servidores Transporte de Hub de sua organização por meio do Active Directory. Todos os servidores Transporte de Hub e, portanto, todos os agentes de registro no diário, lêem a mesma configuração do Active Directory. Assim, essa cobertura ampla garante que todos os agentes de registros no diário apliquem a mesma configuração de registros no diário.
Lembre-se dos tempos de replicação do Active Directory ao criar ou modificar as regras de diário, já que a alteração na configuração precisa ser replicada em toda a sua organização e lida pelos servidores Transporte de Hub. Isso poderia levar várias horas. Para ajudá-lo a identificar quando a configuração dos registros no diário está atualizada, o Exchange registra um evento no log de eventos de segurança de cada servidor.
O Exchange Server 2007 verifica se um relatório de diário não é perdido devido a uma caixa de correio de diário indisponível, esteja ela cheia, configurada incorretamente ou offline. (Isso é particularmente útil para atender os diversos requisitos legais e reguladores, uma vez que mensagens perdidas podem resultar em não conformidade.) Se um relatório de diário não puder ser entregue a uma caixa de correio de diário, o relatório permanecerá na fila do servidor Transporte de Hub até que a caixa de correio do diário fique disponível novamente. Como isso pode resultar em filas que crescem rapidamente, você deve monitorar a disponibilidade de sua caixa de correio de diário para verificar se ela está operando corretamente. Se uma caixa de correio de diário continuar indisponível por muito tempo, você poderá configurar uma alternativa para o recebimento dos relatórios que estão parados na fila.

Decidindo o que registrar no diário
Antes de começar a criar regras de diário, você precisa ter uma idéia clara de quem você deseja registrar e quais são os tipos de dados que devem ser registrados no diário. Ao especificar um usuário em uma regra de diário, você pode selecionar usuários específicos para o registro no diário. Esses usuários podem, por exemplo, estarem sujeitos a requisitos reguladores, ou podem estar envolvidos em ações judiciais que exigem a coleta de mensagens de email e de outras comunicações como evidência.
Além de especificar quais destinatários serão registrados, você também pode determinar o escopo das mensagens a serem registradas no diário, com as opções Interno, Externo e Global. As mensagens internas visam apenas as mensagens dentro de sua organização. As mensagens externas são aquelas nas quais o remetente ou um dos destinatários está fora e as mensagens globais visam as mensagens internas e externas. (Observe que a opção Global registra todas as mensagens que passam por um servidor Transporte de Hub - mesmo aquelas que podem já ter sido processadas usando os escopos interno e externo.)
O Exchange Server 2007 suporta a Unificação de mensagens. Portanto, você pode configurar o Exchange para coletar os emails, o correio de voz e os faxes de um usuário em sua Caixa de entrada. Isso também significa que você pode registrar no diário todos esses dados, ou excluir alguns deles.
Mesmo executando o Exchange Server 2007 com as CALs padrão, é possível usar os registros no diário por armazenamento de caixa de correio. Entretanto, para usar os novos recursos de registros no diário por destinatário, você deverá atualizar para as CALs empresariais do Exchange Server 2007.

Onde colocar a caixa de correio do diário
Após resolver o que deve ser registrado, você precisa decidir para onde enviar os relatórios do diário. Se você tiver vários locais, precisará levar em conta a topologia de rede atual ou planejada ao decidir onde colocar as caixas de correio de diário. Dependendo do tamanho da sua organização e do número de caixas de correio, os registros no diário podem resultar em um número significativo de relatórios repetidos.
Entretanto, você não precisa se restringir às caixas de correio do Exchange. É possível enviar os relatórios de diário para qualquer endereço SMTP válido. Esse endereço pode apontar para o Exchange Hosted Services, para uma solução de arquivamento de terceiros ou para qualquer combinação entre esses dois usando um grupo de distribuição. Cuidado, porém, pois há determinadas implicações de segurança em relação ao local para onde você envia os relatórios de diário.
Independentemente do lugar onde você resolver colocar a caixa de correio do diário, você deve criar um objeto de destinatário para ele no Active Directory. Ele pode ser uma caixa de correio do Exchange Server 2007, um contato habilitado para email que redireciona os emails para o Exchange Hosted Services, uma solução de arquivamento de terceiros ou uma lista de distribuição que contém caixas de correio e contatos.

O que há em um relatório de diário?
Quando o agente de registro no diário registra uma mensagem, ele tenta capturar o máximo possível de detalhes sobre a mensagem original em um relatório de diário. Em seguida, esse relatório é enviado para a caixa de correio do diário. As informações são muito importantes, pois ajudam a determinar a intenção da mensagem, seus destinatários e seus remetentes. Por exemplo, quando os destinatários são identificados - seja diretamente endereçados no campo Para, incluídos no campo Cc ou simplesmente parte de uma lista de distribuição - a determinação do modo pelo qual o destinatário está envolvido na discussão da mensagem é facilitada. A mensagem original é incluída como um anexo. As capturas de telas da Figura 2 mostram um relatório de diário indicando que uma mensagem enviada para david@contoso.com foi encaminhada para christine@contoso.com e outro relatório de diário, indicando que uma mensagem enviada para o grupo de distribuição Sales_Group@contoso.com foi expandida e que o destinatário lukas@contoso.com, que é membro do grupo de distribuição Grupo de vendas recebeu a mensagem. Ambos os relatórios contêm a mensagem original como um anexo, mostram que o remetente original foi brian@contoso.com e têm o assunto “Previsão de vendas”.
Figura 2 Relatórios de diários mostrando um destinatário encaminhado e um destinatário de grupo de distribuição expandido
Figura 2 Relatórios de diários mostrando um destinatário encaminhado e um destinatário de grupo de distribuição expandido (Clique na imagem para diminuir a exibição)
Figura 2 Relatórios de diários mostrando um destinatário encaminhado e um destinatário de grupo de distribuição expandido
Figura 2 Relatórios de diários mostrando um destinatário encaminhado e um destinatário de grupo de distribuição expandido (Clique na imagem para aumentar a exibição)
O Exchange só classifica as informações que considera corretas. As informações que não podem ser determinadas automaticamente são colocadas nos campos apropriados do relatório do diário. A Figura 2 explica os campos que são incluídos no corpo do relatório do diário.

Tudo sobre a segurança
Como padrão, toda comunicação entre computadores com o Exchange Server 2007 na mesma organização do Exchange é criptografada. Essa criptografia inclui os relatórios de diário. O Exchange Server tem várias formas de ajudar a reduzir o risco de violação de relatórios:
  • Links seguros são usados entre os servidores Transporte de Hub e os servidores Caixa de Correio da organização do Exchange 2007.
  • Os relatórios de diário são enviados como “Microsoft Exchange” em nome do remetente da mensagem original.
  • As sessões entre o servidor Transporte de Hub e o servidor Caixa de Correio são autenticadas.
  • Apenas as conexões autenticadas são aceitas quando os relatórios de diário são enviados entre os servidores Transporte de Hub e os servidores Caixa de Correio da mesma organização do Exchange 2007.
Quando você cria uma caixa de correio de diário, deve torná-la segura, uma vez que a caixa de correio contém as mensagens enviadas e recebidas por destinatários de sua organização. Algumas mensagens podem fazer parte de ações judiciais ou estarem sujeitas a requisitos reguladores. Existem diversas leis que exigem que as mensagens permaneçam inalteradas antes de serem enviadas para a autoridade encarregada das investigações. Para aumentar a segurança da caixa de correio do diário, é necessário configurá-la para aceitar apenas as mensagens do remetente do Microsoft Exchange e exigir que todas as mensagens enviadas para a caixa de correio do diário sejam enviadas por remetentes autenticados. A Figura 3 mostra as restrições de entrega de mensagens configuradas em uma caixa de correio do diário. Também é possível usar o seguinte comando do Shell de Gerenciamento do Exchange para configurar essas restrições de entrega de mensagens:
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
Figura 3 Restrições de entrega de mensagens
Figura 3 Restrições de entrega de mensagens (Clique na imagem para diminuir a exibição)
Figura 3 Restrições de entrega de mensagens
Figura 3 Restrições de entrega de mensagens (Clique na imagem para aumentar a exibição)
Se você enviar relatórios de diário para uma caixa de correio de diário fora da sua organização do Exchange Server 2007, será necessária a criptografia manual e tornar segura a conexão entre seus computadores Exchange Server 2007 e o servidor de recepção. Você pode fazer isso exigindo o uso do protocolo TLS entre os dois sistemas, exigindo a autenticação no sistema receptor, aceitando apenas as mensagens do sistema receptor do endereço SMTP do destinatário do Microsoft Exchange (este endereço SMTP será semelhante ao Exchange_UMUnique GUID@contoso.com) e configurando o contato do Active Directory usado para encaminhar as mensagens e aceitar mensagens apenas do destinatário do Microsoft Exchange.

Implementação das regras do diário
Chega de falar. Vamos implementar algumas regras. As regras de diário do agente de registro no diário podem ser configuradas no Shell de Gerenciamento do Exchange ou no Console de Gerenciamento do Exchange. Cada regra pode ser usada para configurar o destinatário, o escopo e as configurações de caixa de correio do diário. Como padrão, as regras do diário são ativadas na criação. O valor especificado para o endereço de email do diário deve ser um objeto de destinatário existente na organização do Exchange Server 2007. Esse objeto de destinatário pode ser uma caixa de correio, um grupo de distribuição, um grupo de distribuição dinâmico ou um contato que envia email para um endereço SMTP.
Ao usar o Console de Gerenciamento do Exchange, o Assistente para Nova Regra de Diário irá orientá-lo na criação de novas regras de diário. Na seção Organization Configuration selecione a função de servidor Transporte de Hub. Em seguida, no painel Ação, clique em New Journal Rule. Aqui você deve fornecer valores para o nome da regra, endereço de email do diário e escopo. Não é preciso especificar um valor para o campo Destinatário se quiser que a regra de diário registre as mensagens de todos os destinatários de sua organização. Você também pode especificar se deseja que a regra de diário seja desabilitada na criação. A Figura 4 mostra uma configuração de exemplo que registra no diário todas as mensagens enviadas por ou para brian@contoso.com. As mensagens registradas no diário são enviadas para a caixa de correio do diário chamada Compliance Mailbox.
Figura 4 Assistente para nova regra de diário
Figura 4 Assistente para nova regra de diário (Clique na imagem para diminuir a exibição)
Figura 4 Assistente para nova regra de diário
Figura 4 Assistente para nova regra de diário (Clique na imagem para aumentar a exibição)
No Shell de Gerenciamento do Exchange você pode usar estes seis cmdlets para administrar o agente de registro no diário:
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
O cmdlet New-JournalRule permite criar uma nova regra de diário. Os critérios básicos para a criação de uma nova regra de diário dessa maneira são iguais àqueles do assistente. Você deve especificar valores para os parâmetros Name, Scope e JournalEmailAddress. Não é preciso especificar um valor para o parâmetro Recipient se quiser que a regra de diário registre as mensagens de todos os destinatários de sua organização. E, se quiser que a regra de diário seja desabilitada na criação, você deve especificar um valor $False para o parâmetro Enabled. Para criar uma regra de diário que tivesse a mesma configuração mostrada na Figura 4, você usaria o seguinte comando:
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
Use o cmdlet Get-JournalRule para exibir uma lista de todas as regras de diário criadas. A execução deste cmdlet sozinho exibe uma lista de resumo de todas as regras de diário configuradas em sua organização e as definições de suas configurações. Se quiser exibir todas as informações disponíveis sobre uma regra de diário, você poderá canalizar o cmdlet Get-JournalRule para o cmdlet Format-List. O pipe envia a saída de um cmdlet para o próximo cmdlet, para que o segundo cmdlet possa fazer o processamento adicional na saída. O cmdlet Format-List, por exemplo, exibe toda a saída que recebe. Para exibir todas as informações disponíveis para a regra de diário criada anteriormente, você pode usar este comando:
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
Os cmdlets Enable-JournalRule e Disable-JournalRule são usados para habilitar ou desabilitar uma regra de diário. Ao usar esses cmdlets, é necessário especificar o nome da regra de diário no parâmetro Identity. Por exemplo, para desabilitar a regra de diário que acabamos de criar use o seguinte comando:
Disable-JournalRule -Identity "Brian Smith Journal Rule"
O cmdlet Set-JournalRule permite modificar uma regra de diário existente. O nome da regra de diário é usado com o parâmetro Identity para dizer ao agente de registro no diário qual regra está sendo modificada. Em seguida, você especifica o parâmetro Recipient, JournalEmailAddress, Scope ou qualquer combinação desses parâmetros juntamente com o novo valor. Por exemplo, use o seguinte comando para modificar o valor armazenado no parâmetro JournalEmailAddress da regra que criamos:
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
Finalmente, você pode usar o cmdlet Remove-JournalRule para remover uma regra de diário existente. Você especifica o nome da regra de diário usando o parâmetro Identity. Para excluir nossa regra de diário de exemplo use o comando:
Remove-JournalRule "Brian Smith Journal Rule"
Ao fazer isso, o Shell de Gerenciamento do Exchange pergunta se você realmente quer excluir a regra de diário. Eis uma última dica: com quase todos os cmdlets, você pode omitir o rótulo do parâmetro Identity e apenas especificar o valor do parâmetro.

David Strome foi redator técnico do grupo de Instrução aos Usuários do Exchange na Microsoft por pouco mais de um ano. Antes de entrar na Microsoft em Redmond, WA, David passou cerca de 10 anos desenvolvendo, implementando e administrando instalações do Exchange Server em várias empresas em British Columbia, Canadá. Ele pode ser encontrado em dstrome@microsoft.com.


 Exchange Server 2007: A luta contra o spam e o phishing com o ID de Remetente
Exchange Server 2007 Craig Spiezle and Alexander Nikolayev

A luta contra o spam e o phishing com o ID de Remetente
Visão geral:
  • Noções básicas sobre ID de Remetente
  • Configuração de ID de Remetente no Exchange Server
  • Benefícios da autenticação

Muitas tecnologias de identificação e filtragem vêm sendo desenvolvidas em resposta à crescente ameaça do spam. Para serem eficazes, elas se apóiam em certas perguntas sobre cada mensagem de email,
como “quem a enviou”. Infelizmente, a pergunta fundamental sobre quem enviou a mensagem não é sempre fácil de ser respondida. Emails são, normalmente, enviados pela Internet sem nenhuma autenticação do remetente ou dos computadores que agem em nome dele. Na realidade, é fácil enviar um email fingindo ser uma outra pessoa, e não há métodos automatizados para a detecção de mensagens falsificadas.
O SMTP, que é usado para enviar e receber emails, não foi projetado para verificar o remetente de uma mensagem de email. Com essa brecha tecnológica, qualquer nome e endereço podem ser inseridos como remetente. Por conseqüência, a filtragem de conteúdo ou medidas anti-spam não podem confiar apenas nas informações do cabeçalho para assegurar que as mensagens realmente venham de onde dizem que vêm.
A autenticação de emails trata especificamente dessa brecha. Com a autenticação, os sistemas de envio e recebimento de emails fazem a validação das mensagens provenientes dos domínios de onde alegam vir. Isso facilita que as organizações filtrem o lixo eletrônico com eficácia, garantindo, dessa forma, que os emails legítimos cheguem a seus destinatários.
Hoje, existem duas abordagens livres de royalties para autenticação de email: SIDF (estrutura de ID de Remetente) e DKIM (correspondência identificada por chaves de domínio). O SIDF é uma solução baseada em protocolo de Internet (IP, Internet Protocol) criada a partir da fusão de SPF (estrutura de diretivas de remetente) e do ID do chamador para emails da Microsoft. Em abril de 2006, a IETF (força-tarefa de engenharia de Internet) publicou as especificações do ID de Remetente na forma das RFCs 4405-4408. Uma coligação de partes interessadas do setor, inclusive a Microsoft, recomenda a implantação do SIDF tendo por base fatores como valor técnico e comercial, estabilidade, maturidade, facilidade de implantação, impacto mínimo no desempenho de entrada ou saída e interoperabilidade com o ecossistema de emails para ISPs e ambientes empresariais.
O DKIM é a combinação das especificações DomainKeys da Yahoo! e de IIM (correspondência por Internet identificada) da Cisco Systems Inc. Em janeiro de 2006, a IETF aprovou a criação de um grupo de trabalho DKIM e a especificação está atualmente sob exame da IETF.
Embora não exista uma solução perfeita para conter o spam, o SIDF representa uma iniciativa significativa do mercado para conter domínios falsificados. Em decorrência disso, trata-se de um componente essencial para a redução de spam e de ataques de phishing e o aumento do crédito e da confiança online. Organizações em todo o mundo estão adotando o SIDF em grande escala. Hoje, mais de 5,5 milhões de empresas e detentores de domínios já publicaram registros SPF e mais de 600 milhões de usuários estão protegidos pelo SIDF. Atualmente, mais de um terço do volume diário de emails do mundo já é autenticado e compatível com SIDF.
O desenvolvimento e a adoção mundial do SIDF não seria possível sem a contribuição e o suporte de muitas organizações e empresas, dentre as quais AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, além de outras.

Noções básicas sobre o ID de Remetente
Alguns levantamentos da indústria indicam que mais de 95 por cento dos atos fraudulentos de phishing provêm de domínios falsificados e têm endereços de email de remetente falsificados. É aí que o SIDF faz uma enorme diferença no que diz respeito ao processamento anti-spam. Sozinho, o SIDF não resolverá o problema do spam, mas contribui muito para minimizar as conseqüências do spam e de ataques de phishing. O SIDF não impede que o lixo eletrônico seja enviado. Entretanto, ele torna muito mais fácil detectar o lixo eletrônico. A estrutura ajuda os remetentes de email a protegerem seus nomes de domínio, reputações e marcas. Ele proporciona uma base sólida para se tomar decisões de filtragem com base na reputação e no comportamento de email do remetente.
O ID de Remetente verifica se cada mensagem de email provém do domínio de Internet do qual alega ter sido enviada. Isso é feito através da comparação do endereço do servidor remetente do email com uma lista registrada dos servidores que o proprietário do domínio autorizou a enviar emails. A verificação é realizada automaticamente pelo ISP (provedor de serviços de Internet) ou pelo servidor de emails do destinatário antes de a mensagem ser entregue à caixa de entrada do usuário.
Observe que o ID de Remetente, ou qualquer outro mecanismo de autenticação, não substitui os sistemas de filtragem de conteúdo. Nem o SIDF, nem o DKIM examinam o conteúdo real da mensagem. Em vez disso, a autenticação notifica o sistema de entrada de emails se a mensagem pode ser validada como oriunda do remetente alegado. Como a maioria dos ataques de spam e phishing não partem, na realidade, do domínio declarado, esta abordagem pode ajudar a identificar automaticamente essas mensagens e separá-las do fluxo de entrada de emails.
Dentro do SIDF, o registro SPF fornece um registro de texto simples de todos os servidores de email de saída associados a um domínio, junto com os respectivos endereços IP. A organização deve publicar o registro SPF no arquivo de zona de servidor de seu DNS, para ser, posteriormente, verificado pelos servidores de email de destino. Configurar um registro SPF é rápido, fácil e grátis. O Assistente de Registro SPF da estrutura de ID de Remetente disponibiliza um processo passo a passo para fazer o levantamento dos servidores de email de um domínio e criar registros personalizados prontos para serem postados. (Os detalhes da publicação de um registro SPF estão disponíveis em microsoft.com/senderid. O assistente pode ser acessado diretamente em microsoft.com/senderid/wizard.)
O servidor de email SMTP de recebimento faz o ping do arquivo de zona do domínio no DNS em busca de um registro SPF existente. Uma vez encontrado, o endereço IP do servidor remetente é comparado com os endereços IP listados. Se houver correspondência, a mensagem será validada como autêntica. Se, por outro lado, o registro SPF no domínio do remetente não corresponder ao endereço IP da origem da mensagem, haverá uma falha que resultará em uma pontuação negativa e sua potencial colocação na pasta de lixo eletrônico. A Figura 1 mostra esse processo.
Figura 1 Verificação dos registros SPF para mensagens de entrada
Figura 1 Verificação dos registros SPF para mensagens de entrada (Clique na imagem para diminuir a exibição)
Figura 1 Verificação dos registros SPF para mensagens de entrada
Figura 1 Verificação dos registros SPF para mensagens de entrada (Clique na imagem para aumentar a exibição)
Com a mensagem marcada, o SIDF permite que o servidor de email destinatário a analise com base em comportamentos passados, na reputação do remetente, em seu conteúdo e em outros critérios que podem ser definidos conforme a necessidade. Esse recurso proporciona garantias extras. Por exemplo, os remetentes de spam podem registrar domínios de aparência enganadora e publicar registros SPF para ludibriar o usuário e a rede de recebimento de forma que pensem que o email provém de um remetente legítimo. E, ainda que a mensagem de email possa passar pela verificação de autenticação, a reputação do remetente como spam será suficiente para bloquear, por no lixo ou excluir a mensagem.

Opções de implantação de ID de Remetente
A autenticação de emails que saem via SIDF não requer nenhuma alteração de infra-estrutura ou atualização de software e não é específica de software de cliente ou servidor. Entretanto, as organizações que quiserem incorporar a autenticação de entrada para proteger as suas empresas e funcionários terão que atualizar seus sistemas de entrada e o MTA (agente de transferência de mensagem) e implantar software ou uma aplicação que aceite SIDF. A maioria dos MTAs de código-fonte aberto e fornecedores de anti-spams líderes do mercado, inclusive o Exchange Server e o Exchange Hosted Filtering da Microsoft®, oferece soluções integradas.
A Microsoft integrou o SIDF em todos os seus produtos de sistemas de mensagens, inclusive Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express e os clientes de colaboração e sistema de mensagens do Office Outlook.
No entanto, nem mesmo a Microsoft está isenta de receber spam. A média diária de tráfego de entrada na Microsoft é de, aproximadamente, 15 milhões de mensagens e, durante ataques recentes de spam, vimos esse volume aumentar de duas até quatro vezes. Em tal ambiente, a rota para a proteção com êxito contra spam reside na implementação vigilante das tecnologias disponíveis.
A Microsoft está executando uma solução anti-spam interna de Exchange Server baseada no filtro de ID de Remetente do Exchange Server 2003 e no agente de ID de Remetente do Exchange Server 2007. Em ambas as versões do Exchange Server, o status do ID de Remetente se baseia na avaliação do registro do ID de Remetente localizado nos servidores DNS correspondentes. O domínio real é determinado pelo exame dos cabeçalhos de mensagem RFC 2822, na seguinte prioridade:
  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From
O domínio do remetente (ou da última entidade responsável por injetar uma mensagem no fluxo de troca de mensagens, pois os sistemas de email podem, legitimamente, encaminhar correspondência em nome de outros servidores de email) é determinado pela localização da primeira definição dos cabeçalhos mencionados, na ordem estabelecida. Se nenhum desses cabeçalhos for encontrado, o SIDF usará o valor SMTP RFC 2821 MAIL FROM.

Configuração do ID de Remetente
No Exchange Server 2007, o agente de ID de Remetente pode ser habilitado nos servidores que possuem a função Transporte de Borda instalada. Se o agente de ID de Remetente estiver habilitado, ele filtrará as mensagens que chegam pelos conectores de recebimento £ todo tráfego de entrada (de origem externa) não autenticado estará sujeito ao processamento de ID de Remetente. No Exchange Server 2003, o status do ID de Remetente permanece de servidor a servidor no blob EXCH50; no Exchange Server 2007 ele também foi adicionado aos metadados de mensagens. No destino final, ambos são convertidos em uma propriedade MAPI para futuro consumo pelo cliente.
A configuração da Filtragem de ID de Remetente no Exchange Server 2003, disponível em Message Delivery Properties, consiste apenas em especificar como o Exchange Server deve manipular validações reprovadas.
Para habilitar o ID de Remetente no Exchange Server 2007, basta abrir o Console de Gerenciamento do Exchange de um servidor com a função Transporte de Borda configurada, selecionar a guia Anti-spam, depois ID de Remetente e, no painel Ações, clicar em Habilitar ou Desabilitar para alternar o agente do ID de Remetente, como mostra a Figura 2. Adicionalmente, é possível usar o Shell de Gerenciamento do Exchange para habilitar ou desabilitar o ID de Remetente, como mostra a Figura 3.
Figura 2 Controles do console de gerenciamento do Exchange para o agente de ID de Remetente no Exchange Server 2007
Figura 2 Controles do console de gerenciamento do Exchange para o agente de ID de Remetente no Exchange Server 2007 (Clique na imagem para diminuir a exibição)
Figura 2 Controles do console de gerenciamento do Exchange para o agente de ID de Remetente no Exchange Server 2007
Figura 2 Controles do console de gerenciamento do Exchange para o agente de ID de Remetente no Exchange Server 2007 (Clique na imagem para aumentar a exibição)
Figura 3 Habilitação do ID de Remetente por meio do Shell de Gerenciamento do Exchange
Figura 3 Habilitação do ID de Remetente por meio do Shell de Gerenciamento do Exchange (Clique na imagem para diminuir a exibição)
Figura 3 Habilitação do ID de Remetente por meio do Shell de Gerenciamento do Exchange
Figura 3 Habilitação do ID de Remetente por meio do Shell de Gerenciamento do Exchange (Clique na imagem para aumentar a exibição)
A caixa de diálogo Propriedades do ID de Remetente refletirá o status do agente, seja habilitado ou desabilitado. A guia Ação oferecerá opções muito similares àquelas disponíveis no Exchange Server 2003 (consulte a Figura 4).
Figura 4 Propriedades da ação do agente de ID de Remetente no Exchange Server 2007
Figura 4 Propriedades da ação do agente de ID de Remetente no Exchange Server 2007 (Clique na imagem para diminuir a exibição)
Figura 4 Propriedades da ação do agente de ID de Remetente no Exchange Server 2007
Figura 4 Propriedades da ação do agente de ID de Remetente no Exchange Server 2007 (Clique na imagem para aumentar a exibição)
Em termos de implementação e funcionalidade do ID de Remetente, não há grande diferença entre o Exchange Server 2003 e o Exchange Server 2007, sendo que o filtro de ID de Remetente (no Exchange Server 2003) e o agente de ID de Remetente (no Exchange Server 2007) usam, ambos, o mesmo algoritmo subjacente para extração e verificação. A gama de ações possíveis também é a mesma: Delete Message (exclusão silenciosa), Reject Message (resposta do protocolo SMTP de nível 500), Stamp the message with the Sender ID result e Continue processing. Esta última opção é a ação padrão em ambas as versões do Exchange Server.
No Exchange Server 2007, os códigos de status FAIL e TempError podem, ambos, disparar uma ação Reject Message (no Exchange Server 2003, somente o código de status FAIL pode disparar essa ação). O agente de ID de Remetente precisa estar explicitamente configurado para disparar a ação Reject Message em mensagens com código de status TempError, porque, por padrão, essas mensagens serão aceitas no sistema, carimbadas com o resultado do ID de Remetente e, em seguida, processadas.
A opção de configuração para tanto é não exposta na interface gráfica de usuário, de modo que você pode usar o Shell de Gerenciamento do Exchange para configurar ações de ID de Remetente para o código com status TempError. Por exemplo, para impor que o agente de ID de Remetente rejeite mensagens com código de status TempError, execute o seguinte cmdlet:
Set-SenderIDConfig -TempErrorAction Reject
A gama de resultados de status e ações possíveis de ID de Remetente no Exchange Server 2007 é similar à do filtro de ID de Remetente do Exchange Server 2003, como mostra a Figura 5.
Figure 5 Status e ações do ID de Remetente no Exchange Server 2007 (Close Figure 5)

Status do ID de Remetente | Descrição | Ações
Neutral | Os dados de ID de Remetente publicados estão claramente inconclusos | Carimbar status
Pass | O endereço IP está no conjunto permitido | Carimbar status
Fail | O endereço IP está no conjunto não permitido | Carimbar status, excluir ou rejeitar
SoftFail | O endereço IP pode estar no conjunto não permitido | Carimbar status
None | Nenhum dado publicado | Carimbar status
TempError | Erro temporário, como servidor DNS não disponível | Carimbar status ou rejeitar
PermError | Erro irrecuperável, como um erro no formato de registro | Carimbar status
O Exchange (se configurado para tal) excluirá somente as mensagens que forem reprovadas pela verificação de ID de Remetente. Nenhum outro resultado disparará a exclusão da mensagem. Mensagens de entrada que resultarem em atribuição dos status Neutral, None, SoftFail, TempError ou PermError serão adequadamente carimbadas e transmitidas para verificação anti-spam adicional. Em alguns casos, quando a mensagem se encontra irremediavelmente mal constituída e o endereço IP FROM está faltando, não é possível carimbar o status de ID de Remetente na mensagem. Nessa situação, a mensagem não é descartada ou rejeitada. Em vez disso, ela será transmitida para processamento adicional sem o status de ID de Remetente e um evento apropriado será registrado para dar ciência disso.
No Exchange Server 2007, é fácil definir domínios remetentes e destinatários de Exchange Server que devem ser excluídos da verificação de ID de Remetente. Mais uma vez, esta opção de configuração está disponível somente no Shell de Gerenciamento do Exchange. Por exemplo, para excluir o domínio contoso.com da filtragem de ID de Remetente, execute o seguinte comando:
Set-SenderIDConfig -BypassedSenderDomains contoso.com
De modo similar, para excluir da filtragem de ID de Remetente mensagens enviadas a destinatários especificados de Exchange Server, execute o seguinte comando:
Set-SenderIDConfig -BypassedRecipients user@contoso.com
No Exchange Server 2007, os valores de configuração de ID de Remetente definidos via cmdlets do Shell de Gerenciamento do Exchange, mas indisponíveis através da interface gráfica de usuário, podem ser facilmente obtidos por meio da execução do comando Get-SenderIDConfig no Shell de Gerenciamento do Exchange, como mostra a Figura 6.
Figura 6 Cmdlets de configuração de ID de Remetente
Figura 6 Cmdlets de configuração de ID de Remetente (Clique na imagem para diminuir a exibição)
Figura 6 Cmdlets de configuração de ID de Remetente
Figura 6 Cmdlets de configuração de ID de Remetente (Clique na imagem para aumentar a exibição)
O Shell de Gerenciamento do Exchange pode ser usado para verificação manual rápida do endereço IP e do nome de domínio correspondente. Para verificar o status de ID de Remetente, execute o seguinte comando:
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
Se o domínio não existir, um resultado semelhante ao da Figura 7 mostrada.
Figura 7 Verificação do status de ID de Remetente de um endereço
Figura 7 Verificação do status de ID de Remetente de um endereço (Clique na imagem para diminuir a exibição)
Figura 7 Verificação do status de ID de Remetente de um endereço
Figura 7 Verificação do status de ID de Remetente de um endereço (Clique na imagem para aumentar a exibição)

Benefícios do ID de Remetente
Além de suas vantagens óbvias na autenticação de mensagens de email e na redução da quantidade de spam recebida pelos usuários, o SIDF, enquanto protocolo, oferece ainda outros benefícios. Durante seu desenvolvimento, a Microsoft se concentrou em várias metas fundamentais, inclusive desempenho, custo, implantação e escalabilidade e interoperabilidade.
O SIDF, primeiro, autentica o remetente do email e permite a aplicação da contagem de pontos da reputação do remetente. Por conseqüência, ele tem o potencial de reduzir significativamente mensagens de spam e emails falsificados, bem como melhorar a capacidade de entrega de emails legítimos, oriundos de remetentes conhecidos e confiáveis. Criar um registro SPF é grátis, de modo que é fácil para qualquer organização tornar-se compatível com SIDF. As organizações que desejarem atender às provisões de um novo padrão devem poder fazer isso. Com o SIDF, para tanto, basta publicar um registro SPF.
O SIDF foi desenvolvido para operar em softwares existentes sempre que possível. Ele pode ser usado com uma vasta gama de arquiteturas de email e software cliente e servidor. Para ser eficaz, todo o serviço de autenticação precisa atender às necessidades dos maiores ISPs de forma tão fácil quanto ao menor servidor de email doméstico. O SIDF pode dar suporte desde um até milhares de servidores de email, mais aqueles que terceirizam seus servidores de email para outras organizações.
Em 18 e 19 de abril de 2007, a Microsoft e um consórcio comercial de mais de 30 organizações e parceiros promoverão a Encontro de Autenticação e Identidade Online, em Boston, Massachussets/EUA. Esse programa de dois dias examinará estudos de caso e oferecerá uma revisão técnica do ID de Remetente, detalhando os valores comerciais da autenticação de emails. Para obter mais informações, visite aotalliance.org/summit2007. Além disso, para obter informações sobre ferramentas e recursos, visite microsoft.com/senderid e microsoft.com/exchange.

Craig Spiezle é diretor de estratégia e planejamento de tecnologia do Windows Live Safety na Microsoft. Como gerente de produtos para autenticação de email, Craig tem sido uma força motriz em trazer o ID de Remetente para o mercado. Começando na Microsoft em 1992, Craig ocupou várias posições de gerência, inclusive de marketing internacional, estratégias de suporte a produtos, OEM e desenvolvimento para mercados emergentes.
Alexander Nikolayev é o gerente de programas da Microsoft encarregado dos protocolos de servidor, núcleo de transporte e componentes anti-spam para Exchange Server e Windows Server. Ele possui título de MBA da Universidade de Mary. Leia as postagens de Alexander no blog da equipe do Exchange em blogs.technet.com/exchange.


 Do Editor: Tentando ajudar
Do Editor
Tentando ajudar

TECHNET MAGAZINE É MAIS do que esta fabulosa publicação que você tem em mãos hoje. Nossa equipe tem trabalhado com afinco para criar um site inovador que tornará nosso conteúdo acessível a mais de um bilhão de pessoas no mundo todo. A partir da edição de novembro, cada artigo estará disponível online em sete idiomas: inglês, espanhol, francês, alemão, russo, chinês simplificado e português (Brasil). Com a inclusão de seis idiomas diferentes (como você já sabe, o site em inglês já está online), aumentamos o número de pessoas que podem usar nosso conteúdo em sua língua materna em mais de 1,6 bilhões. Isso é incrível!
Como se isso não bastasse, introduzimos uma série de recursos que tornam o site mais utilizável. Nossas novas RSS feeds personalizáveis permitem que você selecione nosso conteúdo por data, coluna, autor ou tópico. É possível ainda misturar e combinar. Visite technetmagazine.com/rss para começar a criar suas próprias feeds hoje.
Também estamos lançando novas páginas de tópicos. Se quiser ler tudo sobre o que os profissionais de TI precisam para estarem prontos para o Windows Vista, basta visitar o site technetmagazine.com/vista. Se você é um postmaster, não deixe de conferir o site em technetmagazine.com/exchange. Temos 32 tópicos interessantes em technetmagazine.com/topics e teremos mais novidades em breve. (Desde novembro, tínhamos 43 artigos sobre segurança aguardando pacientemente por sua atenção.)
E isso não é tudo. Agora você pode ter ainda mais insights na revista e no mundo dos profissionais de TI. Joshua Hoffman é o editor técnico e de aquisições da TechNet Magazine e também o responsável pelo blog da revista em blogs.technet.com/tnmag. Também hospedo um podcast mensal em nosso site, em www.technetmagazine.com/podcasts. A cada edição falarei com as pessoas que escrevem os artigos que você lê e irei além das palavras para explicar os porquês por trás de cada texto. Você vai adorar ouvir nossos melhores autores falarem sobre os artigos e o trabalho que fazem.
Todos nós tornaremos a TechNet Magazine o recurso mais útil do mundo para os profissionais de TI. O ano de 2006 tem sido bom, mas queremos ouvir o que mais podemos fazer por você. Se tiver algum comentário, escreva-nos! Nossa linha direta editorial é tnmag@microsoft.com. A caixa de sugestões está sempre aberta.
- JOSHUA TRUPIN

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Kevin Allison, Jessica Arnold, Sebastian Bengochea, Naveen Chand, Li Chen, Alpa Dave, Jill Frank, Mihai Jalobeanu, Darcy Jayne, Harry Katz, Kerry Landen, Todd Luttinen, Brett Muzzey, Bruce Payette, Tony Smith, Shawn Thomas, Jim Truher e Scot Vidican.


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

Faça o teste de sobrecarga de seus aplicativos Web
Ferramenta de sobrecarga de aplicativos Web WAPT
www.loadtestingtool.com
Saber como a última versão de seu aplicativo Web se sairá é crucial para dimensionar corretamente sua infra-estrutura e evitar aqueles momentos de alta pressão em que o CEO vem lhe perguntar por que aparece a resposta "Server Too Busy" (Servidor muito ocupado) quando ela tenta consultar o site. E, se você estiver em busca de um aplicativo Web relativamente de baixo custo e fácil de usar como ferramenta de teste de desempenho e sobrecarga, convém experimentar o WAPT 4.0 da SoftLogica LLC.
O aplicativo pode ser executado na maioria das versões do Windows®, mas é conveniente usar Windows 2000, Windows XP ou Windows Server® 2003 para obter seu potencial total, devido às limitações de soquete das versões anteriores. Como na maioria dos aplicativos de teste de desempenho que emprega usuários virtuais, quanto mais memória, mais rápido o processador, e quanto mais larga a conexão de rede, mais usuários virtuais poderão ser simulados com o WAPT.
A documentação declara um limite de cerca de 2.000 usuários virtuais para um PIV 2.4 com 512 MB de RAM e interface gig-e, mas isso depende do tipo de aplicativo que você está testando e como é configurado o perfil de teste. Um outro fator de variação de seu teste é a demora entre as solicitações, o que o WAPT lhe permite definir como tempo de pensamento do usuário em um perfil de usuário virtual.
Terminada a configuração de um perfil de usuário virtual (é possível ter vários cenários por teste), você pode criar o plano de teste para o perfil. O WAPT divide a seqüência de teste em três seções: Inicial, Principal e Ações finais. Trata-se de separações mais lógicas do que funcionais, mas elas sugerem que você divida sua função de logon ou registro, por exemplo, na seção inicial, e a ação de logout, na seção final. O WAPT permite a inserção manual das solicitações ou a utilização do gravador de navegador integrado para controlar o modo desejado de navegação desse perfil através do site. Em seguida, você pode passar às configurações gerais para determinar qual deve ser o carregamento do teste e se ele deve ser fixo ou adaptado ao volume no decorrer de um período de tempo específico. Durante o teste, o WAPT lhe proporciona uma visão em tempo real das estatísticas de desempenho do seu cenário de teste. E, quando você acabar, poderá salvar os resultados como HTML ou CSV para análises futuras.
Preço: U$ 350 por máquina.
Saber como a última versão de seu aplicativo Web se sairá é crucial para dimensionar corretamente sua infra-estrutura e evitar aqueles momentos de alta pressão em que o CEO vem lhe perguntar por que aparece a resposta "Server Too Busy" (Servidor muito ocupado) quando ela tenta consultar o site. E, se você estiver em busca de um aplicativo Web relativamente de baixo custo e fácil de usar como ferramenta de teste de desempenho e sobrecarga, convém experimentar o WAPT 4.0 da SoftLogica LLC.
O aplicativo pode ser executado na maioria das versões do Windows®, mas é conveniente usar Windows 2000, Windows XP ou Windows Server® 2003 para obter seu potencial total, devido às limitações de soquete das versões anteriores. Como na maioria dos aplicativos de teste de desempenho que emprega usuários virtuais, quanto mais memória, mais rápido o processador, e quanto mais larga a conexão de rede, mais usuários virtuais poderão ser simulados com o WAPT.
Ferramenta de sobrecarga de aplicativos Web WAPT
Ferramenta de sobrecarga de aplicativos Web WAPT (Clique na imagem para diminuir a exibição)
Ferramenta de sobrecarga de aplicativos Web WAPT
Ferramenta de sobrecarga de aplicativos Web WAPT (Clique na imagem para aumentar a exibição)
A documentação declara um limite de cerca de 2.000 usuários virtuais para um PIV 2.4 com 512 MB de RAM e interface gig-e, mas isso depende do tipo de aplicativo que você está testando e como é configurado o perfil de teste. Um outro fator de variação de seu teste é a demora entre as solicitações, o que o WAPT lhe permite definir como tempo de pensamento do usuário em um perfil de usuário virtual.
Terminada a configuração de um perfil de usuário virtual (é possível ter vários cenários por teste), você pode criar o plano de teste para o perfil. O WAPT divide a seqüência de teste em três seções: Inicial, Principal e Ações finais. Trata-se de separações mais lógicas do que funcionais, mas elas sugerem que você divida sua função de login ou registro, por exemplo, na seção inicial, e a ação de logout, na seção final. O WAPT permite a inserção manual das solicitações ou a utilização do gravador de navegador integrado para controlar o modo desejado de navegação desse perfil através do site. Em seguida, você pode passar às configurações gerais para determinar qual deve ser o carregamento do teste e se ele deve ser fixo ou adaptado ao volume no decorrer de um período de tempo específico. Durante o teste, o WAPT proporciona a você uma visão em tempo real das estatísticas de desempenho do seu cenário de teste. E, quando você acabar, poderá salvar os resultados como HTML ou CSV para análises futuras.
Preço: U$ 350 por máquina.

Revisão do livro
Fundamentos de sistemas de redes de conteúdo
www.ciscopress.com
O conteúdo é soberano e o livro Content Networking Fundamentals (Cisco Press, 2006), de Silvano Da Ros, é de grande ajuda para que você alcance um rápido controle para aprimorar sua infra-estrutura de distribuição de conteúdo. O próprio livro se declara "uma introdução abrangente à teoria e às aplicações práticas de sistemas de redes de conteúdo"; e é isso mesmo o que ele é. Embora, obviamente, assuma o viés da engrenagem dos sistemas de rede da Cisco, o livro dá uma boa noção dos diferentes componentes dos sistemas de redes de conteúdo, além de diretrizes práticas para implementar os princípios que sustentam esses sistemas e que são aplicáveis não importando os tipos de produtos de conteúdo em sua infra-estrutura.
O livro começa com uma visão geral de alto nível dos diferentes elementos dos sistemas de redes de conteúdo (que realmente aprimoram o desempenho e a distribuição da comunicação de camada 4 a 7 do modelo OSI). Em seguida, ele investiga os detalhes práticos dos principais formatos de apresentação de conteúdo, como XML, HTML, WAP e transformação de conteúdo por XSLT na borda da rede, além de uma seção sobre distribuição de mídia de fluxo contínuo. Finalmente, ele aborda escalabilidade e disponibilidade, com discussões sobre balanceamento de carga dos servidores (globais e locais), balanceamento de carga de firewalls e uso de dispositivos de cache de conteúdo, como a comutação de serviços de conteúdo da Cisco.
Se você usa comutação de serviços de conteúdo da Cisco em sua infra-estrutura, achará interessante o capítulo sobre comutação de conteúdo protegido. Ele mostra os detalhes da configuração do módulo de serviços de conteúdo para a camada de soquetes protegidos, além da configuração de URL e recriação de cabeçalho. Geralmente, os profissionais de sistemas de redes de qualquer marca acharão o capítulo sobre QoS útil para entender os diferentes mecanismos de filas e o gerenciamento de congestionamentos.
Em suma, embora definitivamente concentrado nas implementações de hardware da Cisco (afinal, é uma publicação da Cisco Press), este livro ajudará você a transformar os jargões de "sistema de redes de conteúdo" em metodologias práticas e aplicáveis à sua infra-estrutura de distribuição de conteúdo.
Preço: U$ 55,00.

Monitore seus serviços
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp
Uma coisa que pode ser o trunfo ou a ruína de um profissional de TI é sua capacidade de detectar (e, espera-se, corrigir) problemas antes dos usuários da organização. Portanto, uma das ferramentas mais importantes que um profissional de TI pode ter é um sistema de monitoramento eficaz que seja capaz de investigar os diferentes serviços fornecidos para verificar se estão sendo executados como devem. O WebWatchBot da ExclamationSoft pode ajudá-lo nisso.
Este aplicativo consegue monitorar cada serviço comum imaginável. Em vez de apenas verificar se um serviço está sendo executado, o WebWatchBot vai um passo além nesse processo. Ele realmente testa os serviços para verificar se estão funcionando de maneira adequada. Por exemplo, ele verifica se um FTP consegue mesmo carregar e descarregar um arquivo, monitora se o DNS consegue executar cada um dos 40 comandos de consulta diferentes e procurar uma cadeia de caracteres na resposta, e testa se o POP3 e o SMTP realmente registram e criam relatórios sobre o desempenho do sistema de emails.
WebWatchBot
WebWatchBot (Clique na imagem para diminuir a exibição)
WebWatchBot
WebWatchBot (Clique na imagem para aumentar a exibição)
Além disso, o WebWatchBot permite o encadeamento de uma seqüência de etapas em uma transação e reporta quaisquer erros ou latência inaceitável (de acordo com os limites que você definir) na transação como um todo. O aplicativo também monitorará URLs HTTP e HTTPS, bem como verificará conteúdos específicos. Você pode, inclusive, configurar monitores de bancos de dados para que executem consultas e comparem os dados com um modelo de resposta.
Preço: U$ 495,95 por licença de usuário.

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


 Windows PowerShell: Comandos simples. Administra&#231;&#227;o sofisticada
Windows PowerShell
Comandos simples. Administração sofisticada
Don Jones
Esta coluna é baseada em uma versão de pré-lançamento do Windows PowerShell. Todas as informações deste artigo estão sujeitas a alterações.

Foi um longo tempo, mas o Windows PowerShell está quase pronto para lançamento. Isso significa que é tempo de os administradores do Windows começarem a ficar alertas. O Windows PowerShell oferece o que talvez seja o modo mais fácil e flexível de automatizar uma grande variedade de tarefas administrativas, fazendo com que você se torne mais eficaz e eficiente em seu trabalho.
Mas, mais importante ainda é que a Microsoft está criando os consoles administrativos gráficos de produtos como o Exchange Server 2007 e o System Center 2007 no Windows PowerShell™. Isso significa que você poderá executar quase todas as tarefas administrativas usando o Windows PowerShell. A Microsoft planeja fazer o mesmo com os recursos administrativos de mais produtos ao longo do tempo. Portanto, o Windows PowerShell poderia, futuramente, se tornar a primeira ferramenta 'faz-tudo' para administrar quase todos os servidores Microsoft. Para ajudar você a se familiarizar, abordaremos o Windows PowerShell regularmente nesta nova coluna. Certifique-se de baixar uma cópia do software.

Poder e simplicidade
Como o nome sugere, o Windows PowerShell é um shell, não diferente do prompt Command (Cmd.exe) que existe desde o Windows NT® 3.1. O Cmd.exe não foi embora, mas com a disponibilidade do Windows PowerShell, há poucos motivos para continuar usando o Cmd.exe.
Usar o Windows PowerShell não é tão diferente de usar o Cmd.exe £ exceto pelo fato de que o Windows PowerShell é bem mais dotado de recursos. Como o Cmd.exe, o Windows PowerShell tem uma linguagem de script interna, apesar de ser muito mais flexível que a linguagem em lotes primitiva do Cmd.exe. Flexível quanto? Com o Windows PowerShell, você pode automatizar tarefas extremamente complexas com uma linguagem que inclui apenas meia-dúzia de palavras-chave internas.
Agora que mencionei o script, devo falar da segurança. O Windows PowerShell beneficia-se do que a Microsoft aprendeu sobre segurança ao longo da década passada. Por padrão, o Windows PowerShell não executará scripts; ele só pode ser usado interativamente para executar comandos individuais. Se você ativar o script, será possível fazer com que o Windows PowerShell execute apenas scripts assinados digitalmente. Tudo isso é para assegurar que o Windows PowerShell não se torne o próximo VBScript £ uma grande linguagem que foi freqüentemente mal utilizada para criar scripts maléficos. O VBScript não está desaparecendo, mas você descobrirá que o Windows PowerShell é mais fácil de usar para muitas tarefas diferentes.
Você pode fazer quase tudo com o Windows PowerShell que faria com o Cmd.exe. Por exemplo, você pode executar o ipconfig e obter o mesmo resultado já conhecido. Mas o Windows PowerShell apresenta um novo conjunto de comandos que não são arquivos executáveis externos. Esses cmdlets ("command-lets") são criados no Windows PowerShell. (Para conhecer alguns dos cmdlets mais úteis quando você começar a usar o Windows PowerShell, consulte a barra lateral "Os 10 principais Cmdlets que você deve usar imediatamente ".)
Os 10 principais Cmdlets que você deve usar imediatamente
  • O Get-Command recupera uma lista de todos os cmdlets disponíveis.
  • O Get-Help exibe informações de ajuda sobre cmdlets e conceitos.
  • O Get-WMIObject recupera informações de gerenciamento usando WMI.
  • O Get-EventLog recupera logs de evento do Windows.
  • O Get-Process recupera um único ou uma lista de processos ativos.
  • O Get-Service recupera um serviço do Windows.
  • O Get-Content lê arquivos de texto, tratando cada linha como um objeto filho.
  • O Add-Content anexa conteúdo a um arquivo de texto.
  • O Copy-Item copia arquivos, pastas e outros objetos.
  • O Get-Acl recupera listas de controle de acesso (ACLs).
Para obter uma lista completa dos cmdlets que fazem parte do Windows PowerShell, acesse windowssdk.msdn.microsoft.com/en-us/library/ms714408.aspx.
(em inglês)
Todos os cmdlets são nomeados em um formato padrão verbo-substantivo, tornando-os fáceis de lembrar e aprender. Por exemplo, executar o cmdlet Get-Command lista todos os cmdlets disponíveis. Talvez o cmdlet mais útil para um administrador seja o Get-WMIObject. Digamos que você quer descobrir qual service pack Server2 está sendo executado. Simplesmente execute:
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
Para descobrir essas mesmas informações usando o VBScript, você teria de escrever diversas linhas de código. Outros cmdlets permitem que você trabalhe com serviços (Start-Service, Stop-Service etc.), processos (Stop-Process e outros), arquivos (Rename-Item, Copy-Item, Remove-Item, Move-Item, por exemplo) e muito mais. Muitos desses cmdlets têm até mesmo nomes de atalho, chamados aliases. No caso do Get-WMIObject, você simplesmente deve digitar gwmi. A execução do Get-Alias fornecerá uma lista desses nomes de atalho.

Por que a preocupação com a orientação a objetos
Construído sobre o Microsoft® .NET Framework, o Windows PowerShell é totalmente orientado a objetos. Geralmente, apenas um desenvolvedor de software ficaria empolgado com isso, mas neste caso, a orientação a objetos resulta em uma grande economia de tempo para os administradores. Isso porque os administradores podem agora trabalhar diretamente com rich objects dentro de um shell baseado em texto. Considere este exemplo:
Get-Process | Sort-Object pm –desc | Select-Object –first 10

Figura 1 Usando um cmdlet simples para resolver problemas (Clique na imagem para diminuir a exibição)
Figura 1 Usando um cmdlet simples para resolver problemas
Figura 1 Usando um cmdlet simples para resolver problemas (Clique na imagem para aumentar a exibição)
O uso de pipes (o caractere de linha vertical geralmente localizado na tecla de barra invertida em teclados no padrão norte-americano) é uma parte essencial do que torna o Windows PowerShell tão capaz. Usando esse caractere, você pode passar objetos (ou enviar por pipe) de um cmdlet para outro, permitindo que cada um refine os resultados, formate-os para exibição, etc. Esse mecanismo funciona porque cada cmdlet retorna um ou mais objetos, em vez de texto puro, dando aos cmdlets subseqüentes o objeto completo com o qual trabalhar.
O uso de objetos no Windows PowerShell expande-se por suas variáveis. E você não tem de declarar variáveis antecipadamente; pode simplesmente começar a usá-las digitando um cifrão ($) antes de um nome de variável. Como isso não é obrigatório, você pode também informar ao Windows PowerShell qual o tipo de dados que deseja colocar na variável. Isso permite que o Windows PowerShell mapeie a variável para um dos tipos extremamente sofisticados do .NET Framework, dando a você muita funcionalidade interna adicional. Por exemplo, suponha que você queira solicitar um nome de computador e recuperar a versão do service pack desse computador, mas não sabe se a pessoa que está digitando o nome do computador incluirá as barras invertidas (como \\Server2). Como você sabe que o cmdlet Get-WMIObject não necessita de barras invertidas, pode salvar o nome do computador em uma variável String e usar o método Replace para substituir as barras invertidas por cadeias de caracteres vazias, conforme mostrado aqui:
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
O valor do parâmetro –Computer foi fornecido pela variável $c. Essa variável foi criada inicialmente como uma cadeia de caracteres, dessa forma ela tem toda a funcionalidade do tipo String do .NET Framework, incluindo o método Replace. É claro que, aprender sobre todas essas capacidades levará algum tempo, mas você verá que elas são fáceis de escolher por meio de exemplos. O Windows PowerShell ajuda a simplificar a aprendizagem. Por exemplo, se você digitar $c = $c. (não se esqueça do ponto final) e pressionar Tab, o Windows PowerShell exibirá Clone(), o primeiro método do tipo de String. Se você continuar pressionando Tab, o Windows PowerShell passará por todos os métodos disponíveis. Essencialmente, quando você faz isso, o Windows PowerShell está lhe mostrando que ele sabe o que fazer com uma String!
Eis uma tarefa mais difícil. Leia uma lista de nomes de computadores de um arquivo, com um nome por linha e mostre o número do service pack de cada computador. No VBScript, essa tarefa exigiria uma dúzia ou mais de linhas de código. No Cmd.exe, você teria de usar um arquivo em lotes complicado. No Windows PowerShell, essa tarefa exige apenas uma linha:
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
O cmdlet Get-Content lê o conteúdo de C:\Computers.txt. Cada linha do arquivo torna-se um objeto por si só. Esse conjunto de objetos – ou seja, nomes de computador – é enviado por pipe para o comando foreach, que é, na verdade, apenas um alias do cmdlet ForEach-Object. Os comandos dentro das chaves são repetidos uma vez para cada objeto enviado por pipe – neste exemplo, isso significa que eles são executados uma vez para cada nome de computador. A variável $_ especial conterá o objeto atual (isto é, o nome do computador atual).
Dentro das chaves estão, na verdade, dois comandos: O primeiro simplesmente exibe o nome do computador atual enviando o conteúdo de $_. O segundo é o, agora conhecido, gwmi. O resultado é uma lista de versões de service pack para cada computador listado no arquivo. Tudo isso foi feito com uma linha de comandos relativamente simples.
Observe que os nomes de parâmetro –Notice e –Computer foram abreviados. O Windows PowerShell exige apenas o suficiente para distinguir exclusivamente os nomes de parâmetros.

Legibilidade e reutilização
Escrever uma única linha de comandos e parâmetros, entretanto, não ajuda na legibilidade. O Windows PowerShell permite que você quebre isso em algo mais legível, que possa ser digitado diretamente no shell sem mesmo ter que escrever um script. Eis um exemplo:
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
Desta vez, o conteúdo do arquivo é armazenado na variável $names. Este exemplo ainda usa foreach, mas ele não está sendo inserido por um pipeline, de forma que você tem de informar em qual conjunto de objetos deve ser feito o loop e em qual variável deve ser armazenado cada objeto – a parte que diz ($name em $names). Tudo o mais é muito semelhante e, assim que você pressionar Enter, o código será executado e os resultados serão exibidos.
Se você quiser usar esse mesmo código várias vezes, poderá simplesmente transformá-lo em uma função. Novamente, digite isso direto no shell:
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
Como você pode ver, quase nada mudou realmente. Isso simplesmente engloba o exemplo anterior em uma função chamada Get-ServicePacks (mantendo a convenção de nomenclatura verbo-substantivo do Windows PowerShell). A função agora tem um parâmetro de entrada denominado $file, que foi substituído no cmdlet Get-Content de forma que um arquivo diferente possa ser especificado quando a função for executada. Agora que a função foi definida, você pode simplesmente executá-la chamando seu nome, quase como um cmdlet, e passando o parâmetro de entrada:
PS C:\> Get-ServicePacks c:\computers.txt
A Figura 2 mostra os resultados.

Figura 2 Resultados da execução da função Get-ServicePacks
O mundo é um arquivo (ou pasta)
Há mais no Windows PowerShell que apenas funções e cmdlets. Vamos dar uma olhada no gerenciamento de arquivos como exemplo rápido do que mais há para conhecer. Você provavelmente está mais do que familiarizado com a navegação em unidades e pastas no Cmd.exe £ digite C: para alternar para a unidade C e digite cd \test para mudar para C:\Pasta de teste. O Windows PowerShell trabalha exatamente da mesma forma, apesar de cd ser apenas um alias para o cmdlet Set-Location.
Tente executar Get-PSDrive, o cmdlet que lista todas as unidades disponíveis. Além das unidades comuns C:, D: e talvez A:, você também encontrará uma chamada Cert, outra chamada Env e outras chamadas HKCU e HKLM. O Windows PowerShell realmente tem vários tipos diferentes de recursos de armazenamento como "unidades", tornando coisas como o armazenamento de certificados local, as variáveis de ambiente e o registro disponíveis por meio de uma interface de navegação familiar semelhante aos arquivos.
Mude para a seção do registro HKEY_LOCAL_MACHINE digitando Set-Location HKLM: (ou cd hklm: se você preferir o atalho) e pressionando Enter. Então, execute cd software\microsoft para mudar para a chave SOFTWARE\Microsoft. Você pode usar dir £ um alias para o cmdlet Get-ChildItem £ para listar as subchaves nessa parte do registro. Se você quiser remover uma chave, use del para excluí-la como se a chave fosse um arquivo ou uma pasta. (Entretanto, seja cuidadoso – sérios problemas podem ocorrer se você remover chaves necessárias ou modificar o registro incorretamente.)
Toda essa flexibilidade vem dos provedores, que mapeiam recursos (como o registro e o armazenamento de certificados) em um formato semelhante ao sistema de arquivos. A Microsoft planeja estender o Windows PowerShell por meio de provedores adicionais, proporcionando a você a capacidade para, por exemplo, navegar por um armazenamento do Exchange Server como se fosse um sistema de arquivos. Esta é uma técnica muito importante, pois ela trabalha com uma grande variedade de repositórios usados pelo Windows e os torna aparentemente idênticos, além de torná-los gerenciáveis por meio de um sistema de comandos e técnicas com os quais você já está familiarizado.

Projetado para segurança
Eu já mencionei que o Windows PowerShell foi projetado tendo em mente a segurança. O recurso de segurança principal no Windows PowerShell é sua diretiva de execução. Por padrão, essa diretiva é definida como Restricted, que pode ser verificado executando o cmdlet Get-ExecutionPolicy. No modo Restricted, os scripts não são executados. Ponto final. Como esse é o modo padrão, o Windows PowerShell não pode ser usado para executar scripts prontos.
Você pode especificar outros modos usando o cmdlet Set-ExecutionPolicy. Eu pessoalmente prefiro o modo RemoteSigned. Isso permite que os scripts locais (mas não os scripts remotos) sejam executados sem assinatura digital, fornecendo a maneira mais fácil de desenvolver e testar scripts. O modo AllSigned não executa quaisquer scripts a menos que eles tenham sido assinados digitalmente, usando um certificado emitido por um editor confiável. Finalmente, a diretiva Unrestricted executa qualquer coisa. Eu não recomendo isso de forma alguma, pois ela abre o Windows PowerShell para executar scripts maléficos que podem encontrar uma entrada em seu computador. Observe que a diretiva de execução também pode ser regida pela diretiva de grupo, que sobrescreve quaisquer configurações locais. (Set-ExecutionPolicy alertará você se a diretiva de grupo estiver sobrescrevendo suas configurações locais.)
Além disso, o Windows PowerShell não executará scripts a partir do diretório atual a menos que você especifique o caminho. Isso é projetado para evitar comandos hijacking. Digamos que alguém crie um script chamado IPConfig.ps1 (PS1 é a extensão dos arquivos de script do Windows PowerShell). Se os arquivos pudessem ser executados fora da pasta atual, haveria um risco em digitar ipconfig e executar esse script criado pelo usuário quando, de fato, você estaria esperando executar o programa Ipconfig.exe do Windows. Como o Windows PowerShell não executa scripts fora da pasta atual, esse erro não ocorre. Se você quiser executar um script fora da pasta atual, apenas especifique o caminho: .\meuscript, por exemplo. A referência explícita à pasta atual assegura que você sabe que está executando um script e não um comando do shell.
O Windows PowerShell também tem recursos que tornam a experimentação mais segura. Por exemplo, considere (mas, por favor, não tente) esta combinação:
Get-Process | Stop-Process
O cmdlet Get-Process cria um conjunto de objetos de processo e os envia por pipe ao cmdlet Stop-Process £ que, de fato, os interromperá! O resultado será uma tela azul de erro STOP após cerca de cinco segundos após os processos críticos do Windows serem eliminados. Mas você verá o que aconteceu, sem realmente deixar que aconteça, adicionando o conveniente parâmetro Whatif:
Get-process | Stop-Process -Whatif
Executar isso no Windows PowerShell resulta em um conjunto de instruções que informam a você o que os cmdlets teriam feito sem realmente deixar que aconteça. O sistema de ajuda online do Windows PowerShell (accessível pelo uso do alias help) ainda não aborda o parâmetro –Whatif, mas tem isso em mente. Ele é uma ótima ferramenta para testar scripts e cmdlets para verificar seus resultados sem realmente fazer algo potencialmente nocivo ou que cause interrupção.

Conclusão
Entre os recursos que não fazem parte desta versão do Windows PowerShell, talvez o mais significativo seja o suporte ao Active Directory® Services Interface (ADSI). Apesar de o Windows PowerShell poder utilizar as robustas classes .NET que trabalham com o Active Directory e outros serviços de diretório, ele não tem ainda um cmdlet Get-ADSIObject conveniente. O resultado é que é um pouco mais difícil trabalhar com os objetos de diretório.
Além disso, o Windows PowerShell freqüentemente oferece várias maneiras de executar a mesma tarefa. Isso é bom, mas pode tornar a aprendizagem do Windows PowerShell um pouco mais confusa, uma vez que, para qualquer tarefa, há meia-dúzia de exemplos diferentes de como fazê-la.
Tudo isso será avaliado ao longo do tempo e a equipe do Windows PowerShell continuará a adicionar recursos e capacidades ao produto. Para manter-se atualizado, visite o blog da equipe.

Don Jones é o fundador de ScriptingAnswers.com e co-autor do Windows PowerShell: TFM (SAPIEN Press, 2006). Ele pode ser contatado pelo email don@scriptinganswers.com.


 Post Mortem: Como migrar do Exchange 5.5
Post Mortem
Como migrar do Exchange 5.5
Whitney Roberts

O PROJETO
O Kentucky Department of Education precisava migrar da sua implementação existente do Microsoft® Exchange Server 5.5 para o Exchange Server 2003. O sistema fornece suporte a aproximadamente 600.000 pessoas entre corpo docente, funcionários e estudantes durante o ano escolar.
OS PARTICIPANTES
O projeto foi realizado pelo OET (Office Education Technology) do Kentucky Department of Education, auxiliado pelos consultores de tecnologia da KiZAN. Os funcionários do OET forneceu supervisão de gerenciamento da implementação do Exchange 5.5 existente. A execução diária dos servidores do Exchange era de responsabilidade dos funcionários locais nas escolas.
OS DESAFIOS
O Department of Education fornece orientação técnica para todas as 178 escolas da Comunidade de Kentucky. Essas escolas são conectadas umas às outras através de uma WAN, mas cada uma hospeda seu próprio servidor Exchange 5.5 gerenciado localmente, que precisava ser atualizado separadamente. Essa atualização daria suporte aos clientes do modo cache do Outlook® 2003 e melhoraria o desempenho do OWA (Outlook Web Access), um esquema de endereçamento de email padronizado, e muito mais.
Além de implantar uma nova infra-estrutura de cliente e servidor de email, muitas escolas adicionaram suporte de email para os alunos. A diretiva estadual e federal exigia que as informações dos alunos fossem protegidas e não ficassem visíveis fora da respectiva escola.
O PLANO
Considerando que um ADC (Active Directory® Connector) não poderia ser usado, criamos uma nova organização do Exchange e fizemos a migração para ela. Padronizar os endereços de email significava criar novos endereços, identificando os subdomínios para cada escola e mais de 400 novas diretivas de destinatário. A proteção dos endereços dos alunos exigia a construção de um sistema de GALs (Listas de Endereços Globais) e uma lista de endereços personalizada para cada uma das escolas.
A migração real envolveu preparação de novo hardware, criação e configuração de caixas de correio com base na associação da escola e no tipo de usuário e configuração dos atributos de extensão com base na associação da escola e no tipo de usuário, de forma que o usuário fosse exibido nas listas de endereços apropriadas.
Criamos um aplicativo baseado no Visual Basic® para detectar e corrigir atributos da conta ou associações de grupo mal configurados e para configurar novas caixas de correio adequadamente para verificar se os requisitos foram mantidos. O aplicativo foi implantado para todas as 178 escolas e executado regularmente a partir dos servidores da escola.

Informações gerais
À primeira vista, isso não parece um trabalho desafiador ou tecnicamente difícil. No entanto, conforme eu humildemente descobri, a regra dos requisitos de negócios e os requisitos de negócios deste projeto foram surpreendentes.
Durante anos, o gerenciamento descentralizado e uma mistura de padrões criaram vários "silos" de suporte que tinham que ser gerenciados mais freqüentemente pelo OET. Além disso, o OET também tinha que verificar se a implementação do Exchange 5.5 atendia aos requisitos das escolas e do Department of Education simultaneamente. Isso significava que, para as escolas que utilizavam emails de alunos, as informações dos alunos estavam protegidas e não ficavam visíveis fora da respectiva escola, conforme estabelecido pelas diretrizes estaduais e federais (consulte ed.gov/policy/gen/guid/fpco/ferpa/index.html (em inglês)).
No Exchange 5.5, essas diretrizes significavam que as informações dos alunos dentro da escola não poderiam ser replicadas para outras escolas ou outros órgãos estaduais que compartilhavam os dados da GAL. Especificamente, era necessário passar pelo processo de importação/exportação manual de cada um dos 178 sites do Exchange 5.5: ocultar os alunos, replicar a lista, mostrar os alunos e, finalmente, importar a lista de endereços novamente. Dessa maneira, outras escolas visualizariam apenas os dados dos funcionários e a escola proprietária visualizaria todos os seus próprios dados, mas somente os dados dos funcionários de outras escolas.
Com os pontos fortes e fracos do sistema existente, a atualização da infra-estrutura de mensagens tinha que atender a alguns critérios específicos. Primeiro, o Kentucky Department of Education queria padronizar em um esquema de nomeação SMTP comum e legível para toda a empresa. O esquema precisava fornecer espaços de endereço SMTP separados para corpo docente e alunos.
O novo sistema também precisava fornecer um serviço gerenciado centralmente, que removeria da escola o gerenciamento de mensagens e a responsabilidade pela disponibilidade. Isso significava centralizar o gerenciamento da recuperação do desastre, do fluxo de mensagens e da resolução de chamadas da assistência técnica. Assim, o novo sistema tinha que fornecer um método centralizado para padronização da configuração dos usuários por todas as escolas, independentemente do local geográfico ou da afiliação da escola de um determinado usuário.
Além disso, o novo sistema tinha que fornecer acesso seguro pela Web e por dispositivos móveis a emails através de um namespace comum e unificado para todas as escolas.
Com esses requisitos, muitos dos quais ainda não implementados no sistema Exchange 5.5 existente, a atualização para o Exchange 2003 parecia difícil.

Blocos de construção da solução
Para atender aos requisitos de negócios, várias opções específicas do Exchange foram definidas para a implantação.
Devido à falta de padronização e à amplitude do ambiente do Exchange 5.5, um ADC não poderia ser utilizado. Em vez disso, criamos uma nova organização do Exchange e fizemos a migração para ela.
A limpeza e a padronização dos endereços de email dos funcionários e dos alunos de cada escola levaram à criação de mais de 400 novas diretivas de destinatário. Os requisitos exigiam um subdomínio de identificação exclusivo para cada escola, incluindo uma designação de escola identificadora para os alunos. Por exemplo, no caso do Distrito de Shelby, o subdomínio principal seria shelby.kyschools.us. Os alunos de cada escola receberam uma designação de subdomínio stu., assim os alunos do distrito de Shelby teriam o endereço stu.shelby.kyschools.us.
Outra restrição era que os endereços dos alunos deveriam ficar visíveis somente dentro da escola dos alunos, enquanto os endereços dos funcionários poderiam ficar visíveis em todas as escolas. Isso levou à construção de um sistema elaborado de GALs e de listas de endereços personalizadas, conforme mostrado na Figura 1 e na Figura 2. Uma vantagem de mudar para o Exchange 2003 era que as listas de endereços poderiam ser protegidas com permissões e o acesso a cada lista de endereços individual poderia ser controlado pela associação em grupos. Aproveitamos bem esse recurso e criamos dois grupos de segurança em nível de escola (um para funcionários e outro para alunos). Protegemos os funcionários da escola correspondente, as GALs dos alunos e as listas de endereços, de forma que somente as contas de usuários de dentro de uma escola específica tinham acesso a determinadas listas de endereços. Com a remoção da GAL padrão e das listas de endereços e nos certificando de que os grupos Todos e Usuários autenticados não estavam listados na ACL (lista de controle de acesso) de cada lista de endereços, poderíamos selecionar antecipadamente a lista de endereços que um tipo de usuário específico, em uma escola específica, poderia visualizar.
Figura 1 Listas de endereços personalizadas com base na função
Figura 1 Listas de endereços personalizadas com base na função (Clique na imagem para diminuir a exibição)
Figura 1 Listas de endereços personalizadas com base na função
Figura 1 Listas de endereços personalizadas com base na função (Clique na imagem para aumentar a exibição)
As permissões, no entanto, somente resolveram uma parte do problema de visibilidade. Tivemos que descobrir uma forma de controlar quem ficava visível e em qual lista de endereços. Foi criada uma consulta de protocolo LDAP base, que permitia a consulta da visibilidade de funcionários e alunos. A consulta foi personalizada para cada lista de endereços e GAL. Por exemplo, a consulta LDAP à GAL dos funcionários de Shelby mostraria somente os funcionários e os alunos apropriados em Shelby e todos dos funcionários (mas nenhum aluno) de cada escola do estado. A GAL dos alunos de Shelby mostraria somente os funcionários e os alunos de Shelby e nenhum outro funcionário ou aluno de qualquer outra escola do estado. Repetimos essa consulta para todas escolas da organização. A Figura 3 mostra exemplos de algumas consultas LDAP usadas nesta migração complexa.
Figure 3 Consultas LDAP da lista de endereços (Close Figure 3)

Consulta LDAP da GAL dos funcionários
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Consulta LDAP da lista de endereços da escola
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
Consulta LDAP da lista de endereços dos alunos da escola
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
Consulta LDAP da lista de endereços offline dos funcionários da escola
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Figura 2 Listas de endereços globais separando os funcionários e os alunos
Figura 2 Listas de endereços globais separando os funcionários e os alunos (Clique na imagem para diminuir a exibição)
Figura 2 Listas de endereços globais separando os funcionários e os alunos
Figura 2 Listas de endereços globais separando os funcionários e os alunos (Clique na imagem para aumentar a exibição)
Os valores personalizados para extensionAttribute14 (Atributo personalizado 14) e extensionAttribute15 (Atributo personalizado 15) das propriedades dos usuários do Exchange foram os mecanismos de distinção das consultas LDAP. Todos os funcionários e alunos de todo o estado utilizaram um valor específico para extensionAttribute14 para designar o tipo de usuário e um valor exclusivo no extensionAttribute15 para mostrar a afiliação da escola. Com a utilização de valores exclusivos para cada escola e os mesmos valores para cada tipo de usuário, as listas de endereços foram capazes de mostrar exatamente as informações necessárias para cada tipo de usuário em cada escola.
Essas listas de endereços funcionaram um pouco melhor para os usuários que acessaram emails pelo Outlook no modo não cache ou por meio o OWA. (Direcionamos cada usuário para a lista de endereços correta no OWA, utilizando o atributo msExchQueryBaseDN.) Mas os usuários que estavam executando o Outlook no modo cache apresentaram outro problema. Como o Outlook não distingue uma GAL personalizada como OAB (Catálogo de Endereços Offline), tivemos que criar listas de endereços adicionais que foram duplicadas das GALs. Cada armazenamento de caixa de correio da escola foi configurado com a lista de endereços OAB apropriada para seus usuários do modo cache. Enfim, essa solução atingiu mais de 1.500 listas de endereços para fornecer a funcionalidade total a vários tipos de usuários por todas as 178 escolas.

Como garantir a conformidade
Para verificar se a estrutura que estava sendo utilizada funcionaria corretamente, a aderência aos padrões estabelecidos mais recentemente era fundamental. Havia várias tarefas de alto nível que tinham que ocorrer para cada usuário habilitado para Exchange na organização. O motivo para isso é que cada usuário precisava ser localizado corretamente por todos os servidores Exchange da escola, bem como ficar visível nas listas de endereços corretas.
O usuário precisava ser membro do grupo de segurança adequado dentro do domínio da escola, pois o grupo de segurança concedia permissões para abrir a lista de endereços apropriada. O usuário também precisava que o atributo msExchQuerybaseDN fosse definido corretamente, com base na associação da escola ou na OU (unidade organizacional). A OU do usuário determinava o tipo de usuário.
A próxima etapa era criar a caixa de correio do usuário no armazenamento correto do servidor apropriado, com base na associação da escola e no tipo de usuário. Isso afetou os níveis de serviço, os limites de tamanho da caixa de correio e as listas de endereços do catálogo de endereços offline, de forma que o modo armazenado em cache do Outlook funcionasse corretamente. Os atributos de extensão foram configurados com base na associação da escola e no tipo de usuário, de forma que o usuário fosse exibido nas listas de endereços apropriadas e não ficasse visível em outras.
Finalmente, precisávamos fornecer uma forma de corrigir automaticamente todos os atributos da conta ou associações em grupos, se eles estivessem mal configurados (ou alterados) com valores inadequados. Se um usuário fosse movido de uma OU para outra dentro do domínio da escola, isso significava que uma alteração da classificação do usuário, o local da caixa de correio, a seleção da GAL e a visibilidade da lista de endereços deveriam ser alteradas.
Precisávamos de um sistema de configuração que realizasse essas tarefas e garantisse a consistência e a precisão do Active Directory. Criamos um aplicativo de console baseado no Visual Basic que é executado regularmente a partir dos servidores Exchange 2003 da escola. O aplicativo, que verifica a aderência aos padrões e às diretivas e também trata da criação e da configuração de novos objetos, foi implantado em todas as 178 escolas.
Sentimos que as tarefas eram muito complexas para que uma série de scripts as executasse de forma rápida e confiável. Como resultado, o aplicativo baseado no Visual Basic foi visto como a solução mais apropriada, pois era eficiente, tinha suporte estruturado a tratamento de exceções e erros e seu código interno poderia facilmente ser adaptado ao código de extensão MIIS (Microsoft Identity Integration Server) no futuro, com o mínimo de recodificação.
Como estávamos migrando para uma nova organização, era necessário encontrar alguns métodos de coexistência. Havia mais de 178 domínios SMTP herdados para suportar no novo ambiente - algumas escolas já tinham domínios de emails de alunos e outras não tinham - mas tínhamos a vantagem de migrar as escolas uma de cada vez e trazer seus endereços e mensagens herdadas para o novo sistema, sem afetar as outras escolas. No entanto, precisávamos evitar a interrupção do fluxo de emails, pois a escola foi migrada do Exchange 5.5 para o Exchange 2003. Isso significava a implementação de algum tipo de sincronização de diretório entre o Active Directory do Exchange 2003 e o diretório herdado do Exchange 5.5. A Microsoft concedeu uso limitado de MIIS ao Kentucky Department of Education apenas durante a migração, assim, um código de extensão personalizado foi desenvolvido e usado para sincronizar as organizações do Exchange através do MIIS antes, durante e após a migração.
A mudança para uma nova organização do Exchange naturalmente afeta a configuração do cliente MAPI. O Department of Education se deparou com o fato de que havia literalmente dezenas de perfis MAPI, em nível de escola, que teriam que ser reconfigurados durante a migração. Felizmente, a Microsoft lançou o Exchange Profile Tool (ExProfRe.exe), que foi usado para migração do perfil nas escolas. Criamos um instalador empacotado que executava a ExProfRe.exe com valores pré-carregados, de forma que as migrações do perfil em nível de escola poderiam ser executadas em um modo automatizado. O programa foi chamado através da Diretiva de Grupo. Atingimos quase 100% de sucesso nas migrações de perfil automatizadas entre as organizações.

Atualizações de hardware
Considerando que os servidores Exchange 2003 substituiriam os servidores Exchange 5.5 dispersos geograficamente, o aspecto do hardware desta solução tinha que suportar o mesmo número de usuários que a implantação do Exchange 5.5, mais a carga de contas adicionais dos alunos. Os servidores teriam que ser hospedados localmente na escola, pois a topologia WAN foi projetada de forma que todo o tráfego entre as escolas (Internet e interno) fluísse por uma linha T1 privada (em algumas escolas, por várias linhas T1).
Devido às restrições orçamentárias, de hospedagem de equipamentos e de gerenciamento, os servidores Exchange não teriam armazenamento conectado do tipo SAN (rede de área de armazenamento), portanto, todo o armazenamento tinha que ser conectado interna ou diretamente. Como muitas escolas não tinham centros de dados com armazenamento em rack e resfriamento centralizado, os servidores tinham que ficar autocontidos o máximo possível. Felizmente, a maioria das escolas tinha menos de 5.000 usuários, ou seja, eram possíveis as implantações com um só servidor. Para as escolas que tinham mais usuários, foram utilizados servidores mais avançados (ou vários servidores) e sistemas de armazenamento adicionais, às vezes com servidores front-end para melhorar e separar ainda mais o tráfego dos alunos e o tráfego dos funcionários.
Na maioria das escolas conseguimos implantar servidores biprocessados e bem equipados que foram configurados com o número máximo de unidades Ultra320 SCSI de 15.000 RPM, múltiplos controladores RAID e 4GB de RAM. As escolas maiores receberam um ou mais servidores com quatro processadores, usando servidores front-end menores, quando necessário. Testes de benchmark e de desempenho antes da implantação indicaram nenhum problema de uso ou de carga. No entanto, os diversos níveis de uso local, no entanto, seriam o fator que realmente determinaria o desempenho geral do servidor.

Teste de verificação do conceito
Embora o ambiente de produção possua uma floresta de 178 domínios do Active Directory, o laboratório POC (Verificação do conceito) foi reduzido para 13 domínios da escola e um domínio-raiz vazio. Todos os domínios de teste foram populados com exportações dos domínios de produção. Servidores Exchange 5.5 virtuais foram criados e configurados com cópias dos bancos de dados das escolas selecionadas para que pudéssemos testar o processo de migração e nos basear no ambiente planejado. O laboratório de teste POC completo foi construído com máquinas virtuais para que o ambiente pudesse ser comparado, congelado e reimplantado, quando necessário.
Uma combinação diversa de scripts (usando VBScript), pacotes do instalador SMS (Systems Management Server) e aplicativos de console foi criada, codificada, testada e finalizada. No fim, tínhamos scripts que executavam a configuração inicial do Exchange 2003, incluindo diretivas de destinatário, GALs e listas de endereços personalizadas e permissões. Os scripts também tratavam da configuração do grupo administrativo, da configuração do domínio da escola (criação do grupo de segurança e delegação de permissões) e da configuração pós-implantação para migração.
A preparação dos servidores Exchange 2003 apresentou alguns desafios significativos. Precisávamos que todos os servidores Exchange fossem instalados com êxito em todos os 178 domínios e tínhamos que fazer isso sem prejudicar o restante da migração. O Exchange 2003 difere do Exchange 2000, pois o grupo dos Servidores de Domínio do Exchange específico só é adicionado à ACL da organização depois que o primeiro servidor Exchange 2003 é instalado no domínio. (No Exchange 2000, o grupo é adicionado ao executar o processo DomainPrep.) Para verificar se tínhamos todos os grupos de segurança necessários listados no objeto da organização do Active Directory, precisávamos fazer a instalação em um determinado domínio, replicar manualmente o Active Directory do domínio para o site de hub de replicação do Active Directory e passar essa replicação para a próxima escola a ser instalada. Somente depois que confirmávamos que a ACL no objeto de organização tinha o grupo Servidores de Domínio do Exchange da escola anterior, a instalação da próxima escola poderia começar de forma segura. Se esse processo fosse concluído com problemas, mesmo um só domínio, a escola teria que ser reinstalada (no mínimo) ou as outras escolas não seriam capazes de estabelecer comunicação entre as escolas, devido a uma ACL do objeto da organização que não listou todas as outras escolas corretamente.
Testamos a implantação completa, a configuração, a preparação do servidor e a migração várias vezes, até nos certificarmos de que o processo funcionava bem dentro do ambiente POC.

Problemas de migração e de crescimento
Depois que os procedimentos POC e os resultados foram aprovados pela equipe do projeto, a migração estava pronta para começar. O OET optou por fazer a migração primeiro, de forma que eles pudessem experimentar o processo e os efeitos posteriores em primeira mão. No momento da migração, todos os servidores já tinham sido preparados e o ambiente inicial tinha sido verificado. Todos os servidores do protocolo front-end e os servidores da caixa de correio estavam instalados e prontos para entrar em produção com os usuários.
A execução do plano de migração ocorreu bem e, após longas 21 horas para transferir o conteúdo de um servidor para outro, o OET estava ativo e funcionando no Exchange 2003. Felizmente, não houve problemas significativos com a migração dos perfis do Outlook do Exchange 5.5 para o Exchange 2003. Empacotamos um arquivo de lote que chamava o programa ExProfRe.exe em diferentes configurações, com base em uma lógica simples. Distribuímos o arquivo de lote e o ExProfRe.exe para o compartilhamento Netlogon de um DC (controlador de domínio) em cada escola e usamos a Diretiva de Grupo para executar o lote para todos os clientes, na conclusão de uma migração. Isso funcionou bem no OET e ficamos confiantes em relação ao avanço do processo.
Neste ponto, o plano de migração foi revisado e aprovado novamente com base em nossa experiência com a implantação do OET. Continuando com a migração, escolhemos seis escolas para serem os primeiros sites de produção. Antes de cada escola ser migrada, o MIIS lia as últimas informações sobre as caixas de correio da escola do Exchange 5.5 e atualizava os usuários correspondentes no domínio da escola. Usamos o Assistente de Migração do Exchange (Mailmig.exe) para mover realmente os dados de caixas de correio entre as organizações. À medida que o assistente movia os dados de caixas de correio, todos os endereços proxy eram copiados e atualizados a partir do que o MIIS havia originalmente exportado para o Active Directory. Durante a migração, os emails eram colocados em fila nos servidores SMTP front-end e liberados para a escola após a conclusão da migração, da configuração do servidor pós-migração e do teste de usuários. A escola foi preparada para executar a migração de clientes em grande escala usando o ExProfRe.exe.

Discutindo o RUS
Para que os clientes Outlook funcionassem corretamente, precisávamos garantir que a solução de configuração era a autoridade mais importante na configuração dos valores de atributos. Também precisávamos que o RUS (Serviço de Atualização de Destinatário) finalizasse o trabalho, por assim dizer, de configuração de contas, mas o RUS deveria ser executado somente após a conclusão da configuração. Para conseguirmos isso, as instâncias do RUS das escolas (todas as 178) foram definidas para Nunca em suas programações e a solução de configuração usou um código que disparou o RUS para ser iniciado após a configuração ser concluída.
A maioria das escolas tinham menos de 5.000 usuários e muito menos atualizações diariamente, portanto, o RUS terminou rapidamente devido ao sistema de configuração ter iniciado uma atualização, em vez de ter recriado no fim de sua execução diária. No entanto, havia muitas escolas com mais de 10.000 usuários. As atualizações nesses ambientes consumiu mais tempo e, se uma recriação de RUS completa fosse necessária nesses domínios maiores, ela poderia ser executada durante uma semana ou mais. Considerando que o RUS avalia todos os tipos de objeto quando é executado, o efeito de fazer uma recriação em um domínio tão grande era impactante.
Apesar de não termos conseguido definir uma estratégia de mitigação (e trabalhamos com membros do grupo de produtos do Exchange para tentar descobrir uma solução), aperfeiçoamos o código de configuração para tratar grande parte do que o RUS normalmente faz. Os atributos showInAddressBook e proxyAddresses dos usários eram populados durante a configuração inicial, de forma que os usuários pudessem efetuar logon imediatamente, em vez de aguardar o RUS concluir seu trabalho. Também criamos uma tarefa manual que é executada em um dos servidores de protocolo Exchange 2003 front-end. Ela faz uma importação LDIFDE temporizada e limpa o endereço gatewayProxy do RUS. Dessa forma, se a diretiva do destinatário for aplicada acidentalmente no ambiente, ela não será colocada na lista de tarefas de cada RUS na empresa.

Problemas do categorizador
Um aspecto interessante de impedir que os dados dos alunos fossem acessados fora da escola foi implementar controles para evitar que os alunos enviassem emails a usuários de fora da própria escola ou endereços da Internet fora do sistema. Em vez de trabalhar com um sistema elaborado de conectores e itens relacionados, decidimos implementar um recurso menos conhecido do Exchange 2003 e usar as restrições de conector no Conector de Grupos de Roteamento existente da escola para o hub central onde os servidores de protocolo front-end residem. Dois grupos de segurança foram criados em cada domínio – um para os funcionários e um para os alunos – e esses grupos foram adicionados às restrições do conector.
Depois que habilitamos a verificação de restrição do conector no Registro, começamos a observar alguns problemas de desempenho. As mensagens ficavam presas no categorizador e nas filas de entrega local durante horas, mesmo as mensagens destinadas aos destinatários do mesmo servidor. Esses problemas pioraram ao longo do tempo, conforme escolas adicionais foram migradas. Como uma solução de curto prazo, desativamos a verificação de restrição do conector e o desempenho de entrega de emails melhorou. Além disso, a inspeção revelou que o categorizador estava verificando não apenas as associações do grupo de dois grupos dentro de seu próprio domínio até o envio da mensagem, mas também as associações do grupo dos mesmos dois grupos em outros 177 domínios. Isso era feito para todas as mensagens que entravam ou saíam do servidor.
Posteriormente, abrimos um caso de suporte com a Microsoft. Após avaliação, a Microsoft está atualmente no processo de geração de um hotfix para minimizar o problema, permitindo que o categorizador trabalhe em um modo de complexidade de topologia reduzido. Outros detalhes sobre o hotfix não estão disponíveis, mas a meta é fornecer uma configuração que permita que o categorizador faça determinadas suposições sobre a topologia de roteamento e não verifique a associação de grupo através de todos os conectores.

Lições aprendidas
Se há uma coisa que aprendi com este projeto, é que os requisitos de negócios determinam tudo o que fazemos como consultores. Houve muitas situações em que a capacidade de o requisito de negócios ser posto em prática teve que ser avaliada de acordo com a complexidade da solução. As decisões e as escolhas que descrevi nesta coluna são as que achamos mais apropriadas, considerando nosso ambiente (incluindo elementos que não tive tempo de discutir aqui), nossos recursos e nossos requisitos de negócios. Para você, as decisões podem ser diferentes, mas espero que esta coluna tenha fornecido alguns conceitos para que você possa refletir. Felizmente, para nós, o Exchange 2003 e o Active Directory permitiram muita flexibilidade para atender a todas as necessidades nesta migração complexa. Depois que passamos pelo choque inicial da implantação do Kentucky Department of Education, a solução real é relativamente simples e nos baseamos no que achamos serem recursos subutilizados do Active Directory e do Exchange 2003.
A segunda lição valiosa foi praticar uma abordagem estável para solução de problemas e gerenciamento de risco/problema. Há situações em que a solução de problemas local é apropriada e outras em que é necessário buscar recursos avançados do Atendimento Microsoft.

Olhando para o futuro
O ambiente do Kentucky Department of Education é seguramente exclusivo. Durante esta implantação, quase todos os recursos do Exchange foram utilizados ou personalizados para satisfazer às necessidades do departamento. Agora que todo o ambiente foi implantado e migrado com sucesso, o campo está preparado para a implementação de funcionalidades adicionais. O Department of Education já percebe o interesse das escolas na plataforma Windows Mobile® e espera que a onda de dispositivos móveis continue.
Há um valor significante a ser obtido da consolidação de servidores. O Kentucky Department of Education atualmente está procurando virtualizar alguns aspectos do ambiente do Active Directory. Tendo em vista o Exchange 2007, o departamento começou a verificar as necessidades de uma atualização de seus sistemas de mensagens.
O Kentucky Department of Education também está verificando ofertas de colaboração adicionais no Live Communication Server, Live Meeting Server etc. O Microsoft Operations Manager 2005 também está em implantação para gerenciamento e monitoramento dos servidores Exchange e Active Directory.

Os resultados
Cada aluno no sistema de escolas públicas de Kentucky será afetado pela qualidade e influência dessa implementação, incluindo meus próprios filhos e os filhos de pessoas com quem trabalhei neste projeto. Esta implementação levou o Kentucky Department of Education a avançar em tecnologia e de uma forma padronizada e segura. Estou orgulhoso de fazer parte desta realização.

Whitney Roberts é o consultor principal da KiZAN Technologies (www.kizan.com (em inglês)) e está trabalhando com o Exchange desde o lançamento do Exchange 4.0.


 SQL Q+A: Como evitar reinicializa&#231;&#245;es, instala&#231;&#227;o de v&#225;rias atualiza&#231;&#245;es e muito mais
SQL Q+A
Como evitar reinicializações, instalação de várias atualizações e muito mais
Editado por Nancy Michell

Como evitar reinicializações

P Como posso limitar o número de reinicializações ao aplicar hotfixes e o mesmo para o SQL Server e até para o sistema operacional do servidor em geral?

R Antes de mais nada, você deve estar interessado em saber que a maioria das reinicializações após a instalação não são codificadas no instalador. Normalmente, elas são o resultado de arquivos bloqueados. Isso significa que o instalador está tentando atualizar arquivos que estão atualmente em uso (bloqueados) por algum outro aplicativo ou pelo sistema operacional. Existe uma abordagem simples para eliminar essas reinicializações: verificar se nenhum processo está usando os arquivos em questão. Como fazer isso?
O primeiro passo é determinar os arquivos específicos que estavam em uso e foram bloqueados durante a instalação. O modo mais fácil é examiná-los no registro, em HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. Verificar essa chave do registro serve a dois propósitos: confirma que a solicitação de reinicialização foi de fato causada por arquivos bloqueados e indica quais arquivos estavam bloqueados. Se fizer essa verificação após a instalação, mas antes da reinicialização, você poderá descobrir o que causou a necessidade de reinicialização e tomar medidas para eliminá-la nas instalações futuras.
Dois tipos de entradas podem ser encontrados. Se o arquivo estava bloqueado para leitura, você observará uma entrada de uma linha por arquivo, o que significa que o arquivo atualizado já está no disco, mas é preciso limpar a cópia temporária que ainda está em uso. Se o arquivo estava bloqueado para gravação, você notará uma entrada de duas linhas por arquivo, o que significa que a atualização ainda não aconteceu, o aplicativo está em estado desconhecido e não deve ser usado. É, literalmente, como parar no meio da instalação. Nesse caso, uma linha indica o arquivo real e a outra aponta para um arquivo temporário (que se tornará o arquivo real na reinicialização).
A próxima etapa depende de muitos fatores, mas a idéia é identificar qual software está usando os arquivos bloqueados. Use verificadores de dependência, se puder, ou o banco de dados DLL HELP da MSDN® (consulte support.microsoft.com/kb/815065).
Se o software identificado tiver um serviço, interrompa o serviço manualmente e, em seguida, teste de novo. Se for um aplicativo, feche-o e tente outra vez. Às vezes, vários aplicativos usam um mesmo arquivo e é necessário interromper todos eles.
O resultado desses testes (em seu ambiente de testes) é uma lista de aplicativos e serviços a serem interrompidos no ambiente de produção, antes da instalação. Logo, o ambiente de produção não precisará de uma reinicialização, pois nenhum software manterá bloqueios em arquivos a serem instalados pelo instalador. Lembre-se, é claro, de reiniciar cada um deles quando a instalação estiver concluída.
O lado bom disso tudo é que os bloqueios geralmente não variam muito. Assim, se você descobrir uma vez esse padrão em seus sistemas, isso provavelmente evitará muitas reinicializações durante o tempo de vida de seu sistema.
Há ainda um outro truque que vale a pena mencionar. Pode ser que você tenha várias versões do SQL Server™ ou de um outro produto instaladas lado a lado que podem ter níveis de versão diferentes. Atualize primeiro, sempre, a versão mais recente. Há boas chances de que a atualização substitua tudo pelas últimas versões, de modo que todas as outras instâncias não se importarão em nada com bloqueios. Por exemplo, se você tiver três instâncias do SQL Server 2000 SP3, a primeira que você atualizar para SP4 atualizará o arquivo MSXML3.dll e precisará de reinicialização. Digamos que você faça a reinicialização nesse instante. Então, você poderá atualizar as próximas duas instâncias para SP4 sem ter que fazer a reinicialização, porque o arquivo MSXML3.dll atualizado já está presente. O mesmo vale para a atualização de qualquer instância do SQL Server 2005 antes de instâncias do SQL Server 2000, e do SQL Server 2000 antes do SQL Server 7.0. Trata-se de uma estratégia geral de minimização de reinicializações que realmente funciona.
Olhando para o quadro geral, as equipes de desenvolvimento da Microsoft têm tido muito trabalho para eliminar ou limitar o número de reinicializações em diversos cenários. Como se trata da coluna de Perguntas e Respostas sobre SQL, tomemos o SQL Server como exemplo.
No SQL Server 2005, a equipe do SQL Server dividiu o Microsoft® Data Access Components (MDAC) necessário para o SQL Server em SQLNCLI (arquivos novos), em vez de atualizar o próprio MDAC, e recolocou o MDAC em banda com o SO. Como isso pode nos ajudar? Bem, o próprio sistema operacional Windows® usa MDAC e mantém esses arquivos bloqueados. É por isso que a maioria dos pacotes de serviços do SQL Server, assim como outros pacotes, sempre necessitaram de reinicialização. Agora, o SQL Server pode atualizar sua versão do MDAC sem tocar nos arquivos MDAC em uso pelo SO, de modo que não há necessidade de reiniciliazação.
Além disso, agora existe um verificador de dependência e uma pausa dentro da instalação do SQL Server 2005 SP1. Isso mostra o que está bloqueado e o que provavelmente o bloqueou, dando a você a chance, no lugar e tempo certos, de interromper o que quer que esteja provocando o bloqueio e continuar a instalação sem reinicializar. Isso significa que você pode se divertir com isso em tempo real, sem precisar de um laboratório de testes. Obviamente, sempre é possível simplesmente continuar e fazer a reinicialização, se preferir ou se a execução estiver no modo autônomo. Note como isso facilita descobrir quem está bloqueando seus arquivos!
Além disso, a tecnologia do Microsoft Installer também processa as PFRs (PendingFileRenameOperations) muito melhor. Você deve se recordar de que a instalação do SQL Server 2000 era bloqueada quando algum arquivo aparecia na chave de registro que já discutimos. A instalação do SQL Server 2005 é inteligente o bastante para bloquear somente os arquivos que pertencerem ao SQL Server (o que significa que pode haver um conflito) e, mesmo nesses casos, é possível alcançar a chave PFR e atualizá-la diretamente, sem necessidade de reinicialização. Essa tecnologia está contida em algum nível no MSI e no update.exe, que são os instaladores padrão atuais da Microsoft usados para realizar todas as atualizações.
Quais são algumas das descobertas conhecidas que causam reinicializações? O MSXML3.dll é uma das maiores. Esse arquivo é sempre bloqueado pelo serviço SVCHost do Windows, de modo que tudo que incluir esse serviço necessitará de reinicialização. E ele também está na maioria das pilhas de MDAC (mdac_typ.exe). Felizmente, o MDAC está "em banda" no Windows Server® 2003 e no Windows XP SP2 e posteriores. A equipe de desenvolvimento do SQL Server fez um ótimo trabalho ao dividir o msxmlsql.dll, de modo que as atualizações do SQL Server não provocarão reinicialização, muito embora você possa observar isso acontecer de vez em quando. Não há nada a fazer nesse caso - não é possível desligar o SVCHost e continuar a executar atualizações.
Além disso, os pacotes do update.exe têm algumas peculiaridades no que diz respeito ao processo de desinstalação. Se você desinstalar um deles, ele colocará um bloqueio (fora das chaves PFR, é claro) nos arquivos in-loco do instalador. Isso evita que outros pacotes do update.exe possam ser executados até que seja feita uma reinicialização para limpar o bloqueio. Tudo o que você realmente pode fazer é ter consciência disso e planejar a reinicialização depois das desinstalações de hotfix que fizer.
Intermitência é uma outra questão. Nem todos os programas trabalham sobre um arquivo 100 por cento do tempo. Na verdade, a maior parte do uso de DLLs compartilhadas é pontual, o que significa que outros programas as acessam apenas de acordo com a necessidade, dependendo de suas próprias tarefas de carregamento e caminhos de código. Isso significa que você poderia fazer um teste 10 vezes e não ver arquivos bloqueados, mas topar com um na implantação da produção. Não há receita mágica, infelizmente. Apenas crie seu ambiente de testes da forma mais semelhante possível a seu ambiente de produção, incluindo testes suficientes de carregamento (sempre uma boa meta) e execução para expor essas permutas.
Os pacotes de serviços e as atualizações de SO provocarão reinicializações. Observe ainda que nas versões de nível menor (Windows 2000, Windows XP e anteriores), a instalação não termina até que a reinicialização seja concluída, mesmo que a chave de registro pendingfilerenameoperations esteja vazia. Há exceções em operações de registro de pacotes que podem ser executadas para instalar código durante a reinicialização. Elas não fazem parte nem mesmo da instalação de pacotes de serviços, mas são comandos incorporados em seu sistema operacional atual, disparados pelos cenários de atualização, para permitir que certos trechos de código em uso sobrevivam a elas.
Finalmente, a chave PFR não faz verificações de versão de arquivo, nem impõe ordem através de serialização. Isso significa que ela aciona as substituições de arquivos na ordem em que estão listadas. Mas a ordem em que são aplicadas ao disco rígido já se provou ser a última para terminar (e não a primeira para começar). Isso faz sentido, mas significa que ter duas cópias do mesmo arquivo no mesmo caminho, cada um apontando para versões diferentes, produzirá um resultado aleatório após a reinicialização. Se você topar com isso, trate de corrigi-lo. Se estiver inseguro, basta executar ambos os instaladores novamente após a reinicialização. Se obtiver os arquivos certos, não terá problema. Se obtiver os errados, seja qual for o pacote que tiver o certo, agora, você fará a correção. Francamente, isso é mais rápido e mais seguro do que tentar imaginar qual seria o resultado desejado.

Várias instalações de pacotes de serviços

P Tenho oito instâncias agrupadas em um cluster de 4 nós e gostaria de instalar o SP4 com o mínimo de reinicializações. Posso instalar o SP4 em todas as 8 instâncias, uma depois da outra, e no final reinicializar todos os nós?

R Depois de ter instalado completamente uma única instância do SQL Server SP 4 - o que pode exigir uma reinicialização - em um determinado servidor Windows (em cluster ou não), não devem acontecer mais reinicializações depois de instalar o SQL Server SP4 em qualquer outra instância do SQL Server na caixa. O motivo é que todos os arquivos compartilhados £ ferramentas, MDAC, MSXML e assim por diante £ já estão com a versão certa e, bloqueados ou não, não necessitam de atualização adicional. Todos os arquivos não compartilhados são usados apenas pela primeira instância, que será desligada pela instalação. Vale a pena notar que a instância mais recente do SQL Server deverá ser atualizada primeiro, se houver várias instâncias com diversas versões.

Execução como serviço de rede

P O que exatamente é a conta NT AUTHORITY\NETWORK SERVICE e qual a sua principal finalidade? Além disso, quais são as implicações de segurança dessa conta, especialmente se lhe forem dados direitos sysadmin (administrador do sistema)?

R A conta Network Service (Serviço de Rede) tem a mesma identidade (de máquina) que System (Sistema) na rede, mas possui privilégios limitados na caixa local. Assim, se um serviço exigir acesso a recursos da rede, pode ser que, para resolver nomes de conta com o controlador de domínio, ele tenha que ser executado seja como Sistema, como conta de domínio ou Serviço de Rede. Normalmente, esta última é a escolha mais segura, pois seu escopo se restringe apenas à caixa local e ainda assim tem privilégios limitados.
Tornar o Serviço de Rede um sysadmin no SQL Server significa que qualquer outro serviço em execução como Serviço de Rede em uma caixa local tem controle total sobre o servidor. Isso acontece, por exemplo, quando a conta de serviço do SQL Server é configurada para execução como Serviço de Rede. Tornar uma conta de serviço do SQL Server um membro de sysadmin é necessário para a funcionalidade do servidor (por exemplo, para permitir conexões de loopback). Embora ter o Serviço de Rede executado como administrador no SQL Server não seja uma boa prática de segurança, isso pode (ou não) ser melhor do que usar uma conta de domínio para esse fim e – muito mais seguro do que executar o SQL Server como LocalSystem.
Se você não quiser que o Serviço de Rede tenha privilégios de sysadmin, a próxima escolha a explorar é usar uma conta de domínio especificamente dedicada a executar SQL Server em uma ou mais instalações do Windows NT®.
Os seguintes artigos podem lhe ajudar: msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp e microsoft.com/technet/security/topics/serversecurity/serviceaccount.

Criação de vários bancos de dados

P Estou pensando em particionar os dados em bancos de dados individuais, talvez em até 250 bancos de dados online ao mesmo tempo. Estimo que apenas 20 por cento serão utilizados nas consultas ativas, a qualquer tempo. Muitos bancos de dados é melhor do que poucos?

R O número de bancos de dados em uma instância de servidor de bancos de dados deve ser conduzido segundo as necessidades de negócio e fatores administrativos. Há muito pouca sobrecarga quando vários bancos de dados são criados em uma mesma instância de servidor; mas a existência de mais bancos de dados significa mais sobrecarga administrativa quanto a tarefas de manutenção, como backup e restauração, espelhamento, contas e funções de usuário. As complexidades administrativas adicionais podem ultrapassar as vantagens de ter mais bancos de dados.
Como regra geral, todos os dados relacionados a um aplicativo devem ser mantidos em um mesmo banco de dados, para facilitar a recuperação na eventualidade de falhas. Se os dados de um aplicativo estiverem espalhados em vários bancos de dados, todos esses bancos de dados terão que ser recuperados durante um failover. Isso poderá atrasar a recuperação ou, até mesmo, impedi-la, caso um dos bancos de dados não possa ser recuperado.
Isto posto, também existem bons motivos para separar dados em vários bancos de dados:
  • Um subconjunto de dados possui requisitos de backup diferentes dos outros dados.
  • Certos dados precisam de um contexto de segurança separado, isto é, de um proprietário de banco de dados diferente.
  • Às vezes, existem dados para fins de histórico que precisam ser mantidos no modo somente leitura.

Agradeço aos seguintes profissionais de TI da Microsoft por seu conhecimento técnico: Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson e Madhusudhanan Vadlamaani.

Editado por Nancy Michell


 Ei, rapaz do script!: Cad&#234; os suportes para copos?
Ei, rapaz do script!
Cadê os suportes para copos?
A equipe de script da Microsoft
Esta coluna é baseada em uma versão de pré-lançamento do Windows PowerShell. Todas as informações deste artigo estão sujeitas a alterações.

Sempre que uma nova tecnologia é introduzida, normalmente, leva algum tempo para que as pessoas consigam diferenciá-la da que havia antes. Pense nos primeiros automóveis, por exemplo. Há um motivo pelo qual aquelas engenhocas eram conhecidas como carruagens sem cavalo: elas realmente eram quase isso. Se formos direto ao ponto, a única diferença entre os primeiros automóveis e as carruagens a tração animal era o fato de que uma usava cavalos e a outra não. Fora isso, era difícil dizer o que era uma e o que era a outra.
Hoje, naturalmente, poucas pessoas confundiriam um automóvel com uma carruagem a tração animal. Isso porque, com o passar do tempo, os fabricantes de automóveis começaram a fazer coisas que separam, claramente, carros de carruagens. Por exemplo, os carros de hoje vêm direto da fábrica com CD players, ar condicionado e sistemas de navegação por satélite; já não podemos dizer o mesmo das carruagens a tração animal. Da mesma forma, suponha que você estivesse conduzindo uma carruagem a tração animal em 1880 e precisasse largar seu Frappuccino por um instante; que pena, você estaria sem sorte. Por outro lado, alguns utilitários esportivos vêm, por padrão, com até 17 suportes para copos, sendo que existe pelo menos um exemplar de automóvel que dispõe de três suportes para copos apenas para o motorista. Alguns dos últimos modelos possuem até mesmo alguns suportes para aquecer ou esfriar a sua bebida, conforme a necessidade.
Observação Sim, é difícil de acreditar que as pessoas conseguiam sobreviver sem poderem tomar três bebidas diferentes enquanto dirigiam. Você consegue imaginar dirigir com apenas uma ou duas bebidas à disposição?
Para que uma nova tecnologia possa realmente ter êxito, as pessoas precisam saber por que devem preferir o novo e desconhecido no lugar do antigo e confiável. Quando os DVDs apareceram pela primeira vez, eles nos permitiam assistir a filmes em casa, exatamente como os videocassetes já faziam. Por outro lado, os DVDs eram bem mais caros do que os videocassetes e não podiam ser usados para gravar nossos programas favoritos. Desnecessário dizer, os DVDs não chegaram ao mundo arrasando. Na verdade, foi só quando os fabricantes de DVD começaram a incluir em seus discos cenas cortadas, comentários de um ator que sequer sabíamos que estava no filme e outras coisas que não podíamos ter com uma fita de videocassete que os DVDs começaram a suplantar seus sósias VHS. Poder assistir a um filme em casa não bastava; os fabricantes de DVD tinham que fornecer recursos acima e além daqueles que as pessoas já tinham.
Observação Se alguém chega, realmente, a assistir algum desses extras ou bônus está fora de questão: a natureza humana sendo o que é, se há alguma coisa diferente disponível, todos simplesmente passam a ter que tê-la. Por coincidência, a equipe de script está pensando em produzir um DVD que consista, principalmente, em textos excluídos das colunas da TechNet Magazine e finais alternativos para scripts de administração de sistemas.

Uso do Windows PowerShell
O Windows PowerShell™, a nova tecnologia de shell de comando/script lançada pela Microsoft, representa um outro exemplo disso. Quando as pessoas ouvem falar no Windows PowerShell pela primeira vez, normalmente, ouvem algo como:
  • "O Windows PowerShell lhe permite gerenciar processos e serviços."
  • "O Windows PowerShell lhe permite recuperar eventos a partir dos logs de eventos."
  • "O Windows PowerShell lhe permite usar WMI para gerenciar computadores."
Bem, não há nada de errado nisso; são todas tarefas úteis e importantes. O único problema, obviamente, é que todas essas tarefas já podem ser feitas pelo VBScript e Windows Script Host. A compatibilidade retroativa é importante e o Windows PowerShell não seria exatamente uma inovação se não pudesse, também, fazer as mesmas coisas que o VBScript. (Imagine um DVD player que não exibisse filmes. Na verdade, você nem precisa imaginar isso: um dos rapazes da equipe de script tem um desses em casa.)
Ao mesmo tempo, contudo, se o Windows PowerShell só fizesse as mesmas coisas que o VBScrip, então por que, em primeiro lugar, deveríamos nos importar com essa nova tecnologia? É verdade, o VBScript não possui nenhum suporte para copos; bom, tudo bem, o Windows PowerShell também não. Então, que diferença faz a tecnologia de script que usamos?
Para ser honesto, pode ser que não faça diferença nenhuma. Entretanto, fora a falta de suportes para copos, o Windows PowerShell tem alguns recursos que o VBScript não tem. Se tudo o que você precisa fazer é gerenciar processos e serviços, então, pode não haver nenhum motivo convincente para que você olhe para o Windows PowerShell; como diz o ditado, não se conserta o que não está quebrado. (Quando usada pela equipe de script, essa máxima tende a ser "Não tentem consertar isso, porque acabarão quebrando"). O Windows PowerShell se torna verdadeiramente atraente quando pode ser usado para fazer algo de que o VBScript não é capaz. Algo como, digamos, alterar a última hora de gravação de um arquivo.

Alteração da última hora de gravação
Você ouviu bem: alteração da última hora de gravação de um arquivo. Por diversos motivos (como uma forma rápida e fácil de controle de versão), os autores de script sempre sonharam com o dia em que eles poderiam alterar a última hora de gravação (ou de criação) de um arquivo ou conjunto de arquivos. É muito triste, contudo, que esse recurso não exista nem no WMI (Instrumentação de gerenciamento do Windows) e nem no FileSystemObject; em ambas as tecnologias, datas e horas de arquivos são para somente-leitura.
Com o Windows PowerShell, no entanto, alterar a última hora de gravação de um arquivo para a data e hora atuais é tão fácil quanto executar este comando:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Antes de explicarmos como o comando funciona, vamos responder a uma pergunta que, provavelmente, está na cabeça de todos: como o Windows PowerShell consegue modificar a última hora de gravação de um arquivo, se o WMI não consegue? Nós achávamos que devíamos tratar dessa questão antes de qualquer coisa, simplesmente porque ela representa uma concepção equivocada comum a respeito do Windows PowerShell. As pessoas tendem a pressupor que o Windows PowerShell é apenas uma nova maneira de usar o WMI. Está certo, você pode, definitivamente, usar o Windows PowerShell para acessar dados do WMI; também é verdade que, enquanto esperamos a criação de cmdlets (comandos nativos do Windows PowerShell) adicionais, a maiorias dos scripts de administração de sistemas continuarão a se basear, primordialmente, no WMI. Em seu cerne, todavia, o Windows PowerShell se baseia em .NET Framework, sendo que os cmdlets do Windows PowerShell lidam, normalmente, com objetos .NET em vez de objetos WMI. E isso é importante, porque as propriedades disponíveis pelo .NET Framework não são necessariamente as mesmas disponíveis pelo WMI.
Por exemplo, quando usamos o cmdlet Get-Item para fazer a ligação com um arquivo, não obtemos uma instância da classe WMI CIM_Datafile; em vez disso, obtemos um objeto .NET. Será que isso é mesmo um negócio tão bom assim? Pode apostar que sim. O objeto .NET expõe um conjunto de propriedades e métodos para gerenciamento de arquivos ligeiramente diferente do exposto pelo WMI. Porém, como acabamos de ver, essas ligeiras diferenças podem ser muito importantes, como a diferença entre uma propriedade ser para somente-leitura em vez de leitura/gravação.
Uma pergunta que não quer calar: como sabemos que o cmdlet Get-Item retorna um objeto .NET? Neste caso, e na maioria dos casos, a maneira mais fácil de descobrir com que tipo de objeto estamos lidando (bem como a maneira mais fácil de identificar as propriedades e os métodos disponíveis) é fazer a ligação com o arquivo e transmitir o objeto ao cmdlet Get-Member:
Get-Item c:\scripts\test.txt | Get-Member
Os resultados deste comando são exibidos na Figura 1. Como você pode ver, trata-se, realmente, de um objeto .NET (como se a equipe de script pudesse errar numa coisa dessas!)
Figure 1 Membros do objeto retornado por Get-Item (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
Por acaso, esse comando pequenino e simples ilustra dois dos recursos mais interessantes (e úteis) do Windows PowerShell: pipelining e meta-informações. Apesar de não entrarmos em detalhes técnicos agora, a idéia básica por trás da criação de pipelining é que você pode usar um cmdlet para agarrar um objeto e passá-lo a um outro cmdlet. Neste comando, usamos o cmdlet Get-Item para obtermos um objeto representando o arquivo C:\Scripts\Test.txt e o passamos (enquanto objeto) pelo pipeline até o cmdlet Get-Member. (O símbolo | representa o pipeline em um comando do Windows PowerShell.)
O Get-Member, então, faz o que sabe, que é recuperar as propriedades e os métodos do objeto recuperado. Este é outro dos excelentes recursos do Windows PowerShell: é muito fácil acessar meta-informações, informações sobre informações. Usando cmdlets tais como Get-Member e Get-Command, é possível interrogar o Windows PowerShell sobre tudo, praticamente da mesma forma que se pode gravar um script WMI para recuperar informações sobre classes, propriedades e métodos WMI disponíveis.
Observação O Get-Member dá, realmente, um passo além do que é possível com o WMI. Embora você possa usar o WMI para obter informações sobre objetos WMI, não é possível usá-lo para obter informações sobre outros objetos de COM (como, por exemplo, FileSystemObject). Esse não é o caso do Windows PowerShell. O Get-Member funciona com qualquer objeto que se possa ligar ou criar. Não consegue lembrar os métodos disponíveis ao usar o FileSystemObject? Então, execute o seguinte comando:
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
Este recurso é incrivelmente útil, logo, extremamente subutilizado.
Legal, hein? Se rolarmos a lista de propriedades e métodos disponíveis ao trabalhar com o arquivo C:\Scripts\Test.txt, veremos, eventualmente, esta linha:
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
Interessante. Aparentemente, LastWriteTime é uma propriedade com suporte tanto para get (ler), quanto para set (gravar). Será que isso significa que podemos usar o Windows PowerShell para alterar o valor da última hora de gravação do arquivo? Hummm...
Glossário do Windows PowerShell
Alias Um nome personalizável que representa um cmdlet existente. O Windows PowerShell fornece uma variedade de aliases padrão que mapeiam comandos de shell comuns para seus cmdlets equivalentes.
Cmdlet A menor unidade de funcionalidade no Windows PowerShell, análoga aos comandos internos de outros shells.
Comando Uma unidade de execução no Windows PowerShell. Os comandos podem incluir várias operações conectadas em pipe e transpor linhas por meio do caractere ";".
Frappuccino Uma bebida gelada mista, à base de café, vendida pela Starbucks.
Monad/MSH/Microsoft Command Shell Codinomes antigos do Windows PowerShell.
Objeto Dados estruturados recuperados a partir do sistema ou de um comando. O Windows PowerShell manipula dados como objetos .NET, permitindo-lhe manipular as propriedades do objeto por nome, em vez de ter que analisar a saída do comando baseado em texto.
Parâmetro Opções definidas em um cmdlet na linha de comando. O Windows PowerShell usa um caractere hífen (-) inicial para designar um parâmetro.
Pipeline Permite enviar a saída de um comando para a entrada de um outro comando. Também conhecido como pipe; representado em comandos pelo caractere “|”.
Perfil Configurações, carregadas quando o Windows PowerShell é iniciado, que lhe permitem configurar como o shell deve operar.
Script Um ou mais comandos salvos como e executados a partir de um arquivo. O Windows PowerShell usa a extensão .ps1 para arquivos de script.
Shell Um ambiente de linha de comando no qual se pode executar tanto comandos, quanto cmdlets.
Variável Um objeto ou parâmetro cujo valor pode ser definido, alterado ou recuperado durante a execução do comando.

Agora, vamos voltar um pouco e falar sobre o comando que define a última hora de gravação de Test.txt como a data e a hora atuais. É semelhante ao seguinte:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Como você pode ver, este comando não tem mesmo nada de mais. Para começar, vamos declarar uma variável denominada $a. Em seguida, vamos usar o cmdlet Get-Item para fazer a conexão com o arquivo C:\Scripts\Test.txt. Agora é a vez de armazenarmos esse objeto na variável $a. Depois de digitar um ponto-e-vírgula (que nos permite ter vários comandos em uma única linha), vamos definir o valor da propriedade LastWriteTime como a data e a hora atuais. Olha só, isso quase compensa a falta de suporte para copos, não é?

Sonhemos um pouco mais
É claro que você tampouco está limitado a definir a última hora de gravação como a data e a hora atuais. Por exemplo, considere este comando:
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
Desta vez, nós amarramos três comandos juntos. Para começar, usamos o cmdlet Get-Date para criar um objeto de data-hora igual a 5/22/2006, 8:15 PM. Por que não tivemos que usar Get-Date para criar um objeto de data-hora em nosso primeiro script, aquele que define a última hora de gravação como a data e a hora atuais? É fácil: o comando Date retorna automaticamente um objeto de data-hora. (Para verificar isso sozinho, digite o seguinte comando no console do Windows PowerShell: Date | Get-Member.)
Após criar um objeto de data-hora igual à data e hora desejadas, usamos nosso comando Get-Item familiar para obtermos um objeto representando o arquivo Test.txt (que armazenamos na variável $a). Finalmente, definimos a propriedade LastWriteTime com o valor representado pela variável $b:
$a.LastWriteTime = $b
Acredite ou não, você ainda não viu nem metade. Espie só este comando aparentemente inócuo:
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
O que tem de tão interessante neste comando? Bem, vejamos o que ele faz. A primeira parte é fácil: mais uma vez, criamos um objeto de data-hora equivalente a 8:15 PM em 5/22/2006. Contudo, note que, na parte dois, nós não usamos o cmdlet Get-Item; em vez disso, usamos o comando:
Get-ChildItem c:\scripts
O que tem isso? Bem, toda vez que se aplica o cmdlet Get-ChildItem a uma pasta, é retornada uma coleção com todos os arquivos da pasta. Vamos apanhar essa coleção e passar todos os seus itens pelo pipeline (lá está aquele símbolo | de novo) para o cmdlet ForEach-Object.
E o que ForEach-Object tem a ver com todos esses arquivos? Ora, ele é que vai alterar o valor da propriedade LastWriteTime de todos e de cada um deles, é claro:
ForEach-Object {$_.LastWriteTime = $b}
Observação Embora esta coluna mensal não pretenda ser um guia para iniciantes no Windows PowerShell, devemos notar que $_ é uma variável especial que representa o item atual em um loop For Each. Ela equivale a objItem no seguinte loop de VBScript:
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
Quando nosso comando de Windows PowerShell terminar de executar, todos os arquivos da pasta C:\Scripts terão a mesma última hora de gravação. Nós gostaríamos de ver uma daquelas inovadoras carruagens sem cavalos fazer isso!
Poderíamos executar variações desse comando a noite toda. Por exemplo, talvez você queira alterar a última hora de gravação somente nos arquivos .txt da pasta C:\Scripts. Certo, tudo o que você teria que fazer seria perguntar:
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

Desperte o seu apetite
É mesmo muito legal. Entretanto, devemos notar que o objetivo desta coluna não é "vender" o Windows PowerShell e nem encorajá-lo a jogar fora todos os seus scripts de VBScript e convertê-los, todos, em Windows PowerShell. Se esses scripts fazem o que você quer e precisa que eles façam, simplesmente deixe-os em paz; o mesmo vale para arquivos de lote, ferramentas de linha de comando, palavras mágicas e quaisquer outras ferramentas utilizadas para gerenciar seus computadores. Lembre-se, se ele não estiver quebrado...
A questão não é que o Windows PowerShell lhe permite fazer coisas que já é capaz de fazer, mas sim que, em parte porque fornece acesso ao .NET Framework, o Windows PowerShell lhe permite fazer coisas que antes não eram possíveis. Modificar a última hora de acesso de um arquivo (ou grupo de arquivo) é um dos exemplos disso. Se existem ou não outros exemplos, depende do que você precisa fazer. São esses recursos que fazem valer a pena dar uma olhada no Windows PowerShell.
Para muitos, esta talvez tenha sido uma introdução pouco usual ao Windows PowerShell, afinal, em vez de começarmos com um exemplo simples, do tipo "Olá, mundo", partimos direto para um comando multicomponentes do Windows PowerShell, todo o tempo lançando termos como pipeline e cmdlet, muito embora todos soubessem o que queríamos dizer com tudo aquilo. Foi intencional. Afinal, nós sabemos que muitos ainda precisam experimentar o Windows PowerShell e ficamos com medo de que, se mostrássemos como recuperar uma lista de serviços em um computador, você simplesmente daria de ombros e voltaria a fazer o que estava fazendo.
Observação Esperamos que você não esteja dirigindo. Para muitos de nós ainda é muito difícil tomar três bebidas, assistir a um DVD e falar em um telefone celular enquanto dirige, sem falar na quot;leitura da TechNet Magazine" no meio disso tudo.
Ei, qual é! Nós dissemos para muitos de nós, não para todos.

A equipe de script da Microsofttrabalha para £ bem, são empregados por ela £ a Microsoft. Quando não está jogando/treinando/assistindo beisebol (e diversas outras atividades), ela administra o TechNet Script Center. Verifique em www.scriptingguys.com (em inglês).


 Security Watch: Implanta&#231;&#227;o de uma PKI confi&#225;vel globalmente
Security Watch
Implantação de uma PKI confiável globalmente
John Morello
Esta coluna inclui informações de pré-lançamento que estão sujeitas a alterações.

Uma infra-estrutura de chave pública, ou PKI, é um elemento fundamental no desenvolvimento de confiança entre diversos aplicativos, sistemas operacionais e territórios de identidade. Ela é criada sobre um modelo de confiança hierárquica no qual as entidades finais confiam em uma chave comum no nível mais alto da raiz e, portanto, quaisquer outras chaves assinadas por essa raiz são implicitamente confiáveis.
Devido a esta estrutura, uma PKI bem projetada pode ser dimensionada facilmente adicionando-se CAs (autoridades de certificação), sem introduzir alterações nas entidades finais.
Há duas maneiras típicas de implementação de PKIs. A abordagem mais comum é comprar certificados, conforme necessário, de um dos provedores de raízes globais implicitamente confiáveis, como a Cybertrust ou a VeriSign. Esses certificados são usados, freqüentemente, para proteger o tráfego em sites, mas também podem ser usados para VPNs (redes virtuais privadas), assinatura de email e tarefas similares. Como essas raízes globais são criadas em todos os navegadores da Web e sistemas operacionais modernos, esse método pode facilmente estender uma relação de confiança para além das fronteiras organizacionais. No entanto, como esses certificados são adquiridos conforme a necessidade, essa abordagem pode ser onerosa para implantação em larga escala em uma organização de grande porte.
O modelo de PKI interna tem sido mais usado ultimamente. Como o nome sugere, uma PKI interna é confiável apenas dentro da rede da própria organização. Esse modelo oferece uma maneira mais barata para uma organização prover certificados a todos os usuários e dispositivos de computação da rede. Essa abordagem costuma ser usada para facilitar tecnologias, como logon com cartão inteligente, EFS (sistema de arquivos com criptografia) e rede sem fio segura. A desvantagem é que, como esses certificados não são globalmente confiáveis, eles não servem para aplicativos direcionados para fora. Assim, a maioria das organização que implantou PKIs internas costuma adotar uma abordagem híbrida, adquirindo certificados para aplicativos públicos de uma das raízes globalmente confiáveis.
Mas, e se você pudesse se beneficiar dos dois mundos? E se a sua organização conseguisse executar a própria PKI – com a economia de custos referente à obtenção de certificados internos – e, ao mesmo tempo, conseguisse prover certificados publicamente confiáveis, tudo isso a partir de seu sistema local? Uma solução como essa ofereceria os benefícios de uma PKI interna (como integração com o Active Directory®, auto-inscrição e suporte de TI localizado) tendo, ao mesmo tempo, a principal vantagem de uma raiz globalmente confiável. A LSU (Universidade do Estado da Louisiana) tem esse sistema. Nesta edição do Security Watch, trato especificamente da solução que implementamos na LSU, discutindo seu projeto técnico e destacando as práticas recomendadas a serem usadas na instalação de um sistema similar. É importante observar que a solução que descreverei é uma solução que atendeu às necessidades específicas dadas pelo nosso ambiente, recursos e requisitos comerciais. Você deve avaliar todos esses aspectos de sua empresa com antecedência para determinar o tipo de solução certa para você.

Como a LSU cria PKI
A LSU é uma universidade de pesquisa de grande porte com um público de estudantes, professores e funcionários de mais de 40.000 pessoas. Ela tem muitos sites públicos, e muitos deles necessitam de TLS – o termo adequado para certificados SSL (secure sockets layer). A LSU gastava milhares de dólares anualmente com certificados de fornecedores de raízes globalmente confiáveis.
Enquanto isso, havia outros objetivos de segurança de TI que poderiam tirar grandes vantagens de uma PKI interna bem projetada. Com base nos objetivos e requisitos da LSU, você poderia esperar que decidíssemos adotar um modelo híbrido. Mas, em invés disso, tomamos uma decisão com base em uma abordagem mais inovadora.
Trabalhamos com uma das raízes globalmente confiáveis, a Cybertrust, para implantar uma CA subordinada a uma CA raiz da Cybertrust nas instalações da LSU (consulte a Figure 1). A Cybertrust oferece esse serviço no programa OmniRoot. Nesse cenário, a LSU cria e opera uma CA que é executada localmente nos equipamentos da própria LSU. Entretanto, diferentemente do modelo interno tratado anteriormente, a CA da LSU não é auto-assinado e sua chave (bem como as chaves assinadas) é implicitamente confiável em praticamente todos os sistemas operacionais e navegadores modernos. Tecnicamente, esse projeto é uma extensão lógica da abertura dos padrões x.509. Como uma PKI é criada de acordo com esses padrões, é possível conectar sistemas criados por fornecedores diferentes com a mesma hierarquia geral. Posto isso, o que é particularmente interessante na solução OmniRoot são os termos de uso do serviço.
Figura 1 Certificado de raiz global Cybertrust
Figura 1 Certificado de raiz global Cybertrust (Clique na imagem para diminuir a exibição)
Figura 1 Certificado de raiz global Cybertrust
Figura 1 Certificado de raiz global Cybertrust (Clique na imagem para aumentar a exibição)
O serviço OmniRoot foi projetado especificamente para o tipo de implantação de PKI implementado na LSU. No programa OmniRoot, as organizações pagam à Cybertrust uma taxa anual predefinida para participar do programa e pagam uma taxa por certificado apenas para os certificados criados para uso público. Em outras palavras, a LSU pode emitir tantos certificados quantos forem necessários para uso interno, sem se preocupar com taxas por certificado. Enquanto isso, o custo dos certificados públicos agora é significativamente menor do que pagávamos quando a universidade comprava certificados cada vez que eles eram necessários.
Para esclarecer, os certificados internos e os públicos são idênticos, do ponto de vista técnico. Eles são emitidos pela mesma cadeia de CA, têm a mesma proteção de criptografia e são fornecidos pelo mesmo sistema de autoridade de registro. A única diferença entre os dois são os termos de licenciamento.
Em última instância, conseguimos expandir e aprimorar a plataforma de segurança de TI da LSU com um custo mais baixo. Essa conquista tornou-se um grande caso comercial para esse tipo de solução de PKI na LSU. Agora, vamos examinar os detalhes mais técnicos da implantação.

Hierarquia da PKI
A hierarquia da PKI da LSU baseia-se em um projeto em duas camadas, com a camada raiz gerenciada pela Cybertrust e uma CA de emissão online sendo executada na LSU (consulte a Figura 2). A camada raiz forma a âncora para a confiabilidade na hierarquia. Em outras palavras, a relação de confiança de todos os certificados emitidos por qualquer CA na hierarquia está sob a CA raiz (consulte a Figura 3). Assim, a CA raiz forma o vínculo comum entre todas CAs, certificados e entidades finais na hierarquia. Como a raiz global da Cybertrust já está incorporada no Windows® e em praticamente todos os outros sistemas de computação modernos, esse vínculo comum se estende automaticamente além da rede da LSU.
Figure 2 Hierarquia de PKI em duas camadas (Close Figure 2)

Camada raiz (Cybertrust) | Camada emissora (LSU)
Gerenciado pela Cybertrust | Gerenciado pela LSU
Localizado no datacenter seguro da Cybertrust | Localizado no campus Baton Rouge da LSU
Incluso no certificado raiz padrão de quase todos os sistemas de computação modernos | Emite certificados para entidades finais dentro de organizações do sistema LSU
 | Certificados emitidos pela LSU se enquadram na raiz Cybertrust e, portanto, são confiáveis globalmente
Figura 3 Certificado emitido pela CA da LSU
Figura 3 Certificado emitido pela CA da LSU (Clique na imagem para diminuir a exibição)
Figura 3 Certificado emitido pela CA da LSU
Figura 3 Certificado emitido pela CA da LSU (Clique na imagem para aumentar a exibição)
A Cybertrust gerencia a CA raiz em uma de suas instalações de hospedagem segura. A instalação de hospedagem usa fortes controles de segurança física, inclusive armadilhas, fechaduras biométricas e um cofre de armazenamento totalmente revestido com cobre. A Cybertrust emite certificados apenas para as CAs emissoras de organizações que demonstram compatibilidade com suas diretivas de segurança e certificação.
A CA emissora da LSU é um sistema voltado para a entidade final responsável pelo fornecimento de certificados ao público de usuários e máquinas da LSU. Seu certificado é assinado pela CA da Cybertrust acima dela na hierarquia e emite certificados que se encadeiam para a CA raiz da Cybertrust (consulte a Figura 3).

SO e hardware emissores
A LSU usa o Windows Server® 2003 Enterprise Edition com Service Pack 1 para sua CA emissora. O serviço de Autoridade de certificação do Windows Server 2003 oferece muitos recursos novos, incluindo arquivamento de chaves, CRLs (listas de revogação de certificado) delta e modelos "versão 2". A instância do Windows usada como CA emissora é criada de acordo com a diretiva de criação do Windows Server da LSU. Ela é atualizada com todas as atualizações de segurança relevantes e gerenciada com as práticas de gerenciamento de alterações padrão da LSU, inventário de software e ferramentas de atualização. Resumindo, enquanto há alguns aspectos particulares no gerenciamento do serviço da CA em si, o sistema operacional e hardware de servidor básicos são facilmente integrados nas operações de TI existentes da organização.
Além das práticas recomendadas padrão da LSU para instalação de servidor a seguir, aproveitamos o SCW (assistente de configuração de segurança), disponível no Windows Server 2003 Service Pack 1. O SCW usa um banco de dados que contém as matrizes de dependência das diversas cargas de trabalho que podem ser executadas no Windows Server e a configuração de segurança necessária para essas cargas de trabalho. Esse banco de dados inclui duas funções principais que a CA oferecerá - o serviço de CA em si e o IIS (que fornece o site de auto-atendimento de PKI).
Usando o SCW, criamos, facilmente, um modelo de segurança que desabilitou todos os serviços, exceto os necessários para executar essas cargas de trabalho, bem como protegemos a pilha de rede do servidor. Usamos então scwcmd.exe para transformar esse modelo em um GPO (objeto de diretiva de grupo), de modo que pudéssemos aplicá-lo no servidor no nível de unidade organizacional. Essa abordagem simplifica o dimensionamento e a recuperação de desastres, já que a configuração de segurança baseada em função para uma CA da LSU agora está armazenada dentro do Active Directory e não em uma máquina específica.
A CA emissora da LSU está instalada em um servidor IBM xSeries 346, com processadores dual 3.2GHz Intel Xeon, 4GB de RAM e cinco discos rígidos de 146GB SCSI. Considerando-se as necessidades de desempenho do serviço de CA e o fato de que a LSU usa um nódulo de segurança de hardware, essa plataforma deve oferecer longevidade significativa e espaço para crescimento.
Seguimos práticas recomendadas padrão para separar bancos de dados e arquivos de log em eixos físicos distintos, criando duas matrizes RAID 1. O quinto disco rígido é mantido como reserva quente e está disponível para as duas matrizes. Montamos a primeira matriz como nosso volume do sistema, onde mantemos o banco de dados da CA. A segunda matriz é usada para arquivos de log e vários outros arquivos de dados, como os CRLs. O banco de dados da CA é baseado na mesma tecnologia Jet encontrada em outras áreas do Windows, como o Active Directory, de modo que as mesmas práticas recomendadas de manutenção e configuração de disco para outras soluções de armazenamento em Jet se aplicam aqui.
Um HSM (módulo de segurança de hardware) é um dispositivo de hardware dedicado gerenciado separadamente a partir do sistema operacional. Normalmente, os HSMs são fornecidos como adaptadores PCI, mas também estão disponíveis como aplicativos com base na rede. Esses módulos fornecem um armazenamento de hardware seguro para chaves de CA, bem como um processador criptográfico dedicado para acelerar operações de assinatura e criptografia. O Windows usa o HSM por intermédio das interfaces CryptoAPI – o HSM é visto como um dispositivo CSP (provedor de serviços de criptografia). O programa OmniRoot requer que cada CA use pelo menos um HSM com certificado FIPS 140-2 nível 3 (dispositivos de nível 4 são bastante raros) para geração e armazenamento de chaves. Como um dispositivo exclusivo e de alta segurança, um HSM requer um investimento financeiro notável, os preços de tabela para HSM com base em PCI ficam geralmente entre US$10.000 e 15.000.
No projeto da LSU, um nCipher nShield 500 TPS (modelo 500 transações por segundo) é usado como um HSM de acesso direto. ("Acesso direto" significa que é interno ao servidor e está disponível para uso apenas por esse servidor, em contraste com um HSM com base em rede que pode ser compartilhado por vários hosts). O HSM é um dispositivo FIPS 140-2 nível 3 e oferece proteção K de N para o material de chaveamento. O HSM oferece proteção significativa contra o comprometimento das chaves privadas - um invasor precisaria possuir tanto o armazenamento HSM quando uma quantidade definida de tokens de acesso e PINs para acessar a chave.
É fundamental observar que os HSMs foram projetados para evitar que seu conteúdo seja alterado por partes mal intencionadas. Assim, os HSMs forçam severamente um limite para tentativas consecutivas de logon com falha. No projeto da LSU, o armazenamento é irrevogavelmente apagado após 10 tentativas com falha.
Temos uma única CA em nossa configuração, de modo que o preço de um HSM com base em rede não se justifica. No entanto, se uma organização planeja implementar duas ou mais CAs, pode ser significativamente mais barato comprar um único HSM com base em rede e compartilhá-lo entre as CAs. Essa abordagem também facilita o gerenciamento de tokens, já que todo o armazenamento de chaves pode ser protegido pelo mesmo conjunto de tokens.

Active Directory e registro
Uma das principais vantagens de uma solução de PKI com base no Windows é que o fornecimento de certificados é obtido sem a necessidade de instalar software adicional em entidades que participam da PKI. Em vez disso, através de uma combinação de auto-registro e Diretiva de grupo, a maior parte do fornecimento de certificados pode ser gerenciada de forma autônoma, invisível para o usuário final. A LSU usa essa tecnologia para distribuir certificados eletrônicos automaticamente para computadores membros de seu Active Directory. E usamos um site personalizado para fornecer recursos de requisição de certificados de auto-atendimento para hosts não baseados em Windows.
Como já foi dito, o programa OmniRoot distingue os certificados usados publicamente daqueles usados internamente. Os certificados serão considerados públicos se forem usados por sistemas e usuários que não fazem parte da organização da LSU (por exemplo, quando um estudante em potencial envia uma inscrição para matrícula através de um site com segurança SSL). Certificados usados dentro da organização da LSU (como os que são usados para criptografar dados nos servidores da LSU) são considerados internos.
Como o custo do programa OmniRoot é baseado no número de certificados públicos, precisamos rastrear quantos certificados públicos são emitidos, e para quem. Assim, para qualquer certificado cujo propósito seja público, o nome distinto do modelo começa com "PublicCertificate" e o nome para exibição começa com "Public Certificate". Por exemplo, o modelo de certificado público TLS da LSU é baseado no modelo padrão do Windows Web Server e é denominado Public Certificate LSU Web Server. Para servidores Web usados internamente, temos um segundo modelo chamado Internal Certificate LSU Web Server. Tecnicamente, os dois modelos são idênticos, a diferença no nome serve apenas para facilitar a contabilidade.
Para fins de registro em massa – como o registro de departamentos inteiros para certificados a serem usados com IPSec – usamos o auto-registro. Essa é uma ferramenta simples e altamente eficiente interna do Windows. Do ponto de vista de um administrador de PKI, a única ação necessária é alterar a lista de controle de acesso no modelo, concedendo a qualquer grupo de usuários ou computadores que precisarem de certificados o direito de se auto-registrarem. Essas entidades conferirão o Active Directory automaticamente, definirão para quais modelos terão acesso de auto-registro, encontrarão as CAs com esses modelos e se registrarão automaticamente nos certificados. Além disso, o recurso de auto-registro garantirá que os certificados sejam substituídos, se um modelo for substituído, e sejam renovados automaticamente antes de expirarem.
Para propostas sem trabalho em massa, como fornecer certificados para servidores da Web, usamos um site de auto-atendimento que permite que usuários solicitem certificados através de um navegador da Web. Esse site é uma versão personalizada das páginas de registro da Web que acompanham o Windows Server 2003 (o diretório virtual /certsrv); nossa implementação inclui a marca padrão da Web da LSU e preenche as entradas padrão corretas na página de solicitação. E usamos o módulo de saída padrão do serviço Windows CA para enviar automaticamente um email para a equipe de administração de PKI quando uma solicitação enviada através desse site necessitar de aprovação.

Projeto de revogação
Cada certificado tem um tempo de vida útil. Com uma certa freqüência, a LSU precisa invalidar determinados certificados antes do final de seu período de validade (por exemplo, se um funcionário recebe um certificado com um período de validade que expira em maio de 2007, mas deixa a LSU em janeiro de 2007). Esse tipo de revogação é obtido com CRLs, arquivos que contêm uma lista de números de série de certificados assinados por uma CA. Os números de série presentes em um CRL se referem a certificados cujo tempo de vida útil não tenha expirado, mas que a LSU já não considera confiáveis. Os clientes podem fazer o download desse CRL e fazer sua verificação para determinar a validade dos certificados.
Qualquer certificado x.509 v3 (exceto o próprio certificado raiz da CA) deve ter um ponteiro para um CRL válido. Esse ponteiro é conhecido como ponto de distribuição de CRL, ou CDP. O ponto de distribuição de CRL é fornecido no próprio certificado (consulte a Figura 4) e não pode ser modificado após a emissão do certificado. O CRL é uma parte essencial para garantir que os certificados de uma CA sejam válidos. Assim, verificamos se os CRLs da LSU são fisicamente redundantes, altamente disponíveis e acessíveis por partes externas.
Figura 4 Ponto de distribuição de CRL da LSU
Figura 4 Ponto de distribuição de CRL da LSU (Clique na imagem para diminuir a exibição)
Figura 4 Ponto de distribuição de CRL da LSU
Figura 4 Ponto de distribuição de CRL da LSU (Clique na imagem para aumentar a exibição)
Uma CA com base no Windows Server integrada com o Active Directory (como a da LSU), publica automaticamente o seu CRL no Active Directory, tornando-o acessível através do protocolo LDAP. O local de publicação padrão é o contêiner CDP (consulte a Figura 5) no contêiner de Serviços de chave pública na floresta. Esse local de publicação é uma excelente opção, já que oferece replicação automática, tolerância a falhas e localidade para pesquisas CDP.
Figura 5 Contêiner CDP
Figura 5 Contêiner CDP (Clique na imagem para diminuir a exibição)
Figura 5 Contêiner CDP
Figura 5 Contêiner CDP (Clique na imagem para aumentar a exibição)
No projeto da LSU, no entanto, há muitos computadores que não usam o Windows nem o Active Directory e usam a PKI. E como a LSU é uma organização de grande porte, a grande maioria de seus usuários se encontra na mesma rede do campus, com um backbone de 10Gbps, tornando mínimas as vantagens da publicação de CDP com base no Active Directory.
Dessa forma, publicamos nosso CRL apenas em um caminho HTTP, facilitando a criação de uma plataforma de hospedagem redundante (nosso site principal já está espelhado). Isso também remove as possíveis complexidades associadas à habilitação de buscas LDAP de cliente. Publicamos nosso CRL diariamente e publicamos CRLs delta de hora em hora.

Seguindo adiante
Enquanto nossa PKI atual fornece uma solução de segurança forte para a comunidade universitária, planejamos o aprimoramento de seus recursos. O Windows Vista™ e a próxima versão do Windows Server (codinome "Longhorn") fornecerão diversos recursos novos de gerenciamento de chaves que queremos investigar. Estamos particularmente interessados nos recursos de cliente e respondente do OCSP (protocolo de status de certificado online), no suporte para criptografia em curva elíptica e algoritmos SHA-256 e em uma interface de auto-registro mais aprimorada. Além disso, o Windows XP Service Pack 3 está programado para incluir um recurso conhecido como credential roaming, que fornecerá mobilidade com segurança de pares de chaves sem a sobrecarga associada aos perfis móveis. Finalmente, estamos investigando o uso do Certificate Lifecycle Manager (que já está disponível em beta) para melhorar nossos recursos de relatório e gerenciamento.
Resumindo, a PKI da LUS oferece à universidade um serviço de segurança básico usado para muitas funções críticas de TI. Usando o serviço OmniRoot da Cybertrust, podemos executar uma PKI integrada com os outros sistemas de TI da LSU, mas com confiabilidade global. E, construindo a solução no serviço de CA do Windows, temos recursos de fornecimento e gerenciamento de certificados eficientes e excelente integração com nosso sistema de diretórios e gerenciamento de identidades existente. Enfim, a visão PKI de segurança forte e confiabilidade contínua já está se tornando uma realidade na LSU.

John Morello graduou-se com louvor na Louisiana State University e passou seis anos na Microsoft como consultor sênior da Microsoft Consulting Services. Com a MCS, ele projetou PKIs para clientes estratégicos, como a Deloitte, GE e várias organizações federais. Hoje, ele é o representante CISO na LSU (Universidade do Estado da Louisiana).


 Os arquivos da &#225;rea de trabalho: Por dentro do formato do Windows Imaging
Os arquivos da área de trabalho
Por dentro do formato do Windows Imaging
Wes Miller
Esta coluna é baseada nas versões de pré-lançamento das ferramentas de implantação do Windows. Todas as informações deste artigo estão sujeitas a alterações.

O lançamento do Windows Vista traz uma importante mudança em como o Windows é instalado e implantado. O mecanismo de instalação e todo o conjunto de ferramentas de implantação do Windows Vista (bem como da próxima versão do Windows Server, com o codinome de "Longhorn") foram reescritos. Falo sobre essas mudanças e o empenho da equipe de implantação do
Windows® para a concretização de tais novidades nos últimos artigos da TechNet Magazine. Como este é um tópico muito abrangente, falarei sobre o Windows PE, a instalação e a implantação do Windows e sobre outros temas de gerenciamento e segurança do Windows nesta nova coluna regular.
Nesta primeira edição, trataremos do novo formato do WIM (Windows Imaging). Se você ainda não está familiarizado com os detalhes de geração de imagens, não deixe de ler a barra lateral "O típico processo de geração de imagens" para obter uma visão geral. Na próxima coluna falarei sobre o Kit de instalação automatizada do Windows - um novo conjunto de ferramentas que inclui o ImageX (a ferramenta de linha de comando para criar e manipular imagens do WIM) e o WDS (Windows Deployment Services), que substitui o RIS (Remote Installation Services) - enfocando como essas ferramentas facilitam as implantações do SO.

O momento decisivo
Ano após ano, a equipe de implantação do Windows ouve o mesmo comentário de OEMs e clientes empresariais. Eles querem melhor suporte para geração de imagens e que a Microsoft forneça ferramentas unificadas para imagens. Esses usuários não querem ter o trabalho de selecionar outro fornecedor e aprender as complicações do produto. Além disso, ouvimos freqüentes reclamações, pois esses OEMs e clientes empresariais não acham que deveriam ter de pagar por ferramentas de geração de imagens usadas para implantar o Windows e que gostariam que a Microsoft fornecesse tais ferramentas.
Logo no início da implantação do Windows Vista™, a equipe de implantação do Windows fez uma aposta muito alta. Decidimos descartar completamente todo o mecanismo de instalação - muitos componentes dos quais já existiam há quase uma década. A instalação sempre foi um processo frágil e com muitas etapas. Queríamos acelerar o processo, remover etapas desnecessárias e aumentar a confiabilidade da instalação do Windows de um modo geral. Para tanto, mudaríamos todo o processo de instalação manual do mecanismo, utilizado há algum tempo, e o substituiríamos por um processo de instalação totalmente baseado em imagens.

O projeto de um novo formato de geração de imagens
Logo no início do processo de reformulação da instalação, partimos para a definição do tipo de imagem que deveríamos usar. O argumento clássico foi o uso de setor versus arquivo. Ou seja, discutimos se deveríamos usar um formato de imagem que armazenasse uma cópia do volume como uma réplica setor-por-setor ou um formato que armazenasse cada arquivo individualmente. A maioria das pessoas espera como benefício maior velocidade (com uma abordagem setorial) versus compactação (com uma abordagem baseada em arquivo). Por fim, chegamos a um formato que acredito proporcionar um excelente equilíbrio entre esses dois quesitos. Conseguimos um desempenho muito bom, com excelente compactação.
Para começar, definimos vários objetivos principais que deveríamos alcançar para chegarmos a um formato de geração de imagens que atendesse às necessidades de OEMs e usuários empresariais. Nossa lista tendia fortemente a uma arquitetura baseada em arquivos. Acho que todos vimos os benefícios dessa abordagem e, portanto, partimos inicialmente nessa direção. E logo nasceram os arquivos WIM. (Caso você esteja imaginando qual o significado do "M" da sigla WIM, adianto que não significa nada. Demos o nome de WIM ao formato, com base na experiência recorrente que a equipe do Windows vivencia perto das etapas de entrega de um produto - e *.WI parecia uma abreviatura estranha.) Vejamos as metas que surgiram para o novo formato de imagens.
Neutralidade quanto ao formato do sistema de arquivos do Windows O formato de imagem tinha de funcionar nas duas arquiteturas de sistemas de arquivos às quais o Windows oferece suporte. Embora quase todos os sistemas utilizem NTFS ao serem executados, vários OEMs e empresas usam sistemas de arquivos FAT como um substituto que permite usar o MS-DOS® para implantar o Windows e converter em NTFS posteriormente. Precisávamos continuar a oferecer esse tipo de suporte com o Windows Vista.
Neutralidade quanto à geometria de volume Tínhamos de superar o problema histórico de capturar um volume grande e aplicá-lo a um volume menor. Mesmo quando se consegue superar essas dificuldades de manipulação de partição, a ferramenta de geração de imagens não é confiável. Em uma arquitetura baseada em arquivos, a imagem ocupa o mesmo espaço que os arquivos que a compõem. Como o sistema de arquivos é restaurado de maneira autônoma, não há dependência em relação ao tamanho do volume.
O típico processo de geração de imagens
Quando um OEM duplica inúmeros sistemas ou uma grande organização precisa implantar o Windows em várias máquinas, geralmente usa a tecnologia de geração de imagens. A premissa é pegar o sistema host, desenvolvê-lo exatamente como desejado e, então, duplicá-lo nos sistemas de destino. Caso você não tenha familiaridade com o processo de geração de imagens, apresentamos uma rápida visão geral.
  1. O administrador instala o Windows em um sistema e o configura como desejar. Isso envolve adicionar e remover componentes, instalar os aplicativos mais utilizados e adaptar a UI e outras configurações. A isso damos o nome de sistema host.
  2. O administrador executa o Sysprep (fornecido pela Microsoft como ferramentas de implantação do Windows), que executa a tarefa pesada de limpar os atributos que tornam a instalação do Windows exclusiva, tais como o nome do computador, o SID (Identificador de segurança) do Windows e outros identificadores exclusivos em todo o sistema. Esses atributos são redefinidos na execução da segunda parte do Sysprep.
  3. Em seguida, o administrador desliga o computador e o reinicia no Windows PE, no MS-DOS ou em outro OS que permita executar o aplicativo de geração de imagens.
  4. Agora o administrador executa a ferramenta de geração de imagens criando uma imagem do sistema de referência. Essa imagem é um arquivo (ou conjunto de arquivos) que contém uma réplica exata do disco ou da partição de referência.
  5. O sistema é desligado e o administrador arquiva a imagem, que pode ser atualizada (por meio da adição de aplicativos, hotfixes e service packs) conforme necessário.
  6. A imagem é replicada em um ou mais computadores e o Sysprep conclui o trabalho sendo executado por uma versão resumida da instalação (chamada Mini-instalação ou Windows Welcome, dependendo da versão do Windows na qual o Sysprep está sendo executado e de como o Sysprep está configurado). Esse estágio depende de um minúsculo executável em modo nativo chamado setupcl.exe.

Neutralidade quanto à arquitetura do sistema A arquitetura de imagem precisava funcionar com qualquer arquitetura suportada pelo Windows. Na época, isso significava oferecer suporte às arquiteturas x86 e IA64 (Intel Itanium), que são bastante diferentes. Hoje, isso também inclui a arquitetura x64 (AMD64 e EM64T).
Deve ser rápida para capturar e aplicar - a imagem precisava ser capturada com razoável rapidez, dada a compactação. No entanto, o quesito mais crítico era alcançar maior rapidez no aplicativo de imagem.
Suporte a aplicativo de imagem não destrutivo Como estávamos substituindo a opção de atualização (que substituiria o Windows sem prejudicar aplicativos ou dados do usuário), além de derivar uma ferramenta que pudesse ser usada para recuperação do sistema, queríamos que ela pudesse gerar uma imagem de sistema sem destruir o que já estivesse no volume. Formatos baseados em setor, sem um trabalho considerável, não permitem que o usuário faça isso - em geral, ou você restaura o volume inteiro ou nada feito.
Suporte à compactação expressiva No início do desenvolvimento do Windows Vista, ainda estávamos focados na entrega em CD. Considerando que uma imagem Windows XP tem quase 1GB, decidimos que era importante compactar a imagem o máximo possível. Para tanto, existem alguns truques que podemos executar com uma imagem baseada em setor, mas nos preocupávamos com as partes móveis nesse tipo de implementação. Muitos formatos baseados em setor omitem espaços em branco no disco para economizar espaço. (Por que gravar um 0 como imagem se ele sempre será um 0?) No entanto, usando uma abordagem baseada em arquivo, lidaríamos com isso de maneira inerente, pois não separaríamos espaços em branco.
Suporte à instância única de arquivos Esta questão é igual à anterior. O Windows é conhecido por armazenar várias cópias do mesmo arquivo em alguns locais diferentes. Com a abordagem baseada em arquivo, é fácil armazenar uma única instância de cada arquivo e usar o arquivo conforme necessário.
Suporte à distribuição em mídia (disco) Mesmo nos primórdios do WIM, quando colocávamos uma imagem em um único CD, sabíamos que era necessário oferecer suporte a várias unidades de mídia. Mesmo se entregássemos o Windows em um CD, quando os usuários adicionassem aplicativos, service packs etc., suas imagens provavelmente ultrapassariam o tamanho de um único CD ou DVD. Portanto, precisávamos permitir a distribuição entre várias unidades para suas próprias soluções de instalação e recuperação.
Suporte a imagens de vários volumes em um arquivo Blob Uma imagem raramente funciona para tudo. Quando projetamos a "instância única", também incluímos a capacidade de separar mais de um volume - e a mesma compactação e instância única funcionam em cada uma delas. Portanto, se você separar uma imagem do Windows XP Professional e anexar uma nova imagem do Windows XP Tablet PC Edition (um superconjunto do Windows XP Professional), a imagem será aumentada somente pelos arquivos explicitamente diferentes entre as duas versões.
Como resultado, um OEM ou um usuário empresarial poderá anexar imagens derivativas sem um aumento exponencial do tamanho. Não foi fácil alcançar essa capacidade com formatos baseados em setor.

Como o WIM funciona
O formato WIM foi projetado para ser o mais simples possível e, ao mesmo tempo, atender nossos princípios básicos. A abordagem baseada em arquivo nos permitiu chegar a tal equilíbrio. Mas como isso funciona exatamente?
Em resumo, você pode pensar em um arquivo WIM como um arquivo CAB (semelhante ao formato ZIP, mas o formato CAB foi desenvolvido e é de propriedade da Microsoft). Na verdade, já ouvi chamarem o WIM de "filho do CAB". A principal diferença entre um arquivo WIM e um CAB é que, além de capturar e compactar o arquivo por conta própria, uma imagem WIM armazena os metadados que se aplicam às pastas e aos arquivos que compõem o volume capturado em uma determinada imagem do volume. Portanto, é como se um arquivo morto com todas as meta-informações precisasse restaurar o volume para o modo em que estava quando a imagem foi criada - ACLs (listas de controle de acesso), nomes de arquivos curtos e longos, atributos e assim por diante.
Observe que em nenhum momento durante o processo de captura, as informações sobre a partição (tamanho ou tipo) são coletadas, tampouco o processo de aplicação particiona o sistema. Diferentemente da maioria das ferramentas de geração de imagens, o ImageX, de partição neutra, requer a criação e a formatação da partição antes da aplicação. Para automatizar o processo antes de aplicar sua imagem, você deve usar as ferramentas de linha de comando de formatação e diskpart.
Nada limita o que pode ser armazenado em uma imagem de volume. Uma imagem pode conter dois volumes, o mesmo volume capturado em uma terça e numa quinta-feira, uma imagem com um service pack e outra sem ou qualquer outra coisa de acordo com suas necessidades. O principal é entender que arquivos idênticos são capturados apenas uma vez. Quanto menos duas imagens de volume tiverem em comum, maior espaço será ocupado.
Devo ressaltar também que não há nada projetado no formato WIM que o impeça de ser usado com versões anteriores do Windows. O WIM funcionará tanto com o Windows 2000 quanto com o Windows Vista. Vejamos mais de perto o que acontece exatamente quando as imagens são capturadas e aplicadas.

Captura de imagens
Quando a imagem de um volume é capturada, acontecem as seguintes etapas:
Os metadados do volume são capturados O ImageX reúne os dados sobre nomes dos arquivos, ACLs do NTFS e outros atributos do sistema de arquivos em todo o volume. (Você pode optar por excluir determinados arquivos com um arquivo de script.)
Os dados do arquivo são capturados O arquivo é carregado pelo ImageX. Cada arquivo é carregado no volume e se prepara para coletar determinados dados sobre ele.
O hash do arquivo é gerado Um hash criptográfico do arquivo com base no próprio arquivo é gerado. Esse hash se torna o identificador exclusivo dos arquivos na imagem.
Duplicatas são verificadas e removidas Se outro arquivo com o mesmo hash já existir na imagem, presume-se que os dois arquivos são iguais e o novo arquivo é referenciado apontando para o arquivo existente.
Os dados exclusivos do arquivo são compactados Diferentemente do formato CAB ou de muitos outros formatos de arquivo, cada arquivo em uma extensão WIM é compactado individualmente, e não em conjunto como um fluxo de dados. Você também tem a opção de compactar tudo e, desse modo, ignorar esta etapa.
Os metadados do volume são compactados e armazenados Quando todos os arquivos estiverem arquivados, será criada uma entrada de metadados para o volume. Esse processo relaciona cada um dos arquivos adicionados à imagem referente ao volume.
Os dados XML da imagem são gerados e armazenados Essa é uma referência a cada imagem do volume que foi capturada. Se você executar o ImageX /info, por exemplo, verá esses dados XML.
O índice de dados WIM em cache é gravado Por fim, o índice de dados mestre (com os dados em cache) é gravado. Essa é a tabela de arquivos mestre para todo o WIM e inclui uma entrada por hash.
Como você pode ver, um WIM é criado arquivo por arquivo. Além disso, você terá um arquivo WIM, não importa o número de volumes que anexar à imagem.

Sobrecarga de imagens
Havia várias equipes desenvolvendo soluções semelhantes quando começamos a trabalhar no WIM. A equipe Automated Deployment Services estava desenvolvendo uma solução de geração de imagens para outro segmento de clientes. Sua abordagem tinha alguns detalhes muito interessantes de implementação, mas o mecanismo de geração de imagens, como na maioria das vezes, era baseado em setor. A equipe do Windows XP Embedded também desenvolveu um mecanismo de geração de imagens baseado em setor para permitir que os IHVs (Distribuidores de hardware independentes) implantassem suas próprias imagens durante a produção do sistema. Quando a equipe do Virtual PC foi adquirida pela Microsoft em 2003, trouxe outro formato de arquivos para VHD (Disco rígido virtual).
Todos esses formatos eram baseados no setor principal. Essas soluções atendiam às necessidades de cada segmento de clientes, mas não estavam de acordo com nossas diretrizes para WIM. Como resultado, continuamos desenvolvendo o novo formato WIM e a ferramenta de linha de comando ImageX para capturar imagens. Por fim, várias outras equipes adotaram nosso formato bem antes de ele ser anunciado como parte da versão beta do Windows Vista. A equipe de SMS, por exemplo, fez uma implementação antecipada do WIM em seu Operating System Deployment Feature Pack.

Aplicação de imagens
Vejamos agora o processo inverso: a aplicação de uma imagem.
Índice de dados WIM em cache carregado – Esta etapa é correlata à etapa final do procedimento anterior. Como esse é o índice mestre, é a primeira coisa a ser carregada do WIM depois que você especifica qual imagem de volume deverá ser aplicada.
Os metadados da imagem são recuperados e carregados O ImageX carrega os metadados específicos para cada imagem do volume.
A estrutura de diretórios é criada Para garantir que cada arquivo terá um local para ser restaurado, toda a árvore de diretórios do volume é criada.
Os dados do arquivo são extraídos Os arquivos são extraídos do WIM exatamente na mesma ordem seqüencial em que foram arquivados.
Os dados do arquivo são aplicados Nesta etapa, os arquivos são carregados, descompactados (caso a imagem do volume tenha sido compactada no WIM) e copiados em cada local referenciado. Por fim, todos os metadados de cada arquivo são aplicados.
Todos os metadados de diretório são aplicados É importante que esta seja a última etapa, porque é possível que uma ACL em um diretório impeça a aplicação correta da imagem.

Compactação flexível
Uma de nossas principais metas com o formato de geração de imagens WIM era oferecer opções de compactação flexível. Portanto, proporcionamos a capacidade de capturar uma imagem de volume com ou sem compactação, de acordo com a necessidade. A captura sem compactação é boa em situações em que a imagem não precisa ser agressivamente compactada ou quando a captura em alta velocidade é crítica.
Há alguns princípios importantes a serem lembrados quando se trata de compactação. A compactação sempre exige mais tempo para descompactar. Quanto mais agressivo o algoritmo de compactação, mais tempo será necessário para compactar um determinado conjunto de dados. E quanto mais dados você alimentar em um algoritmo de compactação, melhor será a compactação.
Imagens WIM podem ser compactadas com a compactação XPress ou LZX - e, é claro, também pode-se optar por nenhum tipo de compactação. O XPress é uma boa solução para ocasiões em que você precisa de um pouco de compactação, mas não quer dedicar muito tempo ao processo de captura. O LZX oferece excelente índice de compactação mas, como você pode imaginar, o método é consideravelmente mais demorado.
Não usar compactação resulta na captura de imagens mais rápida, mas também gera uma imagem maior. O tipo de compactação é uma opção por WIM. Uma vez capturada uma imagem de volume em um WIM, todas as imagens posteriores de volume deverão ser capturadas com a mesma definição de compactação.
Observe que, como as imagens WIM são compactadas arquivo por arquivo, a compactação não é tão completa quanto poderia ser. Essa foi uma decisão consciente - fizemos isso para que a imagem pudesse ser editada com mais facilidade. A capacidade de editar imagens após a captura é uma opção importante. Para que um arquivo seja editado após a captura da imagem, os dados do arquivo e seus metadados devem ser substituídos. Se tivéssemos compactado todo o WIM de uma vez, teríamos incrível dificuldade em oferecer suporte à edição de arquivos (ou isso seria simplesmente impossível) e a substituição de um arquivo na imagem tomaria um tempo considerável. Com esse ajuste, chegamos a um formato que é bem compactado e que ainda pode ser editado com nossas ferramentas.
Espero que este artigo tenha proporcionado um bom entendimento de como funcionam os recursos de geração de imagens desenvolvidos para o Windows Vista. Em minha próxima coluna, falarei sobre algumas das ferramentas que podem ser usadas para gerenciar e implantar imagens WIM, dando maior ênfase no ImageX e no Windows Deployment Services.

Wes Miller é gerente de desenvolvimento da Pluck (www.pluck.com (em inglês)) em Austin, Texas. Antes disso, Wes trabalhou na Winternals Software, em Austin, e na Microsoft, como gerente de programas e gerente de produtos do Windows. Para entrar em contato com Wes, você pode enviar um email para technet@getwired.com. Wes gostaria de expressar sua gratidão a John Macintyre, atual gerente de programas do WIM/ImageX da Microsoft, pela ajuda com esta coluna.


 Segredos do Windows: &#192; espera do RunOnce
Segredos do Windows
À espera do RunOnce
Raymond Chen

IMAGINE UMA instalação que precisa reiniciar o sistema no meio do processo. Por exemplo, o programa pode solicitar a atualização de uma DLL do sistema em uso no momento. Você teria de disparar uma reinicialização interveniente para instalar o novo arquivo DLL e, depois da atualização da DLL, poderia usá-la no próximo estágio da instalação.
A chave do RunOnce foi desenvolvida para esse tipo de cenário £ para ser usada por programas de instalação com o objetivo de concluir as instalações após uma reinicialização interveniente. (Isso remonta à época em que confiávamos que não haveria erro nos programas.)
O Windows® Explorer aguarda a conclusão do programa RunOnce antes de criar a área de trabalho e a barra de tarefas. Isso ocorre porque o RunOnce foi projetado para operar com programas de instalação. Como o programa RunOnce pode alterar os dados de configuração do sistema, não é conveniente que o sistema seja utilizado durante sua reconfiguração.
Por exemplo, se o programa RunOnce estiver redefinindo a base e vinculando os arquivos que acabou de instalar, e alguns desses arquivos fizerem parte de uma extensão do shell. Sem dúvida, não será conveniente que o usuário tente executar o programa ou ativar a extensão enquanto seu executável ainda estiver no processo de atualização.
Outra armadilha do princípio "para programas de instalação" é que a chave do RunOnce será processada somente se o usuário com privilégios de administrador tiver feito logon. Portanto, os usuários que não são administradores não poderão concluir a instalação. Além disso, se a chave do RunOnce for executada por não-administradores, o programa deixará de ser "de execução única" (run once), o que poderá criar um verdadeiro dilema. Como você diria, "OK, executei uma vez, não o executo novamente"? Para alterar esse estado global do sistema, você precisaria de privilégios administrativos. E, obviamente, o usuário não administrativo não possui privilégios administrativos! O programa deixaria de ser "run once" e passaria a ser "de execução consecutiva até o administrador fazer logon."

(Clique na imagem para diminuir a exibição)

(Clique na imagem para aumentar a exibição)
O RunOnce, desenvolvido para finalizar a instalação do programa, é visível na própria instalação do Windows. Quando você tenta fazer a instalação de um service pack ou a atualização para uma versão mais recente do Windows, o assistente de instalação verifica a chave do RunOnce. Se não estiver vazia, você receberá uma mensagem de erro que diz: "Hey, you still have some unfinished program installation in progress. Please finish that before you try to upgrade the operating system". Isso é oportuno, pois não faz sentido alterar o sistema operacional bem no meio da instalação de um programa.
Todo o design do RunOnce revela seu passado. O programa foi concebido no Windows 95, um sistema operacional que não fazia distinção entre administradores e não-adminstradores. Como no Windows 95, basicamente todo o mundo era administrador, um programa de instalação que utilizasse o RunOnce poderia contar que as ações do RunOnce seriam executadas na próxima reinicialização.
Em versões mais recentes do sistema operacional Windows £ especialmente o Windows Vista™ £ é possível que ninguém com privilégios de administrador faça logon durante meses. Como resultado, um programa que precisa do RunOnce para ser executado pode ter de esperar um período longo, muito longo.
Eu mesmo já vi um RunOnce perpétuo, que se readicionava à chave do RunOnce sempre que era executado. Isso vai claramente contra o intuito da chave do RunOnce, pois ela deixa de ser parte da instalação e passa a fazer parte da operação normal do programa. Além do mais, esse comportamento faz com que a instalação do Windows sempre reporte que há uma instalação em andamento.
Desse modo, o usuário nunca conseguia atualizar o sistema operacional porque esse programinha irritante não parava de dizer: "I just need to do a few more little things and I'll really be done." The program will not finish installing today, "but surely tomorrow". É o mesmo que esperar Godot, mas sem crises existenciais.

Raymond Chen, The Old New Thing, trata da história do Windows e da programação Win32. Atualmente, ele está trabalhando em um livro, que por coincidência também se chama The Old New Thing (Addison-Wesley, 2007).