 TechNet Magazine December 2007

TechNet Magazine December 2007

Comunicações: 16 novos recursos do Service Pack 1 para Exchange Server 2007

Diferentemente dos service packs típicos, o Service Pack 1 para Exchange Server 2007 oferece muito mais do que apenas hotfixes e atualizações de segurança. Aqui está uma visão geral de alguns dos mais importantes recursos novos oferecidos pelo SP1.

Tony Smith Comunicações: Replicação contínua em espera do Service Pack 1 para Exchange Server 2007

Um dos recursos mais interessantes oferecidos pelo Service Pack 1 é a Replicação Contínua em Espera. Descubra como ela pode ajudá-lo a aumentar o tempo de atividade, a limitar a perda de dados e a simplificar a manutenção e a retenção de emails.

Scott Schnoll Comunicações: Executando o Exchange com o Windows Server 2008

Preparando-se para executar o Exchange no Windows Server 2008? A equipe de Desenvolvimento do Microsoft Exchange tem feito isso já há um bom tempo, e Paul Bowden compartilha alguns conselhos e lições que aprendeu para ajudar você a se preparar.

Paul Bowden Comunicações: Implantando a Unificação de Mensagens com o Exchange Server 2007

Reunir correio de voz, funcionalidades de fax e mensagens de email em uma única caixa de correio pode parecer uma tarefa árdua, mas é mais fácil do que você imagina. Aqui está um guia para a implantação de mensagens unificadas na organização.

Jeff Goodwin Segurança: Um guia para a computação forense básica

Conheça abordagens simples e baratas de computação forense que podem ser usadas pelos principais administradores em investigações básicas.

Tom Cloward and Frank Simorjay Sistemas de rede: O Relatório de Inteligência de Segurança da Microsoft

A Microsoft coleta muitos dados sobre as ameaças de segurança enfrentadas pelos usuários dos computadores. Tenha uma visão geral das últimas tendências, como tem sido o desempenho de várias versões do Windows, quais são as regiões do mundo mais afetadas e muito mais.

Tim Rains Rede: Rastrear problemas de rede enganosos

Você recebeu uma máquina que não está se comunicando com as demais sem nenhum motivo aparente. Essas dicas podem ajudá-lo a diagnosticar e reparar rapidamente o problema.

Christopher Stoneff Do editor: A conversa vai começar

Joshua Hoffman Cartas: Com a palavra, os leitores

Caixa de ferramentas: Novos produtos para profissionais de TI

Greg Steen P+R SQL: Configuração da memória, criação de perfil de desempenho, configuração do fator de preenchimento e muito mais

Edited by Nancy Michell Utilitário em destaque: A ferramenta da Microsoft para avaliação de segurança

Este utilitário gratuito e o questionário eletrônico podem ajudar as empresas de médio porte a identificar e resolver riscos de segurança de rede.

Lance Whitney The Cable Guy: Servidor de Diretivas de Rede

O serviço Servidor de Diretivas de Rede (NPS) do Windows Server 2008 substitui o Serviço de Autenticação da Internet usado no Windows Server 2003 e traz inúmeros aprimoramentos, desde a possibilidade de impor requisitos de integridade do sistema até a capacidade de gerenciamento aperfeiçoada.

Joseph Davies Windows PowerShell: Indo mais fundo

O Windows PowerShell oferece muitos recursos que costumam passar despercebidos. Usando uma abordagem metódica de exploração dos cmdlets do Windows PowerShell, você revelará alguns recursos muito eficientes que jamais havia notado.

Don Jones Ei, Equipe de Scripts!: O retorno do WinRM

Quem matou foi o mordomo? Ele estava mesmo na dispensa com o castiçal? Nenhuma dessas perguntas é respondida aqui. Mas, após quatro longas semanas, a Equipe de Scripts está de volta com a Parte 2 da série de duas sobre o WinRM.

The Microsoft Scripting Guys Security Watch: Diretivas de senha de domínio do Windows

Até hoje, o Windows permitia apenas uma diretiva de senha por domínio. Porém, o Windows Server 2008 permite que os administradores implementem várias diretivas de senha, personalizando diferentes diretivas para vários tipos de usuário.

Derek Melber Os arquivos da área de trabalho: Implantando o Windows em um mundo virtual

Pensando em virtualização? Se não está, deveria. Descubra o que é preciso saber para implantar sistemas virtuais, o que evitar e como funcionam os bastidores da virtualização.

Wes Miller Anotações de campo: O futuro fungível

A TI se tornou "consumível" como tecnologia e percepções da vida pessoal se mesclaram à tecnologia e às percepções da vida profissional. E os efeitos na vida profissional e pessoal são profundos.

Romi Mahajan Segredos do Windows: Um joystick não precisa ser um microondas

Um exame de como a interface do joystick com force feedback DirectInput especifica forças periódicas — e alguns dos resultados inesperados.

Raymond Chen


 Comunica&#231;&#245;es: 16 novos recursos do Service Pack 1 para Exchange Server 2007
Comunicações Tony Smith

16 novos recursos do Service Pack 1 para Exchange Server 2007
Visão geral:
  • Novos recursos de gerenciamento
  • Funções de servidor aprimoradas
  • Unificação de Mensagens aperfeiçoada

A maioria dos administradores está familiarizada com o processo de download e de aplicação de Service Packs em servidores e sistemas desktop. É claro que esses downloads oferecem hotfixes e atualizações de segurança que
ajudam a manter os sistemas atualizados. No entanto, às vezes, um service pack inclui algo a mais. É isso o que acontece com a próxima versão do Service Pack 1 para Microsoft® Exchange Server 2007, que inclui muitos recursos novos e interessantes.
Esse download, que estará disponível em go.microsoft.com/fwlink/?LinkId=91472, pode ser usado para realizar uma instalação completa do Exchange Server 2007 (com todas as atualizações do SP1 em vigor) e atualizar instalações existentes do Exchange Server 2007. Embora possa ser instalado no Windows Server® 2003 SP1, SP2 e R2, o Exchange Server 2007 SP1 introduz a compatibilidade com o futuro lançamento do Windows Server 2008.
O Service Pack 1 apresenta mais recursos e aprimoramentos novos do que posso abordar nesta visão geral resumida. Por isso, o que fiz foi compilar uma lista descritiva com algumas das alterações mais relevantes que você pode usufruir ou usar para aprimorar o ambiente do Exchange. Para obter uma visão detalhada de todas as alterações, consulte "O que há de novo no Exchange Server 2007 SP1" em technet.microsoft.com/bb676323.aspx.

Alterações feitas no Console de Gerenciamento do Exchange
O Service Pack 1 acrescenta ao Console de Gerenciamento do Exchange, mostrado na Figura 1, alguns recursos novos muito práticos. Para os iniciantes, a Caixa de Ferramentas, que oferece uma coleção de ferramentas de diagnóstico, solução de problemas e recuperação instaladas por padrão com o Exchange Server 2007, agora inclui o Console de Gerenciamento de Pasta Pública, um Editor de Modelos de Detalhes e o Visualizador de Log do Roteamento.
Figure 1 Exchange Management Console with Service Pack 1
Figure 1 Exchange Management Console with Service Pack 1
É possível usar o Console de Gerenciamento do Exchange, o Console de Gerenciamento de Pasta Pública, o Editor de Modelos de Detalhes e o Visualizador de Filas para exportar listas nos painéis de resultados e de trabalhos. As listas podem ser exportadas como Texto (delimitado por tabulação), Texto (delimitado por vírgula), Texto Unicode (delimitado por tabulação) e Texto Unicode (delimitado por vírgula). Além de poder filtrar o painel de resultados no Console de Gerenciamento do Exchange, agora você pode filtrar os painéis de resultados no Console de Gerenciamento de Pasta Pública, no Editor de Modelos de Detalhes e no Visualizador de Filas.
No entanto, o que mais chama a atenção é o fato do Console de Gerenciamento do Exchange incluir algumas interfaces de gerenciamento novas (como, por exemplo, o Console de Gerenciamento de Pasta Pública que mencionei). Falarei sobre elas separadamente neste artigo.

Suporte a IPv6
Com o suporte ao Windows Server 2008 vem o suporte ao IPv6 (protocolo IP versão 6). É claro que isso depende da instalação do Exchange Server 2007 no Windows Server 2008 com as pilhas dos protocolos IPv4 e IPv6 habilitadas. Se você desabilitar o IPv4 antes da instalação, o Exchange não dará suporte a IPv6.
É possível inserir endereços IP e intervalos nos formatos IPv4 ou IPv6. Apenas uma das funções de servidor não pode enviar dados para e recebê-los de dispositivos, servidores e clientes que usem endereços IPv6. A única exceção é a função de servidor Unificação de Mensagens. Isso porque ela exige IPv4 devido a limitações em relação a alguns componentes necessários de telefonia e fala.

Interface do usuário de administração POP3 e IMAP4
O Console de Gerenciamento do Exchange inclui uma nova interface do usuário de administração para gerenciar POP3 e IMAP4. Aqui é possível definir todas as configurações de POP3 e IMAP4 do servidor Acesso para Cliente, inclusive as configurações de porta, autenticação e conexão. A Figura 2 mostra a caixa de diálogo de configuração das propriedades de IMAP4; as mesmas opções estão disponíveis para POP3.
Figure 2 Exchange Management Console for POP3/IMAP4
Figure 2 Exchange Management Console for POP3/IMAP4

Gerenciamento mais eficiente da caixa de correio
Os recursos de gerenciamento de caixa de correio do Console de Gerenciamento do Exchange agora dão suporte à criação de caixas de correio em massa para contas de usuário existentes. Enquanto isso, novos assistentes permitem que os administradores concedam ou removam direitos de Acesso Completo para uma caixa de correio e possibilitam a configuração de permissões Enviar Como em uma caixa de correio.

Novos recursos para gerenciar dados da caixa de correio
Um administrador agora pode importar e exportar arquivos .pst para gerenciar dados da caixa de correio. Também é possível fazer isso no Shell de Gerenciamento do Exchange usando os cmdlets Import-Mailbox e Export-Mailbox, respectivamente.
O MRM (Gerenciamento de Registros de Mensagens) pode ser aplicado a Pastas Padrão Gerenciadas presentes no servidor do Exchange com uma Licença de Acesso para Cliente Padrão do Exchange. (Observe que o MRM para Pastas Padrão Gerenciadas continua exigindo uma Licença de Acesso para Cliente Padrão do Exchange.) O novo parâmetro RemoveManagedFolderAndPolicy, destinado ao cmdlet Set-Mailbox, remove todas as diretivas do MRM de uma caixa de correio, remove as propriedades do MRM de todas as pastas gerenciadas criadas como parte da diretiva do MRM que foi aplicada à caixa de correio e converte todas as pastas gerenciadas em pastas padrão.
Os novos contadores do Monitor de Desempenho lhe permitem monitorar várias informações sobre a desfragmentação online – mais especificamente, quando ela foi executada pela última vez, qual foi o tempo necessário à conclusão e o que ela fez. Essas informações são muito úteis na otimização do intervalo de desfragmentação online.

Confirmação de apagamentos remotos
O Exchange Server 2007 já permite que um administrador ou usuário da conta emita um apagamento remoto para limpar todos os dados do usuário de um dispositivo móvel – um recurso de segurança muito útil em caso de perda ou roubo do dispositivo. Com o Service Pack 1, uma mensagem de confirmação é enviada quando o dispositivo reconhece a solicitação de apagamento remoto. Se originar a solicitação (usando o Outlook® Web Access ou OWA), o usuário receberá um email de confirmação. Se o administrador emitir a solicitação (usando o Console de Gerenciamento do Exchange), tanto ele quanto o usuário receberão um email de confirmação.

Um cliente OWA mais eficiente
O cliente de email baseado na Web oferece muitos aprimoramentos que proporcionam um sistema de mensagens melhor para trabalhadores em trânsito. Com o SP1, os usuários do OWA podem criar e editar listas de distribuição pessoal, bem como regras do lado do servidor. Além disso, eles podem usar os recursos Dumpster e Recuperar Itens Excluídos.
Mova e copie comandos que foram adicionados à interface do usuário, permitindo que os usuários movam e copiem pastas usando o menu acessado com o botão direito do mouse na lista de pastas. Os itens individuais em pastas de mensagens e pastas públicas também podem ser movidos e copiados clicando-se com o botão direito do mouse na lista de itens ou clicando-se em um ícone da barra de ferramentas.
Os usuários do OWA também têm acesso completo a Pastas Públicas sem usar o diretório virtual /public (e você não precisa manter um servidor back-end do Exchange 2003 para dar suporte a isso). E há suporte para os recursos de pesquisa em Pasta Pública no OWA.
Agora os recursos S/MIME permitem que os usuários leiam e escrevam mensagens de email assinadas e criptografadas (consulte a Figura 3). Há até mesmo o suporte a CNG (Cryptography API: Next Generation) e a conformidade com Suite-B. Enquanto isso, a interface do usuário do OWA pode ser personalizada tendo em vista a plena integração de aplicativos personalizados.
Figure 3 S/MIME message settings
Figure 3 S/MIME message settings

Monitoramento de composição no OWA Light
O Outlook Web Access Light – uma versão menos complexa do OWA, projetada para funcionar com praticamente todos os navegadores da Web – agora monitora a atividade enquanto um usuário está criando uma longa entrada de qualquer tipo (como, por exemplo, uma mensagem ou uma entrada no calendário) para garantir que a sessão não expire (causando a perda dos dados) enquanto ele ainda está digitando. Além disso, as mensagens são salvas automaticamente na pasta Rascunhos caso a sessão expire em decorrência da inatividade enquanto o formulário de criação da mensagem está aberto.

Desempenho aprimorado de Direct Push
O Direct Push funciona estabelecendo uma conexão HTTPS entre um dispositivo móvel e o servidor do Exchange 2007. Com o Exchange 2007 SP1, o tamanho dos cabeçalhos da solicitação HTTPS e da resposta foi reduzido, e isso diminui a quantidade de dados enviada e recebida com um dispositivo móvel.

Gerenciamento de Pasta Pública
O novo Console de Gerenciamento de Pasta Pública, mostrado na Figura 4, permite que os administradores criem, configurem e mantenham pastas públicas no Console de Gerenciamento do Exchange. Listas de endereços, diretivas de endereço de email, grupos dinâmicos de distribuição e listas de distribuição reconhecem a pasta pública. Ao visualizar a lista de endereços, a diretiva de endereço de email, o grupo dinâmico de distribuição e os destinatários do grupo de distribuição, você pode ver as pastas públicas com email habilitado incluídas nos critérios de associação do grupo.
Figure 4 Public Folder Management Console
Figure 4 Public Folder Management Console
O console de Administração da Pasta Pública do Exchange 2007 SP1 permite que você configure os direitos administrativos da pasta pública. É possível fazer isso usando o cmdlet Add-ExchangeAdministrator ou o assistente Adicionar Administrador do Exchange para adicionar um usuário à função de Administrador da Pasta Pública ou usando o cmdlet Add-PublicFolderAdministratorPermission para conceder ou negar direitos específicos a pastas públicas.

Processamento e roteamento aprimorados de mensagem
Implantados na floresta do Active Directory® , os servidores Transporte de Hub lidam com todo o fluxo de email da organização, aplicam regras de transporte e de diário, além de entregarem as mensagens nas caixas de correio dos destinatários. As mensagens enviadas para a Internet são retransmitidas pelo servidor Transporte de Hub para o servidor Transporte de Borda no perímetro da rede. O SP1 inclui aprimoramentos nessas funções de servidor.
O Exchange Server 2007 inclui um recurso de monitoramento de recursos do sistema, chamado Back Pressure, que habilita os servidores Transporte de Hub e Transporte de Borda para responder a um alto uso dos recursos. Com o SP1, o requisito de espaço em disco foi reduzido significativamente, de 4 GB para 500 MB.
O Console de Gerenciamento do Exchange no SP1 oferece mais configurações de transporte. E agora você tem a possibilidade de configurar um espaço de endereçamento X.400 como um domínio autoritativo (agora também há suporte para endereços longos X.400).
O servidor Transporte de Hub dá suporte ao enfileiramento de prioridades. A prioridade atribuída a uma mensagem por um usuário do Outlook é considerada pelo categorizador, o que ajuda a garantir que as mensagens enviadas com alta importância sejam realmente recebidas com prioridade e entregues mais rapidamente do que as designadas como sendo de baixa importância.
No Exchange 2007 SP1, o escopo de um conector de Envio em relação a um único site do Active Directory é simplificado pela adição do parâmetro IsScopedConnector nos cmdlets do Shell de Gerenciamento do Exchange e da caixa de seleção Scoped Send Connector no Console de Gerenciamento do Exchange. Quando um conector de Envio está em escopo, apenas os servidores Transporte de Hub no mesmo site do Active Directory dos servidores de origem do conector de Envio consideram esse conector de Envio nas decisões de roteamento.

Aprimoramentos na sincronização do servidor Transporte de Borda
No Exchange Server 2007 SP1, é possível usar o cmdlet Start-EdgeSynchronization para começar imediatamente a sincronização dos dados do Active Directory para o serviço de diretório ADAM (Modo de Aplicativo do Active Directory). No Exchange 2007 SP1, esse cmdlet dá suporte ao parâmetro Server, que lhe dá a possibilidade de executar o cmdlet em um computador remoto.
O cmdlet Test-EdgeSynchronization, um cmdlet de diagnóstico que informa o status da sincronização dos servidores Transporte de Borda, foi aumentado com um novo conjunto de parâmetros que lhe permite verificar os resultados da sincronização referentes a usuários individuais.

Clonagem do objeto TransportConfig
Os scripts de configuração clonados facilitam a aplicação por parte dos administradores de uma configuração consistente quando há mais de um servidor Transporte de Borda implantado no ambiente. No SP1, o objeto TransportConfig, que controla as configurações em todo o servidor referentes à função de servidor Transporte de Borda do Exchange, agora está incluído nas informações de configuração clonadas. A inclusão desse objeto aperfeiçoa – e muito – os procedimentos de implantação do servidor, de backup e de restauração.

Aperfeiçoamentos na Unificação de Mensagens
A Unificação de Mensagens foi uma parte interessante da versão inicial do Exchange Server 2007. O Service Pack 1 foi criado com base nessa funcionalidade, apresentando muitos recursos e aprimoramentos novos. Alguns dos recursos exigem que você implante o Office Communications Server 2007 na mesma floresta do Active Directory, embora haja muitos recursos que não exijam o servidor do Office Communications Server. Não posso abordar todas as alterações feitas na Unificação de Mensagens, mas passarei por algumas das adições mais importantes. Caso você queira ler mais sobre a Unificação de Mensagens, confira "Implantando a Unificação de Mensagens com o Exchange Server 2007" nesta edição da TechNet Magazine para obter mais informações.
Primeiro, abordarei alguns dos novos recursos que não exigem o Office Communications Server 2007. Agora há suporte a fluxos de mídia para atravessar firewalls e a mensagens de voz de alta fidelidade. Existe a notificação de encaminhamento quando as mensagens de voz estão saindo e o destino usa o encaminhamento de chamada. Os usuários podem acessar o Outlook Voice Access no Office Communicator 2007 sem inserir um PIN. Há uma integração entre as mensagens de email de notificação de chamada perdida e a notificação do correio de voz usando o Office Communicator 2007 (consulte a Figura 5). E muito mais.
Figure 5 Voicemail notification in Office Communicator
Figure 5 Voicemail notification in Office Communicator
Um dos aprimoramentos feitos na Unificação de Mensagens que não exige o servidor do Office Communications Server é o suporte ao protocolo SRTP (Secure Realtime Transport Protocol). A versão inicial do Exchange Server 2007 oferece dois modos de segurança: desprotegido e protegido. O modo protegido só criptografa o tráfego do protocolo SIP, e o tráfego RTP permanece descriptografado. No SP1, há três modelos: desprotegido, protegido com SIP e protegido. No modo protegido com SIP, apenas o tráfego SIP é criptografado, e não o tráfego RTP. No modo protegido, tanto o tráfego SIP quanto o RTP são criptografados. Também é possível configurar a MTLS (Mutual Transport Layer Security) em planos de discagem usando o Console de Gerenciamento do Exchange.
Outras alterações incluem o novo Assistente de Habilitação de Unificação de Mensagens, que pode ser usado para adicionar um endereço SIP ou E.164 de um usuário; a configuração do tipo de URI de um plano de discagem usando o Console de Gerenciamento do Exchange e o suporte a QoS (Qualidade de Serviço) usando DiffServ para marcar o tráfego de mídia adicionado ao SP1.

Melhor alta disponibilidade
O Service Pack 1 introduz vários recursos novos que aprimorarão a alta disponibilidade, bem como os aperfeiçoamentos feitos nos recursos de alta disponibilidade já existentes. Os recursos novos e aprimorados estendem os cenários em que é possível obter dados e disponibilidade do serviço referentes às funções de servidor do Exchange 2007. Os novos cenários permitem que as organizações separem os cenários de alta disponibilidade dos de resiliência local e implantem configurações adequadas às necessidades específicas da organização em cada área separada.
Para os iniciantes, o suporte adicionado ao Windows Server 2008 possibilita clusters de failover com várias sub-redes, bem como o suporte a novos modelos de quorum (testemunha de compartilhamento de arquivos e de discos). Também há aprimoramentos muito úteis feitos nos recursos de relatório e monitoramento do cluster, inclusive uma funcionalidade adicional projetada para o monitoramento proativo de ambientes de replicação contínua. Enquanto isso, aprimoramentos relacionados ao desempenho incluem uma redução da E/S nos discos que contêm cópias passivas dos grupos de armazenamento, cópia mais rápida do arquivo de log e movimentação mais ágil dos servidores de caixa de correio em cluster em meio aos nós.
Por fim, foram adicionados novos assistentes para melhorar o gerenciamento e a experiência de configuração (consulte a Figura 6), além de controles da interface do usuário para gerenciar servidores de caixa de correio em cluster, inclusive uma nova guia Servidor de Caixas de Correio em Cluster e uma página de configuração de CCR (replicação contínua em cluster).
Figure 6 Manage Clustered Mailbox Server Wizard
Figure 6 Manage Clustered Mailbox Server Wizard

Replicação contínua em espera
A SCR (replicação contínua em espera) usa a mesma tecnologia de envio de logs e de repetição usada pela LCR (replicação contínua local) e pela CCR para oferecer opções e configurações adicionadas de implantação. A SCR é semelhante à LCR e à CCR, embora tenha características próprias. Para uma análise mais profunda da SCR, consulte o artigo "Replicação contínua em espera do Service Pack 1 para Exchange Server 2007" de Scott Schnoll nesta edição da TechNet Magazine.

Conclusão
O Service Pack 1 para Exchange Server 2007 é claramente muito mais do que apenas hotfixes e atualizações de segurança. Ele oferece muitos recursos e aprimoramentos novos com os quais você contará em breve. Não tenho espaço para abordar todos os novos recursos e aprimoramentos, mas espero que este artigo tenha dado a você uma boa visão geral do que o espera. Para obter informações completas sobre todas as alterações feitas no Service Pack 1 mais downloads, webcasts e fóruns de discussões, visite o TechCenter do Exchange Server em technet.microsoft.com/exchange.

Tony Smith é redator técnico chefe da equipe Exchange User Education, especializando-se na Unificação de Mensagens. Antes de trabalhar para a Microsoft, Tony foi engenheiro de rede, fornecedor Microsoft e Microsoft Certified Trainer. Ele também concluiu vários projetos de publicações para a Microsoft Learning, incluindo livros e manuais práticos.
© 2007 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..


 Comunica&#231;&#245;es: Replica&#231;&#227;o cont&#237;nua em espera do Service Pack 1 para Exchange Server 2007
Comunicações Scott Schnoll

Replicação contínua em espera do Service Pack 1 para Exchange Server 2007
Visão geral:
  • Configurando a replicação contínua em espera
  • A importância da redundância
  • Como a SCR reduz o tempo de inatividade

O Service Pack 1 oferece vários recursos e aprimoramentos novos para o Exchange 20 07. Um desses novos recursos, a SCR (Replicação Contínua em Espera), foi projetado para propiciar às organizações redundância no data center e resiliência local. Como o nome indica, a SCR foi projetada
para cenários que usam ou habilitam o uso de servidores de recuperação em espera.
Caso esteja familiarizado com a versão RTM (Release to Manufacturing) do Exchange 2007, você já deve saber que ela também oferece redundância no data center e resiliência local em todos os recursos de envio de logs e suporte aos clusters de failover do Windows® . Na versão RTM, o envio de logs (conhecido oficialmente como replicação contínua) está disponível em duas formas: LCR (replicação contínua local), como mostra a Figura 1e CCR (replicação contínua em cluster), como mostra a Figura 2.
Figure 1 Local continuous replication
Figure 1 Local continuous replication
Figure 2 CCR is log shipping to a second server in a Windows failover cluster
Figure 2 CCR is log shipping to a second server in a Windows failover cluster
A replicação contínua oferece disponibilidade de dados e redundância, permitindo que os administradores habilitem e mantenham online uma segunda cópia de todos os bancos de dados de caixas de correio. Essa cópia do banco de dados representa uma primeira linha de defesa contra falha, perda ou dano de um banco de dados de produção. Em vez de precisar perder tempo localizando uma fita de backup para poder restaurar os dados, uma cópia do banco de dados pode ser ativada e transformada em um banco de dados de produção em questão de minutos.
A SCR estende os cenários em que é possível obter dados e disponibilidade do serviço para a organização. Os novos cenários lhe permitem separar as topologias de alta disponibilidade das topologias de resiliência local, além de também permitirem que você implante configurações adequadas às necessidades específicas da organização em cada área.
A versão RTM do Exchange 2007 proporciona redundância no data center e resiliência local, mas como a LCR e a CCR oferecem apenas uma cópia extra de cada banco de dados, você deve optar pela resiliência ou pela redundância. Por exemplo, considere os recursos de disponibilidade de dados e serviço oferecidos pela CCR. Implantar os nós ativo e passivo em um único data center possibilita o serviço no data center e a disponibilidade de dados, mas não a resiliência local (porque ambos os nós estão no mesmo local físico). Já implantar o nó ativo em um data center e o nó passivo em um segundo data center proporciona a resiliência, mas não a disponibilidade no data center (porque o nó passivo, que oferece esses recursos, está localizado em um segundo data center).
Com a SCR no Service Pack 1, a disponibilidade para a criação de cópias adicionais dos bancos de dados significa que a alta disponibilidade e a resiliência local não são mutuamente excludentes; é possível conseguir ambas. Por exemplo, como mostra a Figura 3, você pode combinar a SCR com a CCR para replicar grupos de armazenamento localmente em um data center principal (usando a CCR para a alta disponibilidade) e remotamente em um segundo data center ou em espera (usando a SCR para a resiliência local). O segundo data center contém um cluster em espera que pode ser ativado e rapidamente provisionado com um servidor de caixa de correio em cluster de substituição em um cenário de recuperação local.
Figure 3 CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter
Figure 3 CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter
A Figura 3 ilustra uma implantação corporativa com dois data centers, cada um com seu próprio site do Active Directory® : Redmond e Quincy. O site Redmond está localizado no data center principal (produção) e o site Quincy, em um data center secundário (backup). A CCR está implantada em Redmond para que haja redundância no data center. Com os elementos de infra-estrutura exigidos pelo Exchange 2007, os destinos da SCR são configurados em um cluster em espera no Quincy para que haja resiliência local. Esses elementos de infra-estrutura adicionais, os quais incluem os servidores de Acesso para Cliente e Transporte de Hub, servidores Active Directory e DNS, além do acesso à Internet, podem ser recursos dedicados ou não. Recursos dedicados são aqueles designados para dar suporte apenas aos usuários do data center nos quais eles residem. Já os não dedicados são aqueles recursos que dão suporte aos usuários no data center local, bem como aos usuários em outros locais. Você deve decidir se os recursos serão dedicados ou não, dependendo daquilo que for melhor para a organização. Para obter mais informações sobre recursos dedicados e não dedicados, consulte o tópico do arquivo de Ajuda do Exchange Server 2007 "Site Resilience Configurations" em technet.microsoft.com/bb201662.aspx. Também observe o uso de um novo quorum MNS (Majority Node Set). No Exchange Server 2007, a CCR usa o quorum de MNS com FSW (testemunha de compartilhamento de arquivos), e não o nó eleitor tradicional, como é possível ver na Figura 3.
Na Figura 4, um ambiente com CCR mais SCR projetado com a resiliência em mente oferece várias camadas de redundância para as caixas de correio e os serviços hospedados no servidor EXCLUS1, o que protege essas caixas de correio de falhas catastróficas de pequenas a grandes proporções.
Figure 4 Standalone mailbox servers using SCR to replicate storage groups to each other
Figure 4 Standalone mailbox servers using SCR to replicate storage groups to each other
As pequenas e médias organizações também podem usufruir a SCR. Por exemplo, como mostra a Figura 4, uma organização pode implantar dois servidores de caixa de correio autônomos (EXMBX1 E EXMBX2) e usar a SCR para replicar um ou todos os grupos de armazenamento de um servidor de caixa de correio para outro.
Nesse exemplo, EXMBX1 e EXMBX2 são servidores de produção com cinco grupos de armazenamento ativos. Cada grupo de armazenamento é uma origem de SCR correspondente ao destino de SCR no outro servidor. Em caso de falha de armazenamento ou de algum outro evento em que um grupo de armazenamento ativo configurado como uma origem de SCR esteja indisponível, o destino de SCR pode ser rapidamente ativado usando algumas tarefas administrativas no Shell de Gerenciamento do Exchange. Com o Microsoft® Office Outlook® 2007 e os recursos de portabilidade do banco de dados e de Descoberta Automática do Exchange 2007, o tempo de inatividade em caso de perda do grupo de armazenamento ativo (ou, no caso, várias perdas do grupo de armazenamento ativo) pode ser de alguns minutos apenas.

Origens e destinos de SCR
Assim como acontece com a LCR e a CCR, a SCR também usa o conceito de cópias ativas e passivas de um grupo de armazenamento, mas se refere a elas como origens e destinos de SCR, respectivamente. No entanto, as origens e os destinos de SCR são cópias do grupo de armazenamento. (Os grupos de armazenamento de recuperação não podem ser habilitados para a SCR.)
O ponto de partida para a SCR (a origem de SCR) é qualquer grupo de armazenamento em um servidor de caixa de correio autônomo ou em um servidor de caixa de correio em cluster dentro de um cluster de cópia única ou ambiente CCR. É importante observar que, muito embora a origem de SCR possa estar em um servidor de caixa de correio em cluster, a SCR propriamente dita não é uma solução em cluster e não exige o serviço de Cluster do Windows. O ponto final da SCR (o destino de SCR) pode ser um servidor de caixa de correio autônomo ou um nó em um cluster de failover no qual a função de Caixa de Correio está instalada, mas sem nenhum servidor de caixa de correio em cluster configurado no cluster.

Relações de origem e de destino
Cada grupo de armazenamento de origem da SCR pode ter um número ilimitado de destinos da SCR. Por exemplo, uma origem poderia ter um destino residindo no mesmo data center dela e um segundo destino em um data center separado. No entanto, a Microsoft recomenda que não sejam usados mais do que quatro destinos por origem. Caso opte por usar mais do que quatro destinos, você deve avaliar o provável impacto sobre o servidor de origem da SCR em termos de memória, CPU e recursos de disco, e planejar de acordo. Cada computador de destino da SCR pode ter vários servidores de origem. Tanto o computador de origem quanto o de destino devem estar executando o Service Pack 1 para Exchange 2007. O sistema operacional deve ser compatível com o Service Pack 1 para Exchange 2007 (por exemplo, o Windows Server® 2008 ou o Windows Server 2003 SP2). No entanto, independentemente do sistema operacional usado por você, a SCR não tem suporte para todos os sistemas operacionais e exige que o sistema na origem corresponda ao sistema de todos os destinos da SCR referentes a essa origem. Por isso, caso a origem da SCR esteja executando o Windows Server 2003, todos os destinos da SCR relacionados a essa origem também devem ter o Windows Server 2003 em execução.
A SCR está disponível na Standard Edition do Exchange 2007. Caso seja usado um servidor de caixa de correio em cluster em um ambiente de SCC ou CCR como origem da SCR, é necessária a Enterprise Edition do Exchange 2007. Cada destino da SCR dá suporte a um máximo de 50 instâncias (50 grupos de armazenamento replicados) com o uso da Enterprise Edition e um máximo de 5 com a Standard Edition.
Os destinos da SCR também têm requisitos a serem atendidos. Primeiro, os computadores de origem e de destino devem estar no mesmo domínio do Active Directory, ainda que possam estar nos mesmos sites do Active Directory ou em diferentes. Além disso, o banco de dados e os caminhos do arquivo de log na origem e em todos os seus destinos devem ser correspondentes para cada grupo replicado com a SCR. Por fim, quando um nó ou um servidor está configurado como sendo um destino de SCR, não é possível habilitar a LCR para nenhum grupo de armazenamento no computador de destino da SCR e adicionar nenhum servidor de caixa de correio em cluster ao cluster de failover em espera.

Comparando a SCR com a CCR e a LCR
A SCR (como mostra a Figura 5) usa a mesma tecnologia de envio de logs e de repetição usada pela LCR e pela CCR para oferecer novas opções e configurações de implantação. Assim como acontece com a LCR e a CCR, os grupos de armazenamento com a SCR habilitada não podem conter mais de um banco de dados. Além disso, a SCR não pode ser usada em um banco de dados de pasta pública, caso haja mais de um banco de dados de pasta pública na organização do Exchange.
Figure 5 SCR is log shipping to another server or a passive node in a failover cluster
Figure 5 SCR is log shipping to another server or a passive node in a failover cluster
Uma das principais diferenças em relação à SCR é que ela dá suporte a vários destinos por grupo de armazenamento, enquanto a LCR e a CCR dão suporte a apenas um destino (a cópia passiva). Outra grande diferença é que, diferentemente da CCR e da LCR, não é possível fazer o backup de uma cópia da SCR. Quando usa a SCR, os cabeçalhos do banco de dados referentes aos destinos da SCR são atualizados e os arquivos de log, truncados quando são feitos backups compatíveis no grupo de armazenamento de origem da SCR (ou, no caso da CCR e da LCR, quando os backups são feitos em cópias ativas ou passivas do grupo de armazenamento de origem da SCR).
Assim como a LCR e a CCR, o envio de logs com a SCR é contínuo e usa um modelo de pull. Assim que um novo arquivo de log é fechado e nomeado usando o número do arquivo de log em seqüência da próxima geração, o Serviço de Replicação do Microsoft Exchange em execução no computador de destino da SCR obtém os arquivos de log da transação fechada do computador de origem da SCR, os inspeciona e valida e, em seguida, os move para a pasta de arquivos de log do grupo de armazenamento em contraponto.

Tempo de latência repetido
Depois que os arquivos de log são copiados para o computador de destino da SCR, esta faz algo que a LCR e a CCR não fazem. Em vez de repetir imediatamente os arquivos de log na cópia do banco de dados, a SCR impõe uma latência de repetição interna de 50 arquivos de log e 24 horas. A SCR também lhe permite especificar um tempo de espera adicional além desses atrasos internos. Atrasar a atividade de repetição é útil em vários cenários. Por exemplo, em caso de dano lógico em um banco de dados ativo, um atraso pode impedi-lo no banco de dados de destino da SCR.
O atraso da repetição controlado por administrador é definido com um parâmetro chamado ReplayLagTime, que informa o tempo que o serviço de replicação do Exchange deve aguardar antes de repetir os arquivos de log que foram copiados para o computador de destino da SCR. O formato é Dias.Horas:Minutos:Segundos, e o valor padrão é de 24 horas. A configuração máxima permitida para o valor é de sete dias. Já a configuração mínima é de zero segundo, e definir esse valor como zero elimina efetivamente qualquer atraso na atividade de repetição do log além do atraso padrão de 50 arquivos de log.
Além de ReplayLagTime, o Exchange tem um atraso codificado interno de 50 arquivos de log, independentemente do valor de ReplayLagTime. Para determinar quando um arquivo de log deve ser repetido, o Exchange usa o maior de ReplayLagTime ou x arquivos de log, em que x=50. Trata-se de mais uma proteção para evitar a necessidade de propagar novamente um grupo de armazenamento em situações nas quais uma origem de SCR que usa a replicação contínua (por exemplo, um servidor de caixa de correio em cluster dentro de um ambiente de CCR) enfrenta um failover e um ou mais grupos de armazenamento precisam ser colocados online usando o cmdlet Restore-StorageGroupCopy. (Propagar é o processo de usar as APIs de backup de streaming do ESE (Mecanismo de Armazenamento Extensível) para criar uma cópia online do banco de dados de origem da SCR no computador de destino da SCR.) Com o atraso da atividade de repetição nos destinos da SCR, quando ocorre um failover com perdas em uma origem de SCR, as chances de que seja preciso propagar novamente as cópias da SCR serão minimizadas porque a natureza da perda de dados na origem da SCR junta as duas cópias de uma só vez.

Tempo de latência do truncamento
Na versão RTM do Exchange 2007, as regras são impostas em um ambiente de replicação contínua para que um arquivo de log não seja excluído, a menos que haja o backup dele e ele tenha sido repetido na cópia do banco de dados. Quando a SCR é usada, essa regra é modificada. A SCR (que introduz o conceito de várias cópias de bancos de dados) permite o truncamento dos arquivos de log no computador de origem da SCR assim que eles são inspecionados por todos os computadores de destino da SCR. O truncamento do log no servidor de origem da SCR não aguarda a repetição de todos os logs em todos os destinos da SCR porque as cópias de destino da SCR podem ser configuradas com tempos maiores de latência para a repetição do log.
Também é possível adicionar um atraso a mais ao truncamento do log usando um novo parâmetro chamado TruncationLagTime, que especifica por quanto tempo o serviço de replicação do Exchange deve aguardar (no formato Dias.Horas:Minutos:Segundos) antes do truncamento dos arquivos de log que foram copiados para o computador de destino da SCR e repetidos na cópia do banco de dados. O período começa assim que os arquivos de log são repetidos com êxito na cópia do banco de dados. A configuração máxima permitida para o valor é de sete dias, e a mínima é de zero segundo, embora zero segundo elimine efetivamente qualquer atraso na atividade de truncamento do log.
Em um ambiente da SCR, um thread em segundo plano é executado a cada três minutos para determinar se algum arquivo de log precisa ser truncado. Se a seqüência de geração do arquivo de log estiver abaixo do ponto de verificação do arquivo em relação ao grupo de armazenamento e o arquivo de log for posterior a ReplayLagTime + TruncationLagTime, um arquivo de log no destino da SCR será truncado.
Em um ambiente de LCR ou CCR estendido com a SCR, um arquivo de log no destino da SCR será truncado se estes quatro critérios forem atendidos: foi feito o backup do arquivo de log, a seqüência de geração do arquivo de log está abaixo do ponto de verificação do arquivo em relação ao grupo de armazenamento, a cópia passiva do grupo está em um estado que permite o truncamento do arquivo e todos os destinos da SCR inspecionaram o arquivo de log.

Habilitando e gerenciando a SCR
A SCR é habilitada com o cmdlet Enable-StorageGroupCopy no Shell de Gerenciamento do Exchange, que foi atualizado no SP1 com alguns parâmetros novos. Conforme a descrição anterior, ReplayLagTime e TruncationLagTime podem dar a você o controle sobre alguns comportamentos dos destinos da SCR. Outro parâmetro, SeedingPostponed, pode ser usado para ignorar a propagação inicial do destino da SCR. Adiar a propagação é útil em várias situações. Por exemplo, digamos que o banco de dados no grupo de armazenamento que está sendo habilitado para a SCR tenha 100 GB. Talvez você não queira que esses 100 GB de dados atravessem a rede durante os períodos de pico da produção. O parâmetro SeedingPostponed lhe dá a opção de habilitar a SCR imediatamente e de realizar uma tarefa de propagação mais tarde. Quando estiver pronto, você poderá propagar manualmente o destino da SCR usando o cmdlet Update-StorageGroupCopy.
Embora os parâmetros mencionados anteriormente sejam opcionais, um parâmetro de Enable-StorageGroupCopy é obrigatório para a SCR: StandbyMachine. Ele especifica o nome do computador que conterá o destino da SCR. O valor desse parâmetro é definido como parte do valor referente ao atributo msExchStandbyCopyMachines do grupo de armazenamento que está sendo habilitado para a SCR. O atributo msExchStandbyCopyMachines é uma cadeia de caracteres Unicode com vários valores adicionada ao esquema do Active Directory quando o Exchange 2007 SP1 é introduzido na organização do Exchange, que é um dos motivos pelos quais o SP1 exige uma atualização para o esquema do Active Directory.
O parâmetro StandbyMachine é básico na SCR, e vários cmdlets foram atualizados no SP1 para usar esse parâmetro na habilitação e no gerenciamento dos destinos da SCR. Os cmdlets atualizados estão descritos na Figura 6.
Figure 6 Cmdlets that use the StandbyMachine parameter (Close Figure 6)

Cmdlet | Descrição
Disable-StorageGroupCopy | Desabilita um destino de SCR para um grupo de armazenamento.
Get-StorageGroupCopyStatus | Determina a integridade atual do destino de SCR.
New-StorageGroup | Cria um novo grupo de armazenamento com a SCR habilitada sem que seja preciso habilitar a SCR separadamente usando o cmdlet Enable-StorageGroupCopy.
Restore-StorageGroupCopy | Desabilita a SCR e viabiliza a montagem de um banco de dados de destino da SCR com uma operação Mount-Database como parte de um procedimento de recuperação.
Resume-StorageGroupCopy | Usado a fim de reiniciar a replicação contínua para um grupo de armazenamento com a SCR suspensa.
Suspend-StorageGroupCopy | Suspende a atividade de replicação contínua para um grupo de armazenamento com a SCR habilitada.
Update-StorageGroupCopy | Usado para propagar ou propagar novamente um grupo de armazenamento de destino da SCR.

Ativando destinos da SCR
A SCR oferece uma ou mais cópias atualizadas dos dados, que podem ser usados caso os dados originais sejam perdidos ou inutilizados. O processo de criação de uma cópia de destino da SCR e de reprovisioná-la como um banco de dados de produção é chamado de ativação. A ativação ocorre como parte do processo de recuperação, que assumirá a forma de portabilidade do banco de dados ou de uma das duas opções de recuperação da configuração (/m:RecoverServer para recuperar um servidor autônomo ou /RecoverCMS para recuperar um servidor de caixa de correio em cluster).

Como você deve usar a SCR
Vejamos como uma empresa fictícia pode usar a SCR e a portabilidade do banco de dados na recuperação após uma falha em um banco de dados de caixa de correio. Após a identificação do dano no banco de dados de produção, o administrador ativa o banco de dados de destino da SCR usando a portabilidade do banco de dados.
A organização implantou o Exchange 2007 com SP1 e optou por usufruir a SCR para oferecer uma cópia de um grupo de armazenamento em um servidor de caixa de correio remoto. Os servidores de caixa de correio de origem e de destino estão no mesmo site do Active Directory e configurados para usar servidores DNS integrados ao Active Directory. O intervalo de replicação do Active Directory é configurado para 15 minutos.

Habilitando a SCR e preparando a recuperação
A SCR é configurada para que os arquivos de log da transação sejam replicados para um único grupo de armazenamento, SG1, que contém um único banco de dados, MBX1. Os caminhos para os arquivos do grupo de armazenamento e para o arquivo do banco de dados são C:\SG1 e C:\SG1\MBX1.EDB. Nesse caso, EXMBX1 é a origem da SCR e EXMBX2, o destino da SCR. Isso foi configurado como você vê aqui:
Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
Após a habilitação da SCR, a integridade e o status da SCR para SG1 foram verificados com o cmdlet Get-StorageGroupCopyStatus:
Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2
Para economizar tempo durante o processo de ativação do destino da SCR, EXMBX2 é pré-configurado com um grupo de armazenamento SG1PORT e o banco de dados MBX1PORT, que será usado como parte das operações de portabilidade do banco de dados. SG1PORT e MBX1PORT estão separados do grupo de armazenamento do destino da SCR e dos arquivos do banco de dados. Por isso, os caminhos para SG1PORT e MBX1PORT são configurados com um caminho temporário que não entra em conflito com os caminhos de destino da SCR. SG1PORT e MBX1PORT só serão usados como objetos de portabilidade do banco de dados; o grupo de armazenamento real e os arquivos do banco de dados para SG1PORT não são necessários. Por isso, o administrador desmonta MBX1PORT e exclui todos os arquivos do grupo de armazenamento. O grupo de armazenamento e os objetos do banco de dados permanecem no Active Directory porque serão usados posteriormente na portabilidade do banco de dados durante o processo de recuperação.

Ativação e recuperação
Uma entrada do log de eventos do aplicativo indica que o banco de dados de origem da SCR está danificado fisicamente. Como a SCR foi habilitada para SG1, é tomada a decisão de realizar uma ativação manual do banco de dados de destino da SCR para SG1 e de usar a portabilidade do banco de dados para restaurar a disponibilidade dos dados. A ativação da cópia de destino da SCR começa desmontando MBX1 em SG1 usando o seguinte cmdlet:
Dismount-Database EXMBX1\SG1\MBX1
Em seguida, a montagem do banco de dados de destino da SCR é viabilizada, e as caixas de correio originalmente em MBX1 são movidas para MBX1PORT.
O processo de desabilitação da SCR e de viabilização da montagem do banco de dados de destino da SCR envolvem a execução do cmdlet Restore-StorageGroupCopy. Essa tarefa marca o banco de dados do grupo de armazenamento como sendo montável e oferece um relatório sobre a perda de dados, caso haja alguma, resultante da montagem do banco de dados no grupo de armazenamento. Ele também verifica se todos os arquivos de log gerados pela cópia ativa do grupo de armazenamento estão presentes no local do arquivo do grupo de armazenamento da cópia passiva. Se algum arquivo de log não for encontrado, a operação também tentará copiá-lo. O seguinte cmdlet é usado para viabilizar a montagem do banco de dados de destino da SCR:
Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
No exemplo, os arquivos de log do grupo de armazenamento de origem da SCR estão disponíveis para cópia. Caso esses arquivos não estejam disponíveis (por exemplo, porque o computador de origem da SCR está desligado), o parâmetro Force deve ser adicionado à tarefa Restore-StorageGroupCopy. Do contrário, Restore-StorageGroupCopy sempre tentará se conectar à origem da SCR para copiar todos os arquivos de log não encontrados e, se a origem da SCR estiver indisponível, haverá uma falha na tarefa Restore-StorageGroupCopy e o banco de dados não será viabilizado para a montagem. Adicionar o parâmetro Force informa à tarefa Restore-StorageGroupCopy que os arquivos de origem não estão disponíveis, quando ela ignora a tentativa de conexão e continua viabilizando a montagem do banco de dados de destino da SCR.
Após a conclusão do comando Restore-StorageGroupCopy, o administrador deve verificar se o banco de dados está em um estado de desligamento normal. Caso o banco de dados esteja em um estado de desligamento anormal (consulte technet.microsoft.com/aa996757.aspx), ele deve ser colocado em um desligamento normal. Se o prefixo do arquivo de log do grupo de armazenamento (por exemplo, E00 ou E01) for o mesmo da origem da SCR (EXMBX1\SG1) e do grupo de armazenamento no destino da SCR (SG1PORT) a ser usado na portabilidade do banco de dados (EXMBX2\SG1PORT), não será necessário executar Eseutil no modo de recuperação, e a operação de montagem do banco de dados final o colocará em um estado de desligamento normal após a repetição de todos os arquivos de log replicados. Caso o banco de dados não esteja em um estado de desligamento normal, o modo de recuperação (Eseutil /r) do Exchange Server Database Utilities (Eseutil) deve ser executado no banco de dados.
Assim que o banco de dados estiver em um estado de desligamento normal, será possível executar dois comandos que atualizam o Active Directory com novos locais referentes aos arquivos do grupo de armazenamento e ao arquivo do banco de dados. Estes comandos alteram os caminhos para SG1PORT e MBX1 dos caminhos originais para os caminhos referentes ao grupo de armazenamento temporário e ao banco de dados (SG1PORT e MBX1PORT):
Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly
O parâmetro –ConfigurationOnly deve ser incluído nos comandos anteriores para que apenas as definições de configuração referentes a esses objetos sejam atualizadas no Active Directory. Nenhum dado ou arquivo é movido, e eles nem precisam ser porque a SCR já replicou os dados para C:\SG1 em EXMBX2.
A próxima etapa é configurar o banco de dados (MBX1PORT) para permitir que ele próprio seja substituído durante uma operação de restauração. Isso pode ser feito marcando a caixa de seleção da configuração "Este banco de dados pode ser substituído por uma restauração" nas propriedades do objeto de banco de dados no Console de Gerenciamento do Exchange ou usando o seguinte comando no Shell de Gerenciamento do Exchange:
Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true
Assim que você tiver configurado o banco de dados para que ele próprio seja substituído, a próxima etapa é montar o banco de dados usando o seguinte comando:
Mount-Database EXMBX2\SG1PORT\MBX1PORT
Após a montagem do banco de dados, as caixas de correio hospedadas no banco de dados de origem da SCR (SG1\MBX1) devem ser movidas de forma a apontar para MBX1PORT em EXMBX2. Basta executar o cmdlet Get-Mailbox e associar a saída ao cmdlet Move-Mailbox. Durante esse processo, é importante que o Atendedor do Sistema Exchange e as caixas de correio do sistema não sejam incluídos na saída do cmdlet Get-Mailbox associado ao cmdlet Move-Mailbox. Esses objetos de caixa de correio não precisam ser movidos e nem devem. O seguinte comando é executado para mover todas as caixas de correio do usuário e excluir as caixas de correio do sistema:
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT
Neste ponto, agora o acesso para cliente a MBX1PORT é possível. No entanto, a possibilidade dos usuários realmente acessarem suas caixas de correio depois que elas foram movidas de EXMBX1\SG1\MBX1 para EXMBX2\SG1PORT\MBX1PORT depende da latência de replicação do Active Directory; ou seja, dependendo do número de servidores de diretório, talvez a propagação da atualização em todo o ambiente demore um pouco. Além disso, os métodos de acesso para cliente importam. Os clientes de mensagens que estejam executando o Outlook 2007 e os que não estejam usando o Outlook terão acesso à caixa de correio do usuário depois que os servidores de diretório usados pelo servidor Acesso para Cliente forem atualizados com os novos caminhos. Os clientes de mensagens que estejam executando o Outlook 2003 e todas as versões anteriores exigirão que o perfil de mensagens da área de trabalho do usuário seja atualizado com o novo nome do servidor.

Etapas finais
Depois que os clientes tiverem acesso a caixas de correio e a dados de caixa de correio, a etapa final é estabelecer a redundância reabilitando a SCR. Isso é feito com a remoção de todos os grupos de armazenamento e dos arquivos de banco de dados restantes de EXMBX1. Após a remoção dos arquivos, os caminhos para EXMBX1\SG1\MBX1 podem ser movidos para um local temporário, e EXMBX1 pode se tornar um destino da SCR de EXMBX2.

Scott Schnoll é redator técnico chefe da equipe do Exchange Server na Microsoft, elaborando conteúdo para o Exchange Server 2007. Antes de trabalhar na Microsoft, Scott escreveu Exchange Server 2003 Distilled (Exchange Server 2003 Elaborado; Addison-Wesley Professional, 2004) e foi o autor-chefe do Exchange 2000 Server: The Complete Reference (Exchange 2000 Server: A referência completa; McGraw-Hill/OsborneMedia, 2001).


 Comunica&#231;&#245;es: Executando o Exchange com o Windows Server 2008
Comunicações Paul Bowden

Executando o Exchange com o Windows Server 2008
Visão geral:
  • Configurando o Exchange no Windows Server 2008
  • Dicas e truques de configuração
  • Conheça o ambiente do Exchange

Na equipe de desenvolvimento do Exchange da Microsoft, o meu trabalho é definir a agenda, o ritmo e as prioridades dos integrantes. A minha função é conhecida na Microsoft como gerente de versão. Isso pode ser mais ou menos traduzido como um gerente de projeto técnico de outras empresas. E como qualquer um que já tenha trabalhando
nesta função sabe, é preciso conhecimento, habilidades, muito trabalho e o respeito da equipe para entregar um bom produto no tempo certo. Ao trabalhar com uma equipe inteligente e talentosa, você não obterá essa credibilidade do dia para a noite — ela terá de ser conquistada.
Uma forma de provar a sua coragem é executar a sua caixa de correio em um servidor de "ração para cachorros" — um servidor de produção com uma versão de pré-lançamento do Exchange. Esse é um ambiente flexível onde fazemos atualizações para as novas compilações do Exchange a cada duas a três semanas. Essa configuração nos permite testar o software em um ambiente de mundo real com interação humana real. Nós até mesmo executamos as nossas caixas de correio nas compilações de teste mais recentes. Eu estive lá e esta é a minha história.

Preparando-se para o "Longhorn"
No final de 2006, quando tínhamos acabado de lançar o Exchange Server 2007, um novo sistema operacional já aparecia no horizonte — o Windows Server®, de codinome "Longhorn". Quando começamos a traçar planos para o nosso primeiro service pack da nova plataforma do Exchange, ficou óbvio que as agendas do Exchange e do Windows® estavam em caminhos semelhantes e que o "Longhorn" (agora chamado de Windows Server 2008) seria bem grande. Foi nesse momento que decidimos fazer a engenharia do Exchange Server 2007 SP1 tanto para o Windows Server 2003 como para o Windows Server 2008. Existe uma quantidade significativa de coordenação e de planejamento necessária ao suporte a um aplicativo corporativo em mais de uma versão do Windows. Por exemplo, o Exchange funciona em estreita relação com o IIS e o Windows Server 2008 inclui uma nova versão, o IIS 7.0.
Eu me lembro de ter instalado o Windows Server 2008 pela primeira vez em meu laboratório no fim de dezembro de 2006. Duas descobertas se fixaram em minha mente sobre aquele dia: a primeira, que a instalação foi muito rápida e a segunda, que o uso das ferramentas de gerenciamento, embora muito diferentes do Windows Server 2003, era perfeitamente intuitivo.
Em nossos laboratórios principais, o Windows Server 2008 é instalado em um terço do tempo necessário para a instalação do Windows Server 2003. Um dos motivos para isso é que os componentes opcionais, não imprescindíveis para a execução do sistema operacional, não são configurados nesse momento. Isso é ótimo para a redução da superfície de ataque do computador e para manter o processo o mais simples possível. Ninguém gosta de confusões desnecessárias. A desvantagem típica desse tipo de instalação tem sido a obrigação de inserir o disco sempre que você quiser incluir um componente adicional. Mas com o Windows Server 2008, todos os arquivos são copiados para uma pasta SxS (pronuncia-se side-by-side, ou lado a lado). Você utiliza a ferramenta Gerenciador de Servidores para configurar os componentes necessários e o sistema operacional descobre qual o arquivo que deve ser copiado.
Neste ponto, devo mencionar algo chamado Server Core. É um modo do Windows Server 2008 onde você instala o mínimo absoluto do sistema operacional. Nele, normalmente você interage com o console do servidor por meio de um prompt de comando; nem mesmo o Explorer é instalado. Esse modo é adequado para servidores de infra-estrutura como controladores de domínio e servidores DNS. No entanto, não será possível executar todos os tipos de aplicação aqui. O Exchange usa extensivamente código gerenciado e isso o impede de oferecer suporte a instalações Server Core.

Configurando o Exchange
Eu adoro pegar as mídias físicas do Windows Server 2008 e do Exchange Server 2007 SP1 e instalar em uma máquina desde o início sem qualquer outro download ou pré-requisito. A melhor maneira de configurar uma instalação do Windows Server 2008 para o Exchange é usar a ferramenta ServerManagerCmd. Eu criei um arquivo de resposta XML, mostrado na Figura 1, e que instala somente os componentes suficientes do sistema operacional para permitir a instalação e a execução do Exchange no Windows Server 2008. Depois de instalar o novo sistema operacional, basta executar este comando para configurar o sistema:
Figure 1 ServerManagerCmd answer file for Exchange (Close Figure 1)
<!-- Arquivo de resposta ServerManagerCmd compatível com o Windows Server 2008        --> <!-- Uso: ServerManagerCmd -ip Exchange.xml                                -->

<ServerManagerConfiguration Action="Instalar" xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- BASE: Instalar o recurso PowerShell 1.0  --> <Feature Id="PowerShell"/>

    <!-- PREPARESCHEMA: Instalar LDIFDE e outras ferramentas de diretório, como LDP e ADSIEdit --> <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX: Instalar a função de servidor web com componentes filhos adicionais --> <Role Id="Web-Server"/> <RoleService Id="Web-Metabase"/> <RoleService Id="Web-Lgcy-Mgmt-Console"/> <RoleService Id="Web-Basic-Auth"/> <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS: Instalar os três tipos de autenticação para OWA, compactação GZip e suporte ao Outlook em Qualquer Lugar --> <RoleService Id="Web-ISAPI-Ext"/> <RoleService Id="Web-Digest-Auth"/> <RoleService Id="Web-Dyn-Compression"/> <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE: Instalar o AD LDS (anteriormente conhecido como ADAM) --> <Role Id="ADLDS"/>

    <!-- UM: Instalar os componentes do Windows Media Player --> <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>

ServerManagerCmd –ip Exchange.xml
Quando tudo estiver concluído, e o sistema reiniciado, você terá tudo o que precisa para instalar as funções do Exchange como a Caixa de Correio, o Acesso para Cliente, o Transporte de Hub, o Transporte de Borda e a Unificação de Mensagens.
Outro truque muito útil é usar o ServerManagerCmd com a opção –query. Isso enumera a lista total de funções e de serviços e mostra quais deles estão realmente configurados (representados pelo texto em verde da Figura 2).
Figure 2 Enumerating Exchange roles and services
Figure 2 Enumerating Exchange roles and services
Bom, vamos voltar à história. Passamos aqueles primeiros meses de 2007 no laboratório, tentando descobrir quais eram as alterações necessárias para a obtenção do melhor desempenho no Windows Server 2008. Se existe algo que aprendi é que você pode permanecer instalando e testando o software à exaustão no laboratório até ficar azul, mas a verdadeira medida de qualidade está em implantações reais e ao vivo com usuários reais e ativos. E é exatamente por isso que usamos nossos produtos como "ração para cachorros" — testando-os em um ambiente real, diário e feito para a conclusão do trabalho. O lançamento do Windows Server 2008 Beta 3 em abril de 2007 foi o momento decisivo — era hora de seguirmos em frente e de implantá-lo em produção.
Eu me sentei ali olhando por cima do ombro de um membro da equipe de operações à medida que íamos implantando o primeiro conjunto de servidores Exchange no Windows Server 2008. A configuração do Exchange foi tranqüila e todos os serviços foram iniciados. Tudo o que precisávamos naquele momento era mover uma caixa de correio e descobrir se o processo realmente tinha funcionado. Ofereci-me para fazer as verificações. Eu tinha uma caixa de correio de 2 GB e, 26 minutos depois, lá estava eu, funcionando perfeitamente e enviando emails pelo Exchange do Windows Server 2008. Sucesso!

Lições aprendidas
Desde aquela primeira instalação no Windows Server 2008, temos feito ajustes finos e procurado garantir que estávamos realmente prontos. E tivemos que tomar algumas decisões fundamentais de implantação pelo caminho.
Instalação Você pode usar o Exchange Server 2007 SP1 como uma atualização para a instalação original do Exchange Server 2007 — o que eu chamo de versão RTM do Exchange 2007 (de release to manufacturing, ou liberada para fabricação) — ou pode fazer uma instalação direta com a mídia do Exchange Server 2007 SP1 em um computador novo. Isso é importante porque você não pode instalar a versão RTM do Exchange Server 2007 em um computador que esteja executando o Windows Server 2008.
Atualizações Embora você possa atualizar o sistema operacional Windows Server 2003 SP2 para o Windows Server 2008, existem alguns componentes que precisam ser desinstalados primeiro. Um deles é o Windows PowerShell™. Isso está no coração do gerenciamento do Exchange; até mesmo a configuração do Exchange se baseia no Windows PowerShell. Por esse motivo, não podemos oferecer suporte a atualizações em vigor do sistema operacional quando o Exchange já estiver instalado. Para muitos, isso normalmente significa que você vai querer instalar o Windows Server 2008 em um computador novo e então instalar o Exchange Server 2007 SP1.
IPv6 O Exchange foi projetado para aproveitar as vantagens dos diversos recursos novos do Windows Server 2008. Por exemplo, o IPv6 é instalado por padrão e dois servidores Exchange executados no novo sistema operacional o utilizarão automaticamente para se comunicarem entre si. As interfaces do Console de Gerenciamento do Exchange também aceitarão intervalos de endereços IPv6. É preciso fazer uma advertência: o Exchange ainda exige que um endereço IPv4 seja associado a cada interface de rede.
Controladores de domínio somente leitura Uma alteração de alguma forma radical para as implantações do Active Directory® é a noção de um controlador de domínio somente leitura (ou servidor de catálogo global). Isso permite que as empresas implantem um servidor Active Directory que receba replicação unidirecional e que não possa replicar as alterações de volta. Ele pode ser útil em uma filial ou em um escritório remoto, onde a segurança física não pode ser garantida. Infelizmente, o Exchange Server 2007 SP1 não consegue usar um controlador de domínio somente leitura e exige o acesso a uma partição gravável normal do Active Directory.

O ambiente do Exchange
Recursos do Exchange e do Windows Server
  • TechCenter do Windows Server 2008
  • TechCenter do Exchange Server
  • Central de avaliação TechNet
  • Laboratórios virtuais do Windows Server 2008

Quando se trata de escolher o nível do sistema operacional para a sua implantação, você tem a flexibilidade de executar uma variedade de configurações, como mostrado na Figura 3.
Figure 3 Exchange environment matrix (Close Figure 3)

Versão do Exchange | Sistema operacional do servidor | Controlador de domínio
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2003
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2003
Outra consideração trata de implantações de versões mistas. Certamente você possui uma mistura de versões do Exchange e do Windows operando entre si. Por exemplo, você pode implantar o Exchange Server 2007 SP1 no Windows Server 2008 para servidores de Acesso para Cliente e fazê-los acessar servidores de caixas de correio da versão RTM do Exchange Server 2007 no Windows Server 2003.
Existem algumas nuances sobre as versões anteriores do Exchange e do Active Directory do Windows Server 2008 que devem ser conhecidas. Se você possuir o Exchange Server 2003 SP2 ou posterior, poderá implantar e usar os controladores de domínio do Windows Server 2008 em seu ambiente. No entanto, se você ainda tiver o Exchange 2000, terá de adiar a implantação de controladores de domínio do Windows Server 2008 no site do Active Directory onde estão esses servidores Exchange ou codificar as configurações do DSAccess (Directory Service Access) para que o Exchange 2000 não tente usar os controladores de domínio do Windows Server 2008.

Considerações finais
Nós nos esforçamos bastante para que o Exchange 2007 SP1 funcione bem nas plataformas do Windows Server 2003 e do Windows Server 2008. No Exchange, tentamos oferecer a flexibilidade de implantação e cenários de um bom trabalho em conjunto. Acho que você ficará agradavelmente surpreso com a facilidade e com a velocidade de implantação do Exchange no Windows Server 2008. Você descobrirá também alguns aprimoramentos sutis feitos no desempenho e na escalabilidade — esta extremamente superior — do servidor de Acesso para Cliente para usuários do Outlook em Qualquer Lugar.
O Windows Server 2008 oferece a plataforma para a futura inovação do espaço de mensagens. Você não ficará desapontado.

Paul Bowden é gerente-chefe de programa da equipe do Exchange Server. Ele gasta grande parte de seu tempo livre reconfirmando as informações de sua conta no PayPal, quando solicitado.


 Comunica&#231;&#245;es: Implantando a Unifica&#231;&#227;o de Mensagens com o Exchange Server 2007
Comunicações Jeff Goodwin

Implantando a Unificação de Mensagens com o Exchange Server 2007
Visão geral:
  • Noções básicas de telefonia
  • Considerações sobre o design de Unificação de Mensagens
  • Migrando seus usuários

Então você decidiu implantar a Unificação de Mensagens do Exchange Server 2007 em seu ambiente. Você instalou uma função de servidor Unificação de Mensagens, a integrou ao seu PBX existente e agora você e outros 10 funcionários da empresa possuem correio de voz, email e mensagens de fax armazenadas no Exchange. Em alguma ocasião talvez
você tenha considerado esta uma grande conquista. Mas como você implantará os mesmos recursos para milhares de assinantes, espalhados por vários locais, sem causar impacto nos negócios?
Espero que este artigo o ajude. Eu o escrevi para ajudá-lo a compreender como implantar a Unificação de Mensagens em seu ambiente e para ajudar a desmistificar os conceitos de telefone associados a uma implantação como essa. Se você precisar de assistência com a instalação, configuração ou recursos da Unificação de Mensagens do Exchange Server 2007, consulte a barra lateral "Recursos da Unificação de Mensagens", no final deste artigo. Além disso, a Microsoft identificou empresas como a Unified Messaging Specialists para auxiliar clientes fornecendo consultoria, design e implantação da Unificação de Mensagens do Exchange Server 2007. Se você precisar de ajuda com a instalação, configuração ou implantação, entre em contato com um desses especialistas, também listados na barra lateral.

Introdução
As tecnologias de unificação de mensagens não são novas para o Exchange; muitas organizações oferecem produtos assim para integração com ele. No entanto, essa é a primeira versão do Exchange que oferece suporte nativo à unificação de mensagens. Desde a sua introdução, muitos clientes implantaram a Unificação de Mensagens do Exchange Server 2007 em pequenos grupos em suas organizações. No entanto, por vários motivos, a Unificação de Mensagens nem sempre é implantada para todos os usuários. Um problema é que muitos administradores do Exchange não conhecem bem os conceitos de telefonia e as tecnologias necessárias para a implementação de serviços de unificação de mensagens e têm lutado com o projeto e com a implantação dessas soluções em suas empresas.
Assim como acontece com qualquer projeto de implantação, uma abordagem de fases normalmente rende os melhores resultados. Os cinco estágios — planejamento da arquitetura, o teste da solução, o piloto de uma comunidade de usuários e a migração dos usuários para o novo sistema — são aspectos de um projeto de unificação de mensagens que devem ser considerados. É fundamental que você inclua os grupos de TI e de telecomunicações de sua organização no planejamento do projeto.
Muitos recursos que os usuários aceitam como certos em plataformas de correio de voz tradicionais devem ser duplicados ou, se isso não for possível, uma solução alternativa deve ser projetada para diminuir o impacto nas comunidades de usuários quando um novo sistema for implementado. Essa é uma área fundamental em que a sua equipe de telecomunicações deverá ajudá-lo. Ao mesmo tempo, a equipe de telecomunicações terá de aprender com a equipe de TI o que é preciso para administrar, solucionar problemas e oferecer suporte à nova plataforma de correio de voz após a implantação.

Noções básicas de telefonia
Você verá que o planejamento é muito mais fácil se você compreender a arquitetura básica, o fluxo de chamadas e as terminologias relacionadas à unificação de mensagens. A Figura 1 ilustra um exemplo de solução de unificação de mensagens integrada a um sistema de telefonia corporativo existente. Agora vamos examinar mais de perto alguns dos conceitos e das tecnologias mais comuns que é provável que você encontre em uma dessas implantações.
Figure 1 A PBX-to-Unified Messaging solution
Figure 1 A PBX-to-Unified Messaging solution
Um PBX (central privada de comutação telefônica) é uma rede telefônica privada usada em uma empresa. Em um sistema desse tipo, normalmente cada usuário possui um telefone conectado ao PBX, a partir do qual as chamadas podem ser feitas para outros usuários internos por meio da discagem de uma extensão (quase sempre de quatro ou cinco dígitos) e para telefones externos.
Quando clientes corporativos possuem muitos locais com PBXs, algumas vezes decidem conectar os sistemas por meio de tecnologias de rede específicas do fornecedor do PBX. Isso permite que todos os usuários dos PBXs em rede liguem uns para os outros simplesmente discando uma extensão.
A unificação de mensagens envolve a integração de dois sistemas distintos: o sistema de mensagens do Exchange e o sistema físico de telefonia. As comunicações entre o servidor de Unificação de Mensagens e a arquitetura de telefonia são estabelecidas por meio do protocolo SIP. Algumas tecnologias de PBX podem se comunicar diretamente com o servidor de Unificação de Mensagens sobre SIP; outros exigirão um gateway SIP. Na Figura 1, o PBX está conectado a um gateway SIP por meio de uma linha T1. Quando uma chamada é encaminhada para a Unificação de Mensagens, o PBX envia informações (o número telefônico do chamador, o número telefônico do chamado e algum tipo de código de motivo) para o gateway SIP, de forma que o servidor de Unificação de Mensagens compreenda para quem é a chamada.
Alguns PBXs podem ser ligados entre si por uma rede IP. A ligação da telefonia em rede oferece o redirecionamento de chamadas sobre a rede IP para uma solução de correio de voz centralizada. Por exemplo, se você examinar a Figura 2, observará que Zurique está ligada em rede com Londres.
Figure 2 A more complex Unified Messaging deployment
Figure 2 A more complex Unified Messaging deployment

Fluxo de chamadas
Recursos da Unificação de Mensagens
  • Catálogo de especialistas em Unificação de Mensagens
  • TechCenter da Unificação de Mensagens do Exchange
  • Gateways SIP compatíveis
  • Orientador de telefonia
  • Observações sobre a configuração PBX

Suponha que uma chamada seja feita para um assinante da Unificação de Mensagens a partir de um chamador externo. Nesse caso, o assinante da Unificação de Mensagens não está no escritório e o telefone não é atendido. Você pode seguir o caminho da mensagem na Figura 1.
O PBX envia a chamada para o gateway SIP, que a negocia via SIP sobre TCP com o servidor de Unificação de Mensagens. O servidor recebe dados de integração do gateway SIP, que lhe diz para quem é a chamada. O servidor de Unificação de Mensagens reproduz a saudação do assinante e permite que o chamador externo grave uma mensagem. Essa mensagem é entregue na caixa de correio do Exchange do assinante da Unificação de Mensagens.
Esse fluxo de chamadas é uma descrição muito simplificada do que ocorre. É importante compreender que quando uma mensagem é gravada, o servidor de Unificação de Mensagens a encaminha para o servidor Transporte de Hub via SMTP para entregá-la ao servidor Caixa de Correio.
Como assinantes da Unificação de Mensagens, os usuários agora têm acesso às caixas de correio do Exchange via telefone (usando o Outlook® Voice Access) ou computador (usando o Outlook 2007 ou o Outlook Web Access). Mas os assinantes também podem acessar mensagens por telefone usando o Outlook 2007 ou o Outlook Web Access com um recurso chamado Tocar no Telefone, que permite ao assinante fazer com que a Unificação de Mensagens reproduza a mensagem selecionada ao tocar um telefone especificado em vez de acessá-la pelo computador. Quando esse método é usado, o servidor de Unificação de Mensagens interage com os servidores de Acesso para Cliente e de Caixa de Correio. É importante compreender isso porque se você colocar o servidor de Unificação de Mensagens em um escritório remoto que não possui um servidor de Acesso para Cliente local, ele terá de atravessar a WAN para entrar em contato com o servidor de Acesso para Cliente e isso poderá causar um desempenho lento.

Design do sistema
Existem dois designs de arquitetura principal do Exchange que os clientes poderão escolher: o centralizado ou o descentralizado. Como regra geral, a arquitetura da Unificação de Mensagens seguirá a arquitetura do seu Exchange, o que significa que em qualquer lugar que você implantar um servidor de Caixa de Correio, um servidor de Unificação de Mensagens também será implantado. É claro que há exceções para qualquer regra.
Durante o projeto da sua arquitetura de Unificação de Mensagens, existem cinco áreas básicas que você deve considerar.
  • O posicionamento do servidor
  • O número de servidores de Unificação de Mensagens
  • O gateway SIP
  • Armazenamento de caixas de correio
  • A configuração do site de Unificação de Mensagens
E não se esqueçam da continuidade de negócios. Como regra geral, o seu plano de recuperação de desastres relacionado ao Exchange pode ser usado na determinação de elementos relevantes para a Unificação de Mensagens.
Cenários de exemplo de implantação podem ajudá-lo a compreender as funções do servidor Unificação de Mensagens. A Figura 2 ilustra claramente uma grande implantação corporativa do Exchange Server 2007 com Unificação de Mensagens.
Nesse design mais complexo, os datacenters principais são Seattle e Londres. Os servidores de Unificação de Mensagens desses locais servem às suas respectivas comunidades de usuários, já que os servidores de Caixa de Correio e de Transporte de Hub são locais. Ambos os sites possuem PBXs IP que oferecem cobertura de chamadas para o servidor local de Unificação de Mensagens para o atendimento de chamadas.
Os sites de tamanho médio estão localizados em Nova York e Glasgow. Os servidores de Unificação de Mensagens desses locais servem às suas respectivas comunidades de usuários, já que os servidores de Caixa de Correio e de Transporte de Hub são locais. Assim como acontece com os datacenters principais, ambos os locais possuem PBXs IP que oferecem cobertura de chamadas para que o servidor local de Unificação de Mensagens atenda chamadas.
Os sites menores não possuem servidores de Caixa de Correio ou de Transporte de Hub locais, mas oferecem recursos de Unificação de Mensagens a partir dos datacenters principais. Austin possui um PBX NEC que utiliza conectividade analógica com um gateway SIP local. As chamadas para usuários finais locais são encaminhadas para o gateway SIP, que negocia com o servidor de Unificação de Mensagens em Seattle o fornecimento de atendimento de chamadas na Unificação de Mensagens.
Zurique possui um Gerenciador de Comunicação Avaya conectado por uma rede IP ao Gerenciador de Comunicação Avaya em Londres. As chamadas para usuários finais locais são encaminhadas pela rede do Gerenciador de Comunicação Avaya, que negocia com o servidor de Unificação de Mensagens em Londres o fornecimento de atendimento de chamadas na Unificação de Mensagens.
Neste exemplo, o site de Seattle possui servidores de Caixa de Correio do Exchange e servidores de Unificação de Mensagens no mesmo local físico. Quando houver uma arquitetura unificada, todos os servidores (Caixa de Correio, Unificação de Mensagens, Acesso para Cliente e assim por diante) e o equipamento PBX estarão no mesmo local. As corporações com vários sites adicionam complexidade ao design. Essa complexidade pode parecer impressionante mas, com a compreensão adequada de alguns princípios básicos da Unificação de Mensagens, ela se torna gerenciável.
Como mostrado na Figura 2, se um site contiver um servidor de Caixa de Correio, a recomendação é adicionar um servidor de Unificação de Mensagens ao mesmo local. Seattle, Londres, Nova York e Glasgow se encaixam nesse design. Nem Austin nem Zurique possuem um servidor de Caixa de Correio local, mas os serviços de Unificação de Mensagens ainda podem ser fornecidos para esses locais por meio da rede IP. Austin possui um PBX analógico local. Nesse caso, um gateway SIP deve ser usado para oferecer a conectividade da rede IP com o servidor de Unificação de Mensagens em Seattle. Zurique possui um PBX IP local conectado ao PBX de Londres pela rede. Dessa forma, as chamadas para um usuário em Zurique atravessariam a rede de telefone até o PBX em Londres e até o servidor de Unificação de Mensagens.
Uma vez que as chamadas feitas para os assinantes em Zurique atravessam a rede e são manipuladas por um sistema de Unificação de Mensagens centralizado em Londres, se a rede sofrer uma interrupção, as chamadas feitas para todos os assinantes em Zurique não serão atendidas até a rede voltar a funcionar. Se a sustentabilidade local for necessária no caso de uma interrupção na rede, um servidor de Unificação de Mensagens poderia ser colocado em Zurique. No caso de uma interrupção da rede, o servidor de Unificação de Mensagens continuaria a receber as chamadas e as entregaria após o reparo da rede.
O posicionamento dos servidores é, provavelmente, o fator mais importante a ser considerado no projeto de uma arquitetura que se ajuste ao seu ambiente. O fluxograma da Figura 3 deve ajudá-lo a determinar o posicionamento adequado dos servidores.
Figure 3 Determining server placement
Figure 3 Determining server placement

Estimando as necessidades de servidor
A próxima área a ser considerada é a quantidade de servidores de Unificação de Mensagens que você precisa para oferecer suporte à sua comunidade de usuários. A resposta para isso realmente depende de vários fatores específicos do site.
A escalabilidade da Unificação de Mensagens é determinada pela quantidade de chamadas simultâneas (portas chamadas, no mundo da telefonia) suportada pelo servidor. Cada chamada feita para o sistema exige que o servidor de Unificação de Mensagens dedique recursos de rede, de CPU, de memória e de disco. Se você acrescentar mais desses recursos, o servidor de Unificação de Mensagens poderá oferecer suporte a mais chamadas simultâneas. Uma vez que esses recursos são sempre limitados, o servidor de Unificação de Mensagens só poderá lidar com o número de chamadas simultâneas até a sobrecarga dos recursos.
Você pode determinar quantas portas são necessárias para o suporte do número de assinantes ao usar os cálculos de análise de tráfego Erlang, mas não entrarei em detalhes aqui. Uma forma mais fácil de determinar quantas portas são necessárias é simplesmente perguntar ao administrador de telefonia quantas portas de correio de voz são usadas no sistema de correio de voz existente. Com base na experiência de campo, os requisitos de porta em um sistema de correio de voz tradicional e em um sistema de correio de voz Unificado devem ser bastante similares.
Eu geralmente recomendo a implementação de até 60 portas em um único servidor. Isso não está relacionado a limitações de software ou de hardware. Em vez disso, se baseia no fato de que um único servidor com 60 portas pode oferecer suporte a até 5 mil usuários. Se esse servidor único sofrer uma interrupção, você acabou de causar uma falha de servidor único em toda a sua base de assinantes (que é enorme).
Quando implementar servidores de Unificação de Mensagens, talvez seja melhor considerar o projeto de uma redundância N+1 na arquitetura. A Figura 4 mostra um design totalmente redundante de servidor e gateway SIP. Usando esse design, se o Unified Messaging Server 1 sofrer uma interrupção, as chamadas do SIP Gateway 1 negociarão automaticamente as chamadas com o Unified Messaging Server 2. Você também pode programar o PBX para distribuir a carga de chamadas de maneira uniforme entre os gateways SIP. Por exemplo, a primeira chamada para o sistema poderia ser roteada para o SIP Gateway 1 e a próxima para o SIP Gateway 2. A alternância de chamadas entre os gateways permite a distribuição uniforme de chamadas e o compartilhamento de carga entre os servidores de Unificação de Mensagens.
Figure 4 Distributing calls between servers for redundancy
Figure 4 Distributing calls between servers for redundancy
No momento, existem dois provedores de gateway SIP suportados pelas soluções de Unificação de Mensagens do Exchange Server 2007: AudioCodes e Dialogic. Se os gateways SIP forem necessários em seu design, adquira um que ofereça suporte ao número de sessões (portas) exigidos por ele. Por exemplo, se o seu design exigir 32 portas, será preciso um gateway que ofereça suporte a pelo menos esse número de sessões.
Se você está querendo saber se o seu PBX funcionará com a Unificação de Mensagens ou que gateway deve ser usado, consulte a barra lateral "Recursos da Unificação de Mensagens". Os links listados ali lhe oferecerão orientação específica da Microsoft, assim como um catálogo de especialistas em Unificação de Mensagens que poderão ajudar a avaliar as necessidades específicas da sua organização. Falando por experiência própria, não existem muitos PBXs por aí que não funcionem com os gateways SIP e com a Unificação de Mensagens do Exchange, e alguns PBXs podem se comunicar com o servidor de Unificação de Mensagens de forma nativa usando SIP sobre TCP.
A Unificação de Mensagens do Exchange oferece suporte a três codecs de áudio para o armazenamento de mensagens de correio de voz: G.711 PCM Linear, GSM 06.10 e Windows Media® Audio (WMA). Cara arquivo WAV do PCM Linear ocupa aproximadamente 16 KB para cada segundo de áudio. O WMA é o codec de áudio padrão para a Unificação de Mensagens e compacta o áudio a 1,1 kilobits (kb) para cada segundo de áudio com um cabeçalho de 7 KB. O GSM 06.10 compacta o áudio a 1,6 kb para cada segundo de áudio, mas possui um cabeçalho menor do que a codificação WMA.
As codificações WMA e GSM 06.10 possuem qualidade de voz aceitável para mensagens de voz. Com base na experiência de campo usando os codecs WMA ou GSM, você pode supor um aumento de 10 a 20 por cento no tamanho do armazenamento da caixa de correio dependendo do quanto a sua organização utiliza o correio de voz.
Quando estiver decidindo que codec de áudio usar para o seu ambiente, tenha em mente os dispositivos móveis e outros sistemas operacionais que poderão ser usados por seus usuários finais. A maioria das perguntas sobre este tópico estão relacionadas aos usuários poderem ou não acessar seus correios de voz em seus dispositivos Windows Mobile®. Você também deve se preocupar com outros sistemas operacionais: talvez você tenha uma grande implantação de máquinas Linux que podem não ser capazes de reproduzir arquivos WMA. Seja qual for o caso, perceba que tais fatores também deverão ser considerados durante o treinamento sobre os requisitos de recursos de suporte técnico.

Configuração e testes
Seja a arquitetura de Unificação de Mensagens centralizada ou distribuída, existem muitos requisitos de correio de voz que precisam ser considerados antes da implantação em sua organização. Você encontrará uma lista de tópicos detalhada que terá de ser discutida pela equipe de projeto na barra lateral "Lista de verificação da Unificação de Mensagens". As informações para todos os tópicos deve ser obtida para cada site onde a implementação da Unificação de Mensagens estiver sendo considerada. Lembre-se, tanto a equipe de TI como a de telecomunicações precisam trabalhar juntas nesses tópicos.
Depois que o seu sistema for projetado e a configuração finalizada, um sistema de testes deve ser montado para a validação do design. Em um design de vários sites, recomendo que pelo menos dois sites separados sejam testados para a exibição de uma prova de conceito e para a validação do funcionamento do design.
O plano de testes da funcionalidade deve ser desenvolvido a partir de seus requisitos de configuração e depois concluído. O plano de testes da funcionalidade deve incluir métodos de acesso de assinantes (telefone, Outlook 2007 e Outlook Web Access), métodos de administração e interrupções de hardware e de rede.
Depois que o teste for concluído e todos concordarem que a Unificação de Mensagens duplicará os recursos do antigo sistema de correio de voz ou que uma solução alternativa foi projetada para oferecer suporte a qualquer configuração ou recurso que não pode ser duplicado, um grupo piloto de usuários deve ser selecionado para testar o sistema. A criação de um grupo piloto demonstrará as etapas necessárias em seu ambiente para mover (ou ser desligado, no jargão da telefonia) os assinantes do antigo sistema de correio de voz para a Unificação de Mensagens. Em geral, essas etapas são necessárias para desligar um assinante:
  1. Desabilitar o assinante do sistema de correio de voz existente.
  2. Habilitar o assinante no Active Directory para Unificação de Mensagens por meio do Console de Gerenciamento do Exchange.
  3. Alterar o caminho de cobertura do telefone para um número piloto da Unificação de Mensagens.
É importante desabilitar o assinante do sistema de correio de voz existente para que nenhuma mensagem seja enviada para a antiga caixa de correio.
Durante a fase piloto, você deve registrar todas as dúvidas que os seus assinantes tiverem sobre a funcionalidade do sistema. A documentação desses detalhes permitirá a resolução de problemas comuns durante a fase de treinamento.
O treinamento é fundamental para um desligamento com êxito. Os seus usuários estão acostumados a acessar o correio de voz do telefone com uma interface do usuário específica. Por exemplo, alguns sistemas de correio de voz exigem que os usuários pressionem 5 para ouvir as mensagens. A Unificação de Mensagens do Exchange exige que os usuários pressionem 1 ou digam "correio de voz" (ou usem o Outlook 2007 ou o Outlook Web Access para reproduzirem mensagens de voz). O seu treinamento para assinantes da Unificação de Mensagens deve englobar a navegação pela interface do usuário de telefone, a navegação no Outlook Voice Access e a navegação no Outlook/Outlook Web Access.
Com a Unificação de Mensagens do Exchange 2007, a capacidade de falar comandos é incorporada ao Outlook Voice Access. Alguns usuários tendem a ficar empolgados com os novos recursos do sistema e essa empolgação pode ajudar a facilitar a transição de uma interface do usuário para outra.
A Unificação de Mensagens do Exchange pode enviar um email de texto para os usuários à medida que cada um é habilitado. Essas mensagens personalizadas podem ser usadas para o oferecimento de valiosos links da Web para FAQs (perguntas freqüentes), documentação de assinantes, números de telefone de suporte técnico e assim por diante. Eles também podem conter informações sobre como acessar o sistema de correio de voz e a senha exclusiva do assinante. Esse é um dos recursos mais poderosos cujas vantagens você poderá aproveitar durante a habilitação de seus usuários finais.

Migrando usuários
Lista de verificação da Unificação de Mensagens
As seções a seguir definem alguns dos elementos básicos de um sistema de Unificação de Mensagens e sugere perguntas que precisam ser respondidas em preparação para a implantar e configurar a Unificação de Mensagens do Exchange Server 2007. Use esta lista de verificação para o desenvolvimento de um plano de implantação.
Planos de discagem Um plano de discagem da Unificação de Mensagens corresponde logicamente a um PBX e aos ramais associados. Alguns aspectos do seu plano de discagem a serem considerados com antecedência:
  • Quantos dígitos terão os números dos ramais?
  • Qual é o número piloto do sistema de Unificação de Mensagens?
  • O que os usuários precisam discar para a obtenção de uma linha externa?
  • Que codec de áudio você usará para as mensagens?
  • Qual é o número do ramal da operadora?
Grupos de busca e números piloto Um grupo de busca é um conjunto de ramais de telefone configurados para receber chamadas em uma determinada ordem. O número piloto é o ramal principal que é chamado para o acesso ao grupo de busca. O número de ramais de membros do grupo de busca deve ser igual ao número de portas de correio de voz em seu design.
Diretivas de caixa de correio As diretivas de caixa de correio de voz não são muito diferentes das diretivas de caixa de correio do Exchange. Estas são algumas das diretivas que talvez você queira discutir:
  • Quantos dias as mensagens de correio de voz serão mantidas antes de serem excluídas?
  • Qual é a freqüência de redefinições de senha de correio de voz necessária?
  • Qual é a diretiva de backup do correio de voz?
  • Qual é o comprimento mínimo da senha aceitável?
  • Qual o máximo de tentativas de logon antes do bloqueio da caixa de correio?
Atendedor automático (AA) Os atendedores automáticos respondem a chamadas não destinadas a um assinante específico. Eles podem fornecer informações e direcionar os chamadores para locais de sua organização. A Unificação de Mensagens do Exchange oferece recursos de DTMF e de fala para a navegação nos AA. Os fatores a serem considerados incluem:
  • Existem saudações de AA diferentes para o horário diurno, para o noturno e para os feriados? (As saudações precisam ser documentadas e gravadas).
  • Que números podem ser discados a partir do menu do AA?
  • A navegação por fala pode ser utilizada quando se usa o AA?
  • São necessários vários idiomas para a utilização do AA?
Caixa de correio geral ou noturna Algumas organizações possuem uma caixa de correio de voz geral ou noturna que permite aos chamadores deixarem mensagens de entrega gerais. Se a sua empresa tiver uma, crie e habilite uma caixa de correio do Exchange para a Unificação de Mensagens.
Indicação de mensagem em espera (MWI) A indicação de mensagem em espera se refere à luz do seu telefone que alerta para mensagens de voz não lidas em sua caixa de correio. A indicação de mensagens em espera em aparelhos de telefone é um requisito para a implantação?
Suporte a vários ramais Muitas organizações contam com funcionários que possuem vários telefones. Quando habilitar esses assinantes para a Unificação de Mensagens, você terá de associá-los a todos os seus números de ramal. Antes de começar, crie uma lista de funcionários com vários ramais.
Suporte a atendimento interativo de voz (IVR) Alguns sistemas de correio de voz tradicionais oferecem suporte a aplicativos IVR que a Unificação de Mensagens não será capaz de duplicar. Determine se o sistema que está sendo substituído possui algum aplicativo desse tipo associado a ele. Esses aplicativos podem permanecer no sistema existente ou ser substituídos por aplicativos IVR alternativos.
Rede de correio de voz A rede de correio de voz oferece uma forma de enviar uma mensagem de um sistema para outro totalmente distinto. Por exemplo, em grandes empresas, talvez o CEO queira enviar uma mensagem de voz para toda a organização ou talvez haja anúncios gerais, como exercícios de simulação de incêndio. Com uma rede de correio de voz, o CEO poderia gravar uma mensagem de voz e enviá-la para todos os funcionários da empresa, não importando o sistema de correio de voz em que eles estivessem. No momento, a Unificação de Mensagens do Exchange não é capaz de se conectar em rede a outros sistemas de correio de voz tradicionais.
Suporte a fax Algumas plataformas de correio de voz tradicionais oferecem suporte ao recebimento de faxes, permitindo que você utilize o seu número de telefone para voz e fax. A Unificação de Mensagens do Exchange Server 2007 oferece suporte ao recebimento de faxes e pode ser usado na substituição desse recurso. É um recurso unidirecional; o sistema não oferece suporte ao envio de faxes. Se isso for uma exigência, você terá de procurar por um produto de terceiros.

Existem diversos pontos de vista diferentes sobre como migrar totalmente o sistema para produção. As duas metodologias principais são uma migração gradual e um desligamento rápido. Não importa a metodologia escolhida, treine a sua equipe de suporte técnico nas perguntas comuns registradas no grupo piloto. Além disso, não se esqueça de mostrar a eles como habilitar um usuário, como validar a habilitação do usuário e como alterar uma senha.
A migração de usuários do antigo sistema de correio de voz para a Unificação de Mensagens é fácil, mas existe um grande problema de que você deve ter consciência: a rede de correio de voz. Assim como um sistema de email permite que você envie, encaminhe e responda a outros usuários e sistemas de email, o sistema de correio de voz também permite o envio, o encaminhamento e a resposta a outros usuários e sistemas de correio de voz.
Considere um cenário em que Alice e Brian estão no sistema de correio de voz antigo. Brian é migrado para a Unificação de Mensagens e deseja enviar uma mensagem para Alice no sistema de correio de voz antigo. Já que os dois usuários estão em sistemas separados, não podem mais enviar, encaminhar ou responder mensagens de correio de voz um do outro; infelizmente, foi criada uma ilha de correio de voz.
A forma como esse problema é resolvido em sistemas tradicionais de correio de voz é usar algum tipo de conversor de protocolo de rede que permite a conexão de sistemas distintos em rede. Atualmente, no entanto, não há um conversor de protocolo de rede que permita que sistemas distintos sejam conectados em rede à Unificação de Mensagens do Exchange Server 2007. Embora isso possa não ser importante para a sua organização, é algo que você deve saber quando optar por migrar usuários em pequenos grupos.
Eu prefiro executar um desligamento rápido de todos os usuários de um site. Um desligamento rápido é uma mudança limpa de um sistema para o outro. Quase sempre ele ocorre em um final de semana; os usuários vão para casa na sexta e voltam a trabalhar na segunda com um novo sistema de correio de voz. Alguns administradores dizem que um desligamento rápido deve ser usado somente para clientes de pequenas empresas ou para sites remotos. Eu não concordo. Já participei de desligamentos rápidos de cerca de 7 mil usuários em um único local onde menos de 1% dos funcionários precisou ligar para o suporte técnico. Se todas as outras fases do seu projeto tiverem sido bem planejadas e bem executadas, a mudança para um sistema totalmente em produção deve ser suave.
Quando vários sites forem movidos para produção, no entanto, considere transferir os sites remotos menores um por vez antes de transferir o site maior. Revise as lições aprendidas com os sites menores e implemente as alterações necessárias em seu plano de projeto.
Normalmente, todos os treinamentos de usuários devem ser concluídos e todos os usuários devem ser habilitados para a Unificação de Mensagens antes que o sistema entrar em produção. A seguir, uma metodologia passo a passo a ser usada na preparação de um desligamento rápido de um sistema de correio de voz.
A primeira coisa a ser feita é validar se o sistema de Unificação de Mensagens está totalmente instalado, configurado e testado.
Execute o treinamento em pequenos grupos. Explique aos usuários que estiverem no curso que suas caixas de correio serão habilitadas antes que o sistema entre em produção e que eles devem fazer login nelas e as inicializar, alterando as senhas e gravando as saudações. Após a conclusão do treinamento, habilite imediatamente esses usuários para que eles inicializem suas caixas de correio antes do desligamento.
Por fim, quando o treinamento estiver concluído, escolha um final de semana para desabilitar todos os usuários do antigo sistema de correio de voz e encaminhe seus telefones para a Unificação de Mensagens do Exchange. Na manhã de segunda, o seu sistema estará no ar para todos os usuários da sua organização.

Fazendo o desligamento
As informações deste artigo lhe serão úteis a despeito de você oferecer suporte a um único local ou a uma grande organização com vários locais. As organizações com vários sites podem adicionar complexidades ao design, mas os requisitos básicos são os mesmos, tenha você 50 ou 5 mil usuários.
Não me canso de afirmar que as equipes de TI e de telecomunicações devem trabalhar juntas na implantação de uma solução de Unificação de Mensagens. Em minha experiência, entre os muitos aspectos que podem prejudicar um projeto de Unificação de Mensagens, o conflito entre TI e telecomunicações e a falta de acordo sobre a solução podem ser um prenúncio de falha. A convergência de tecnologias não é tão difícil, mas requer que alguém de fora da sua organização e que entenda de TI e de telecomunicações ajude a juntar as equipes ou planeje a implantação de um projeto de sucesso.

Jeff Goodwin é tecnólogo sênior do The Via Group, especializado em projetos e implantação de Exchange e de Unificação de Mensagens. Você pode contatá-lo pelo email jgoodwin@theviagroup.com.


 Seguran&#231;a: Um guia para a computa&#231;&#227;o forense b&#225;sica
Segurança Tom Cloward and Frank Simorjay

Um guia para a computação forense básica
Visão geral:
  • Guia básico de investigação computacional para Windows
  • O Malware Removal Starter Kit
  • Criando um kit de investigação com o Windows PE
  • Preservando informações para análise forense

As pessoas maliciosas podem usar um computador de inúmeras formas para executar atividades ilegais — invadir sistemas, vazar segredos comerciais, liberar novos vírus, usar mensagens de phishing para furtar informações pessoais e assim por diante. E constantemente ouvimos falar de novas explorações e
técnicas. O que você não ouve com freqüência são informações sobre todas as formas como os computadores podem ser usados na investigação dessas atividades.
Enquanto algumas investigações exigem profissionais altamente treinados com ferramentas caras e técnicas complexas, existem métodos mais fáceis e baratos que podem ser usados na investigação e na análise básicas. Neste artigo, nos concentraremos em técnicas de computação forense que você pode acessar prontamente como administrador.
A nossa discussão se baseia em dois aceleradores de soluções que podem ser baixados gratuitamente: "Guia básico de investigação computacional para Windows" (go.microsoft.com/fwlink/?LinkId=80344) e O Malware Removal Starter Kit (go.microsoft.com/fwlink/?LinkId=93103). Neste artigo, mostraremos como é possível combinar essas duas soluções para criar um ambiente inicializável do Windows® PE que permitirá a você conduzir uma investigação efetiva e preservar as suas descobertas para análise e criação de relatórios. Observe que você não poderá usar o método discutido aqui para investigar um disco rígido criptografado ou que faça parte de um volume RAID. E se o disco rígido estiver danificado, você precisará executar etapas adicionais além do tempo de restauração do seu estado.
Embora a nossa solução detalhe uma maneira fácil de coletar provas de um computador baseado em Windows, ela não deixa de ser uma abordagem básica e ad hoc. Existem diversas soluções mais sofisticadas disponíveis comercialmente que podem executar o trabalho descrito aqui de uma forma muito mais eficiente.
Tenha em mente também que a técnica discutida aqui não é uma solução prescritiva garantida nem certificada pela The International Society of Forensic Computer Examiners. Antes de começar uma investigação, você deve considerar se a prova contida no disco rígido potencialmente pode se tornar parte de um procedimento legal. Se houver essa possibilidade, um examinador de computadores certificado profissionalmente deverá ser encarregado de conduzir a investigação. Dependendo da natureza de qualquer potencial procedimento legal, você também deve considerar o fato de transferir a investigação diretamente para as autoridades competentes. Há mais informações sobre este tópico no "Guia básico de investigação computacional para Windows".

Sobre os Solution Accelerators
O "Guia básico de investigação computacional para Windows" discute processos e ferramentas que você pode usar em uma investigação computacional interna. Ele descreve as quatro fases do modelo de investigação computacional: avaliar, obter, analisar e relatar. Esse modelo é conveniente para ajudar profissionais de TI a conduzir investigações de uma forma que preserve as descobertas importantes.
Esse guia também aborda o momento em que é necessário envolver as autoridades competentes — será preciso pedir a opinião de seus consultores jurídicos nessa tomada de decisão. Você encontrará informações sobre o gerenciamento de crimes relacionados a computadores, como entrar em contato com as autoridades competentes apropriadas e sobre as ferramentas Windows Sysinternals e outras ferramentas do Windows úteis na condução de investigações.
O outro solution accelerator indicado neste artigo, o Malware Removal Starter Kit, oferece orientação sobre como criar e usar um CD-ROM inicializável do Windows PE para remover malware de um computador. Esse guia inclui uma lista de ameaças e algumas das soluções que podem ajudar a reduzir seu potencial impacto em uma organização. Também salienta a importância do desenvolvimento de um plano de resposta a incidentes que possa ser seguido em caso de suspeita de ataque de malware. O Malware Removal Starter Kit também inclui uma abordagem de 4 estágios para ajudar um profissional de TI a determinar a natureza do malware envolvido, limitar sua disseminação, removê-lo, se possível, verificar a sua remoção e prosseguir com outras etapas que venham a ser necessárias.

O CD-ROM do Windows PE
Existem dois pré-requisitos para a execução de uma investigação desse tipo: um CD-ROM do Windows PE e um dispositivo de armazenamento externo, como uma unidade flash USB.
Provavelmente você já viu televisão suficiente para saber que os policiais devem manter a cena do crime inalterada. Bem, por algum motivo, você deseja preservar os dados no disco rígido que está sendo investigado. Ao contrário do disco do Malware Removal Starter Kit, o disco inicializável do Windows PE que estamos criando só executará ferramentas de forma que os dados do disco rígido não sejam alterados de forma alguma.
O disco do Windows PE inicializará o sistema em um ambiente limitado do Windows. Ao criar esse CD inicializável, você poderá incluir ferramentas (como no Malware Removal Starter Kit) configuradas com antecedência para uma finalidade especial. Observe que o computador deve ter pelo menos 512 MB de RAM — essa é uma exigência do Windows PE.
O processo de criação do CD-ROM do Windows PE, detalhado em O Malware Removal Starter Kit, é bastante simples. Antes de criar esse disco reinicializável, você precisará instalar o AIK (Kit de Instalação Automatizada do Windows), o Sysinternals Suite (disponível em microsoft.com/technet/sysinternals/utilities/sysinternalssuite.mspx), colocar as ferramentas Sysinternals em sua lista de ferramentas como descrito na Tarefa 2 do Malware Removal Starter Kit e instalar qualquer outra ferramenta e utilitário de exame de malware. Para obter instruções detalhadas sobre a criação do disco, utilize as etapas descritas no documento O Malware Removal Starter Kit.

A unidade externa USB
Uma vez que esse processo não altera a unidade sob investigação, você precisará também de um pen drive USB ou algum outro tipo de disco rígido externo para poder armazenar os arquivos de saída que serão gerados (o pen drive USB é a mídia recomendada, já que o Windows PE consegue montar dispositivos USB automaticamente). Talvez você também queira usar um disco rígido externo para armazenar uma imagem do disco rígido original. Com todos esses requisitos e opções, é importante que você planeje com antecedência para levar em consideração o espaço em disco total que a investigação exigirá.
Como você deseja garantir que o kit esteja limpo no início de uma investigação, todos os dados anteriores precisam ser completamente removidos do disco rígido externo que será usado para salvar os arquivos da investigação. Isso pode ser feito com facilidade com um utilitário de limpeza de disco que substitua toda a superfície da unidade gravável. O disco externo poderá então ser formatado e rotulado como necessário para ser usado na investigação. Essa precaução garante que o dispositivo não contenha arquivos que possivelmente possam contaminar as provas obtidas durante a investigação.
Você também deve incluir um formulário de cadeia de custódia que será a documentação oficial quanto a quem manipulou o computador em toda a investigação. O "Guia básico de investigação computacional para Windows" oferece um exemplo de formulário de cadeia de custódia. Depois de concluir o empacotamento do kit (com o disco inicializável do Windows PE necessário, o dispositivo de armazenamento externo e um formulário de cadeia de custódia), você estará pronto para prosseguir.

Executando uma investigação
Agora você está pronto para executar uma investigação. Primeiro, inicialize o sistema suspeito usando o disco do Windows PE, verificando se a ordem de inicialização do computador identifica a unidade de CD-ROM como o principal dispositivo de inicialização. Quando solicitado, pressione qualquer tecla para concluir a inicialização a partir do CD-ROM. Isso oferecerá o acesso às ferramentas instaladas no disco.
Nós usaremos o nosso kit em uma máquina de exemplo para demonstrarmos como você pode coletar informações a partir de um computador (que chamaremos de Testbox1). A atribuição da unidade de CD em Testbox1 é X:\ e o local padrão fornecido para as ferramentas do Malware Removal Starter Kit é X:\tools. Para acessar as ferramentas do kit, devemos simplesmente digitar: cd \tools.
Existem diversas ferramentas que podem identificar as unidades de destino montadas em um computador. Bginfo.exe, localizado no diretório de ferramentas Sysinternals, pode oferecer essas informações e colocá-las em uma janela de plano de fundo na área de trabalho para referência fácil. O Drive Manager também pode identificar todas as unidades do computador, incluindo as unidades de disco rígido de destino e o dispositivo USB externo. A Figura 1 mostra as informações do disco de Testbox1. A unidade de inicialização é a X:\, o disco rígido de destino é o C:\ e a nossa unidade externa USB é a F:\.
Figure 1 Viewing disk information with Drive Manager
Figure 1 Viewing disk information with Drive Manager

Verificando a existência de malware
É importante executar ferramentas anti-malware antes de iniciar uma investigação para garantir que a investigação não será comprometida por um vírus ou por outro código malicioso. O relatório gerado pela ferramenta anti-malware pode ser usado como prova, se necessário. Mas a falta de verificação da existência de malware em um computador pode prejudicar a investigação, assim como a credibilidade do examinador em relação à sua eficácia e precisão. Recomendamos que você execute as ferramentas anti-malware fornecidas em um modo somente leitura ou de relatório.
O Malware Removal Starter Kit discute algumas das ferramentas recomendadas, incluindo a Ferramenta de Remoção de Software Mal-Intencionado e o McAfee AVERT Stinger. Quando a Ferramenta de Remoção de Software Mal-Intencionado for executada, não se esqueça de incluir a opção de linha de comando /N para instruí-la a somente informar o malware, sem tentar removê-lo:
x:\tools\windows-KB890830-v1.29.exe /N
O arquivo de relatório resultante será gerado em %windir%\debug\mrt.log.
Da mesma forma, quando executar o McAfee AVERT Stinger, altere a preferência para Report only (Somente informar), como mostrado na Figura 2, para que ele verifique o computador mas não faça alterações no disco rígido. E não se esqueça de salvar um relatório da ferramenta após a conclusão da verificação.
Figure 2 Use Report only mode in McAfee AVERT Stinger
Figure 2 Use Report only mode in McAfee AVERT Stinger

Salvando arquivos fundamentais
Se não houve um backup completo de todo o disco antes do início da investigação, pelo menos faça backup dos principais arquivos de usuário. As informações de configuração podem ser usadas em uma futura revisão, se necessário. Comece pela coleta dos arquivos e das configurações do registro, pois eles contêm todas as informações relevantes sobre como o computador foi usado e que programas estão instalados no sistema.
Para salvar o hive do registro de Textbox1, primeiro criamos uma pasta na unidade F:\ removível e registramos a data e a hora de início da investigação usando os seguintes comandos:
f: Mkdir f:\evidence_files Date /t >> f:\evidence_files\Evidence_start.txt Time /t >> f:\evidence_files\Evidence_start.txt
Agora salvamos o hive do registro usando o comando xcopy para copiar todo o diretório de configuração e seu conteúdo. Os arquivos do registro que interessam a você estão localizados em %windows%\system32\config. Em nosso caso, executamos o seguinte:
xcopy c:\windows\system32\config\*.* f:\registrybkup /s /e /k /v
Esse comando copia todas as informações de configuração localizadas na pasta config. Textbox1 contém aproximadamente 95 MB de informações na pasta config.
Em seguida, concentre-se nos dados do usuário, que podem estar em qualquer lugar do disco rígido. Em nosso exemplo, copiaremos somente os dados de um diretório chamado c:\HR. Para garantir que todos os dados sejam coletados, copiados todos os dados do diretório e de seus subdiretórios usando o seguinte comando xcopy:
Mkdir f:\evidence_files\HR_Evidence Mkdir f:\evidence_files\documents_and_settings Mkdir f:\evidence_files\users xcopy c:\HR\*.* f:\evidence_files\HR_Evidence /s /e /k /v
Agora você pode se concentrar nas informações das pastas pessoais. Novamente, queremos copiar todos os dados desses diretórios e de seus subdiretórios. Para isso, usamos os seguintes comandos:
Xcopy c:\documents and settings\*.* f:\evidence_files\documents_and_settings /s /e /k /v

Xcopy c:\users\*.* f:\evidence_files\users /s /e /k /v
Esse exemplo coletou cerca de 500 MB de dados, que agora podemos analisar, se necessário. Como você pode ver, a quantidade de dados coletados pode ser imensa — especialmente se você encontrar arquivos de áudio, vídeos e fotos. Ainda assim, é importante preservar o máximo possível dos dados originais porque uma investigação pode exigir não só as provas coletadas fisicamente como também a garantia de que essas informações não foram alteradas durante o processo de coleta. O ideal é que você faça uma imagem completa do disco para a sua investigação, mas isso pode ser difícil devido a restrições de tamanho. Não é preciso dizer que você pode ver porque é importante saber com antecedência quanto espaço de armazenamento é provável que a sua investigação exija.

Coletando informações adicionais
Os arquivos do sistema também podem ser um bem útil na coleta de provas, mas a obtenção desses dados pode exigir alguma exploração do computador de destino, uma vez que esses arquivos nem sempre estão no mesmo local. Ainda assim, vale a pena procurar por certos tipos de arquivos porque eles oferecem informações úteis. Os arquivos de swap, por exemplo, contêm informações sobre arquivos que foram acessados pela memória. Além disso, os arquivos de swap podem até oferecer informações detalhadas sobre a atividade de uso. De forma similar, os dados e os cookies de um navegador da Web oferecem informações sobre comportamento e padrões de navegação.
A localização desses dados pode exigir algum trabalho de detetive, especialmente se um usuário tiver alterado sua configuração para armazenar dados em algum lugar diferente dos locais padrão. Existem diversas ferramentas Sysinternals que podem ajudá-lo a encontrar arquivos fundamentais. A Figura 3 lista cinco aplicativos úteis e descreve como eles poderão ajudá-lo em sua investigação.
Figure 3 Tools to locate files and data of interest (Close Figure 3)

Aplicativo | Descrição
AccessChk | Exibe o acesso a arquivos, chaves do registro e serviços do Windows feitos pelo usuário ou pelo grupo especificado.
AccessEnum | Exibe quem tem acesso a quais diretórios, arquivos e chaves do registro em um computador. Use-o para encontrar locais onde as permissões não foram aplicadas corretamente.
Du | Exibe o uso do disco pelo diretório.
PsInfo | Exibe informações sobre um computador.
Strings | Procura por cadeias de caracteres ANSI e UNICODE em imagens binárias.

Tom Cloward, CCE, CISSP, gerente de programa da Microsoft, dedicado a oferecer solution accelerators de segurança e de conformidade para profissionais de TI. Trabalhou nos setores de software e de TI por mais de 15 anos e é apaixonado por segurança de TI, computação forense e conformidade.
Frank SimorjayCISSP, CET, é gerente de programa técnico e especialista no assunto segurança do grupo de segurança e conformidade do Solution Accelerator da Microsoft. Ele projeta soluções de segurança para clientes da Microsoft. Seu trabalho mais recente é o Malware Removal Starter Kit, disponível no Microsoft TechNet.


 Sistemas de rede: O Relat&#243;rio de Intelig&#234;ncia de Seguran&#231;a da Microsoft
Sistemas de rede Tim Rains

O Relatório de Inteligência de Segurança da Microsoft
Visão geral:
  • Tendências nas divulgações de vulnerabilidades de software, explorações e malwares
  • Impacto de ameaças em diferentes versões do Windows
  • Áreas mais e menos infectadas no mundo

Dados de centenas de milhões de sistemas conectados à Internet e alguns dos mais ocupados serviços online do mundo proporcionam à Microsoft uma visão singular das ameaças de segurança enfrentadas pelos usuários da Internet atualmente.
A Microsoft compartilha esses dados duas vezes ao ano em seu SIR (Relatório de Inteligência de Segurança da Microsoft). Os colaboradores do relatório incluem o MMPC (Microsoft® Malware Protection Center), o MSRC (Microsoft Security Response Center), o grupo TwC (Trustworthy Computing), bem como vários outros grupos de produtos. O SIR possibilita uma visualização profunda das recentes tendências em divulgações de vulnerabilidades de softwares mal-intencionados e potencialmente indesejados como, por exemplo, spywares e adwares. O relatório também inclui detalhes sobre o desempenho de várias versões do sistema operacional Windows em relação às ameaças e quais são as regiões do mundo mais afetadas por malwares e outros softwares intrusivos. A versão mais recente do relatório, que se concentra nas tendências observadas no primeiro semestre de 2007, inclui uma nova seção sobre explorações de vulnerabilidades de softwares. Se a segurança do computador for responsabilidade sua ou de seu interesse, a leitura do SIR será útil, uma vez que ele foi projetado para ajudar você a se manter informado a respeito das ameaças relacionadas à Internet.
O SIR mais recente revela que os pesquisadores de segurança estão encontrando mais vulnerabilidades em softwares de todos os fornecedores. Na verdade, mais de 3.400 novas vulnerabilidades de softwares foram descobertas apenas no primeiro semestre de 2007! Ainda assim, apesar desse número significativo, a porcentagem geral de vulnerabilidades de sistema operacional divulgada está diminuindo.
O que isso significa? Uma possibilidade é de que os pesquisadores de segurança estão se concentrando mais em aplicativos porque a segurança do sistema operacional tem melhorado continuamente. Além disso, como o número de novos aplicativos está ultrapassando o número de novos sistemas operacionais, a proliferação de aplicativos deve estar por trás dessas recentes tendências de divulgação de vulnerabilidades.
Durante 2006, 29,3% das vulnerabilidades em produtos Microsoft apresentavam código de exploração conhecido publicamente, ao passo que, a partir de 1º de agosto de 2007, apenas 20,9% das vulnerabilidades conhecidas apresentavam esse código. Embora o número de vulnerabilidades continue crescendo, a proporção de códigos de exploração permanece estável e chegou até mesmo a mostrar um ligeiro declínio. Códigos de exploração em produtos mais novos são difíceis de encontrar. Realizamos uma comparação produto a produto que sugere que as versões mais recentes dos produtos correm menos riscos do que aquelas que já estão no mercado há mais tempo. Na média, a possibilidade de exploração reduz os tempos de vida dos produtos, o que significa que, para a maioria dos produtos, as versões posteriores estão menos sujeitas à exploração. Isso fica mais claro com os produtos Windows e do Microsoft Office System. As versões posteriores de ambos (Windows Server® 2003, Windows Vista®, Office 2003 e 2007 Office system) mostraram uma redução significativa no número de vulnerabilidades em todo o tempo de vida do produto.
O SIR oferece informações importantes sobre as tendências em softwares mal-intencionados (conhecidos como malwares). Essas tendências são uma indicação das táticas usadas atualmente em ataques aos usuários. Observar os dados de algumas das origens principais mais importantes, inclusive o EHS (Microsoft Exchange Hosted Services), o Windows Live® OneCare e o verificador de segurança Windows Live OneCare, além da MSRT ( Ferramenta de Remoção de Software Mal-Intencionado do Microsoft Windows) e o Windows Defender, nos dá uma visão do panorama de ameaças em relação a alguns pontos vantajosos diferentes.
A engenharia social desempenha um papel cada vez mais importante na distribuição de malwares. Esses ataques costumam conseguir enganar os usuários de forma que eles tomem alguma ação que possa reduzir a eficiência dos mecanismos de segurança. Os dados do EHS indicam que, durante o primeiro semestre de 2006, os worms clássicos por email foram responsáveis pela maior ameaça única por email, representando 95% dos malwares detectados. Observando seu início no segundo semestre de 2006, esse número caiu para 49% e permaneceu estável durante todo o primeiro semestre de 2007 (consulte a Figura 1). Tentativas de phishing e emails contendo ataques IFrame mal-intencionados foram responsáveis por 27% das detecções de malware em emails no segundo semestre de 2006 e chegaram a 37% no primeiro semestre de 2007. Trojans Downloader transmitidos por email atingiram o pico de 20% no segundo semestre de 2006, caindo para 7% no primeiro semestre de 2007.
Figure 1 Composition of infected e-mail in the first half of 2007
Figure 1 Composition of infected e-mail in the first half of 2007
Os dados de telemetria obtidos do Windows Live OneCare e do verificador de segurança Windows Live OneCare (safety.live.com) indicam que as proporções de infecção por vírus, backdoors, password stealers e Trojans ladrões de dados cresceram no primeiro semestre de 2007.
A MSRT foi projetada para ajudar na identificação e na remoção de malwares permanentes dos computadores dos clientes. Ela é basicamente lançada como uma atualização crítica por meio do WU (Windows Update), do MU (Microsoft Update) e das AU (Atualizações Automáticas). Nos últimos dois anos, a MSRT já removeu 50,3 milhões de infecções de 20,5 milhões de computadores em todo o mundo. Até hoje, o número total de execuções da MSRT ultrapassa os 7,4 bilhões; isso inclui 1,9 bilhões de execuções no primeiro semestre de 2007.
A MSRT é uma grande origem de dados para a Microsoft e seus clientes. As proporções de infecção observadas pela MSRT são significativamente menores entre os sistemas Windows Vista e Windows XP SP2 do que entre os sistemas operacionais Windows anteriores, como mostra a Figura 2. A MSRT removeu malwares de 60% menos computadores que executavam o Windows Vista do que os que executavam o Windows XP SP2, e 91,5% menos malwares dos computadores que executavam o Windows XP sem nenhum tipo de service pack instalado. Curiosamente, o número de desinfecções por computador permaneceu estável com o passar do tempo, com uma média de 2,2 desinfecções por computador infectado.
Figure 2 OS versions cleaned by the MSRT in the first half of 2007
Figure 2 OS versions cleaned by the MSRT in the first half of 2007
Como regra geral, mais malwares são encontrados, proporcionalmente, pela MSRT em países em desenvolvimento do que em países já desenvolvidos. Por exemplo, os países mais infectados na Europa são a Albânia e a Turquia, enquanto os menos infectados são a Itália e a Finlândia. Na região da Ásia/Pacífico, os mais infectados são a Mongólia e a Tailândia, e os menos são a Nova Zelândia e o Japão. Proporcionalmente, os Estados Unidos são menos infectados do que a maioria dos países e regiões das Américas, e seu índice de infecção basicamente acompanha a média mundial. Em média, a MSRT limpou 1 a cada 216 computadores durante o primeiro semestre de 2007.
O Windows Defender é executado no Windows Vista, no Windows XP e no Windows Server 2003. Em geral, 50,7 milhões de softwares potencialmente indesejados foram detectados durante o primeiro semestre de 2007, com 2,8 vezes menos peças sendo detectadas em computadores que executavam o Windows Vista do que naqueles que executavam o Windows XP SP2. Da mesma forma, o número de detecções de softwares potencialmente indesejados em computadores que executavam o Windows Vista foi metade das feitas em computadores que executavam o Windows Server 2003.
Agora você deve estar se perguntando, por mais interessantes que todas essas estatísticas possam ser, como elas podem proteger você e o seu ambiente? No SIR mais recente, todas as seções principais vêm acompanhadas de um resumo dos pontos mais importantes de cada seção e de um conjunto de "Estratégias, reduções e medidas defensivas". É possível usar essas listas para saber rapidamente quais são as principais descobertas em cada uma das seções do relatório.
Além disso, é possível usar os dados, as informações e as orientações oferecidas no SIR para avaliar e melhorar a sua postura atual em relação à segurança, dado o panorama de ameaças em constante alteração. O relatório completo, que oferece estratégias, reduções e medidas preventivas com base nas principais descobertas, pode ser baixado em microsoft.com/sir.

Tim Rains é gerente de produtos do MMPC (Microsoft Malware Protection Center). Ele gerencia a produção do SIR (Relatório de Inteligência de Segurança da Microsoft). Os autores do SIR são Jeff Jones (diretor do Microsoft Trustworthy Computing Group), Jeff Williams (diretor do MMPC), Mike Reavey (gerente de grupos do Microsoft Security Response Center) e Ziv Mador (gerente de programas sênior e coordenador de respostas do MMPC).


 Rede: Rastrear problemas de rede enganosos
Rede Christopher Stoneff

Rastrear problemas de rede enganosos
Visão geral:
  • As causas habituais dos problemas de rede
  • Indo além do óbvio
  • Quando as ferramentas para solução de problemas não ajudarem
  • Por que você precisa configurar limites de conexão

É provável que já tenho visto isso muitas vezes – a máquina não consegue se comunicar com as demais e você não sabe o porquê. O sistema de gerenciamento fica em um segmento de uma rede roteada conectada a outros segmentos de rede por meio de um roteador como, por exemplo, o Microsoft Internet
Security and Acceleration (ISA) Server ou outro dispositivo de hardware. Ao tentar gerenciar 10, 20 ou até mesmo 100 sistemas, você não enfrenta nenhum problema. Mas quando você tenta gerenciar 500, o computador não consegue se comunicar na rede, exceto com as máquinas com as quais ele já mantém conexões abertas. Não é possível se comunicar com qualquer outro sistema, acessar a Internet, ainda que mais ninguém na rede, inclusive o seu segmento, esteja diante desse fenômeno. Onde você começaria a olhar?

Diagnosticando o problema
A pressuposição mais comum nessa situação é a de que o software de gerenciamento apresenta defeito. Muitas ferramentas de gerenciamento proativas se conectam aos sistemas e os gerenciam, mas elas próprias podem, às vezes, causar o problema que você está tentando rastrear. Isso porque uma ferramenta de gerenciamento proativa pode gerar milhares de conexões para os dispositivos em nome de um melhor gerenciamento. O Windows® manterá essas conexões abertas durante dois minutos por padrão, mesmo quando elas estiverem ociosas, a menos que a ferramenta, o aplicativo ou o serviço as mantenham ativas por mais tempo. Isso significa que, mesmo que o sistema de gerenciamento não tenha falado com nenhuma máquina em dois minutos, talvez você ainda tenha mais de mil conexões abertas. (É possível exibir as conexões abertas executando NETSTAT em um prompt de comando. O comando NETSTAT mostrará a você todas as conexões abertas, pendentes e de fechamento para e do sistema, além de lhe dar seu status. As descrições das mensagens de status podem ser encontradas no RFC 793 em tools.ietf.org/html/rfc793.)
Para descartar o software de gerenciamento que não está funcionando corretamente, é possível criar um arquivo em lotes que estabelece conexões com sistemas remotos. Se o mesmo problema ocorrer durante a execução do arquivo em lotes, você conhecerá o software de gerenciamento e seus threads não deviam ser responsabilizados. Este é um exemplo do conteúdo do arquivo em lotes necessário:
Net use \\system01\ipc$ Net use \\system02\ipc$ Net use ...
Caso o programa de gerenciamento em questão implemente sua própria pilha de rede e de autenticação, talvez ele seja o culpado, mas em soluções sem agentes como a maioria desses pacotes de gerenciamento, a ferramenta usa as pilhas de rede e de autenticação do sistema operacional para realizar operações de rede. O uso de um arquivo em lotes que inicia qualquer número de conexões de rede sem causar a falha mostra que o problema não é resultado do uso do programa das pilhas de rede e de autenticação do sistema operacional, uma vez que o arquivo em lotes também as usa.

Logs e mensagens de erro que não ajudam
Você deve ter notado que, assim que as conexões começaram a falhar, você recebeu informações sobre falhas equivocadas: erro 53 – caminho de rede não encontrado, erro 64 – o nome da rede foi excluído e erro 1203 – nenhum provedor de rede aceitou o caminho de rede fornecido. Tudo isso pode normalmente indicar problemas de resolução de nomes, exceto por todas as demais máquinas que não estejam enfrentando problemas ao resolver nomes e se conectar aos mesmos sistemas. Para verificar se as configurações da máquina não apresentam alguma falha, basta executar ipconfig para confirmar se elas estão corretas.
Em seguida, como o fenômeno parece estar localizado no sistema de gerenciamento, você deve observar os logs de eventos. Uma pesquisa nos logs do aplicativo não traz muitos frutos, mas no log do sistema você encontra um evento de aviso 4226 do TCP/IP de origem do evento informando que o número máximo de conexões foi atingido (consulte a Figura 1).
Figure 1 TCP connection limit has been reached
Figure 1 TCP connection limit has been reached
Realizar uma pesquisa completa na Base de Dados de Conhecimento Microsoft® em busca dos limites de conexão revelará o fato de que há limitações de conexão impostas para conexões incompletas, embora não haja nenhum limite para conexões completas. Você tem a possibilidade de ajustar as seguintes entradas do Registro em HKLM\System\CurrentControlSet\Services\TCPIP para controlar os fatores já mencionados: TcpNumConnections é usado para definir o número máximo de conexões que o protocolo TCP é capaz de manter abertas simultaneamente (o padrão é 10). TCPTimedWaitDelay define o tempo durante o qual uma conexão permanece no estado TIME_WAIT quando está sendo fechada. O tempo médio padrão é de 120 segundos, o que significa que uma conexão está basicamente em uso durante 4 minutos. Por fim, MaxFreeTcbs também tem sua função no número máximo de conexões. Caso todos os blocos de controle TCP estejam sendo usados, o protocolo TCP deve liberar as conexões listadas com um estado TIME_WAIT para criar mais conexões, mesmo que TCPTimedWaitDelay ainda não tenha expirado. TCPTimedWaitDelay tem um intervalo de valores entre 30 e 300 segundos (0x1E a 0x12C).
Dependendo do cenário, você pode notar uma pequena melhora no desempenho geral com essas alterações feitas no Registro. Outra etapa que você pode tentar executar é corrigir o arquivo TCPIP.sys para remover esses limites, embora isso só apresente aperfeiçoamentos em aplicativos P2P.

Capturas de rede
Após outras tentativas malsucedidas de resolver os problemas de conexão, uma captura de rede das máquinas envolvidas parece um recurso promissor. Quando executei o Monitor de Rede da Microsoft (Netmon), ele produziu capturas que exibiam os resultados exatos em relação ao que eu estava vendo nas ferramentas de gerenciamento e nos scripts de teste: tudo funciona e deixa de funcionar, sem mais nenhuma indicação do erro.
A <Fig>Figura 2</Fig> mostra o resultado da execução de Netmon, que indicava a comunicação bem-sucedida entre os primeiros n sistemas. Observe que estou conseguindo confirmações das solicitações RCP. É isso o que você deseja ver – comunicação bidirecional bem-sucedida.
Figure 2 Successful communication in Netmon
Figure 2 Successful communication in Netmon
Agora você precisa observar as capturas do sistema de gerenciamento e das máquinas remotas que aparentam exibir o erro 53/1203. Como já se esperava, não há nada para ver, já que as máquinas não estão se comunicando. Na captura de rede da Figura 3, o sistema de gerenciamento resolveu o endereço IP e tentou se conectar ao sistema usando a porta 445 (a porta SMB Microsoft), mas jamais recebeu uma resposta.
Figure 3 Attempts to connect to the system over port 445 yield no response
Figure 3 Attempts to connect to the system over port 445 yield no response
O erro exibido quando você tem mais threads do que a capacidade de conexão atual da máquina nem sempre é consistente. Em alguns casos, talvez você veja um erro 53 no sistema de origem, o que indica que recebeu a resolução de nomes, mas que o endereço IP simplesmente não pôde ser encontrado. Isso é um indício de que o DNS está fornecendo um endereço ao qual você não consegue se conectar. Você pode receber um erro 1203 indicando que nenhuma máquina respondeu ao nome ou ao endereço IP solicitado. O erro 1203, nesse caso, indica que o DNS não está disponível para você. Você verá se esse é o caso, se executar nslookup.
Neste ponto, você já está prestes a se sentir frustrado, mas há mais opções a serem consideradas. A maioria das pessoas sequer pensará em olhar a infra-estrutura de conexão por conta da forma com que esse problema se apresenta: como a sua máquina é a única incapaz de se conectar ao restante da rede e os logs de eventos mostram que essa máquina atingiu o número máximo de conexões permitidas, o problema não parece ser de natureza arquitetônica.
Embora as milhares de conexões geradas pela solução em gerenciamento não sejam iniciadas simultaneamente, keep alives de transmissão e tempos limites de conexão podem indicar que você tem mais conexões abertas a qualquer momento do que pode imaginar. Por isso, você também deve examinar esses sistemas que se conectam ao restante da rede.
Deixe-me explicar. Como eu disse anteriormente, na medida em que passa pela rede, o tráfego passa por comutadores, roteadores e, quem sabe, firewalls. Em qualquer um desses pontos, normalmente o roteador ou o firewall, você pode encontrar sistemas de detecção de intrusões. Comutadores e roteadores gerenciados também podem usar a filtragem de tráfego. Você, ou quem tiver controle sobre esses dispositivos, precisará verificar os logs em busca de erros ou de avisos. O problema de comunicação pode muito bem estar nesses sistemas.
Por estar se conectando de um sistema interno a outros sistemas internos, você talvez ache que não há alertas sendo gerados, uma vez que o alerta não está configurado no dispositivo ou porque o problema não se qualifica como intrusão ou ataque de negação de serviço (DoS). Mais uma vez, você deve começar pelos logs. Usando o ISA Server como exemplo, esses logs podem ser encontrados no console Gerenciamento do ISA Server em Matrizes\<Nome_da_Matriz>\Monitoramento\Log.
Caso haja uma diretiva lhe impedindo, você pode (no caso do ISA Server) procurar os seguintes códigos resultantes em que o protocolo IP de origem é o seu computador de gerenciamento:
  • 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000d FWX_E_POLICY_RULES_DENIED
  • 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED
Caso encontre esses resultados, você identificou a raiz dos problemas de conectividade.

Implementando a solução
Agora que você identificou o problema, a solução pode ser simples, mas a política do departamento pode dificultar sua implementação. Antes de fazer qualquer alteração, verifique se você tem as permissões apropriadas para isso, já que a criação de exclusões nas configurações de segurança dos firewalls, roteadores e/ou sistemas de detecção de intrusões nem sempre é permitida.
Novamente, usando o ISA Server como exemplo, as seguintes etapas mostram como aumentar o número máximo de conexões de um determinado host ou de todas as máquinas na rede (como mostra a Figura 4). Abra o console Gerenciamento do ISA Server e navegue até Matrizes\<Nome_da_Matriz>\Configuração\Geral\Definir Configurações de Redução de Inundação.
Figure 4 Increase the maximum number of connections for one host or all machines using ISA Server
Figure 4 Increase the maximum number of connections for one host or all machines using ISA Server
As duas configurações importantes são as conexões TCP simultâneas máximas por endereço IP e solicitações de conexão TCP máximas por minuto para cada endereço IP. As conexões TCP simultâneas máximas por endereço IP costumam ser definidas em um valor que seria o suficiente onde não houvesse nenhum gerenciamento ativo, o que significa que nenhum computador está ativamente se conectando a milhares de outras máquinas rapidamente. No ISA Server, o limite padrão para conexões TCP máximas é de 160. As solicitações de conexão TCP máximas por minuto para cada endereço IP foram projetadas para limitar os danos e a visibilidade dos exames da rede. O limite padrão é de 600 solicitações de conexão por minuto para cada IP.
Conforme dito anteriormente, o Windows manterá uma conexão ativa durante um período padrão de dois minutos, desde que mais nada esteja tentando fazer o mesmo, ainda que a conexão não esteja sendo usada. Isso significa que, muito embora você já tenha conseguido gerenciar um computador com êxito e não precise mais se comunicar com ele, a conexão permanecerá ativa. Essa conexão aberta é contabilizada para o número total de conexões alocadas. Repita esse processo mais de 160 vezes sem remover as conexões, e você verá que todas as tentativas de conexão estão sendo negadas pelo roteador. Mesmo que o programa de gerenciamento finalize uma sessão de maneira ativa, o Windows pode muito bem manter a conexão em um estado time_wait ao aguardar o consentimento de uma máquina de destino para desconectar a sessão.
Comece fazendo os ajustes no mais provável culpado: as conexões TCP simultâneas máximas por endereço IP. Você deve definir isso de forma que a máquina de gerenciamento possa criar todas as conexões necessárias ao gerenciamento dos sistemas sem que haja a negação do acesso. Clique no botão Editar próximo da configuração e altere os valores.
A próxima solicitação (consulte a Figura 5) tem uma caixa Limite que representa o limite padrão, aplicável a todos os clientes. O limite Personalizado se aplica a todas as máquinas, redes etc. definidas na guia Exceções de IP da caixa de diálogo de redução de inundação. Caso você queira que todas as máquinas tenham permissão para criar mais conexões, altere o valor de Limite. Para configurar a exceção apenas para a sua máquina de gerenciamento, ajuste o limite Personalizado e adicione a máquina à guia Exceções de IP. Costuma ser melhor permitir a exceção apenas para a sua própria máquina.
Figure 5 Default connection limit and custom connection limit
Figure 5 Default connection limit and custom connection limit
Caso você queira usar o limite personalizado para modificar esse valor apenas para sistemas específicos, altere o valor no campo Limite personalizado e clique em OK. Em seguida, adicione a máquina à guia Exceções de IP da caixa de diálogo de redução de inundação. Para adicionar o seu único computador à lista de exceções, em Exceções de IP, clique em Adicionar para abrir a caixa de diálogo Conjuntos de Computadores. Clique em Novo para criar um novo conjunto de redes que conterá o(s) sistema(s) se ainda não houver um conjunto contendo essas máquinas. Selecione o conjunto de redes, clique em Adicionar para adicionar o conjunto Redes Internas e em Fechar. Selecione novamente o conjunto de redes Redes Internas e clique em Editar. Isso abrirá as propriedades de Redes Internas (consulte a Figura 6). Clique em Adicionar na caixa de diálogo para exibir um submenu em que é possível optar por adicionar um computador, um intervalo de endereços ou uma sub-rede; escolha o computador. Digite um nome para identificar a entrada, o endereço IP da máquina e uma descrição para que qualquer um que esteja vendo essa entrada mais tarde não se sinta tentado a remover o sistema (consulte a Figura 7). Clique em OK para adicionar o sistema e clique nele novamente para adicionar a exceção. Agora que já fez essas alterações, você deve aplicar as configurações.
Figure 6 Internal networks properties settings
Figure 6 Internal networks properties settings
Figure 7 Enter computer name, IP address, and description to ensure your system is not removed
Figure 7 Enter computer name, IP address, and description to ensure your system is not removed
Tente usar a ferramenta de gerenciamento proativa novamente, e você deve notar que o desempenho está muito melhor, além da conexão não apresentar nenhuma falha – pelo menos não em decorrência do tráfego de rede. No final das contas, acontece que o problema não foi o número de conexões iniciadas pelo software, e sim a falta de planejamento apropriado para elas a responsável pela interrupção.

Lições aprendidas
Uma das maiores dores de cabeça da TI é enfrentar e resolver os problemas realmente enganosos. Trata-se de problemas que não foram criados pelo usuário final ou pela equipe do servidor, que o suporte técnico desconhece e que, infelizmente, é de sua responsabilidade resolvê-los. Existem algumas ferramentas disponíveis que podem lhe ajudar a solucionar, isolar e resolver problemas, mas, às vezes, elas não são o suficiente. Às vezes, elas estão erradas. E, em outras, você apenas precisa ser mais esperto do que elas.
Na próxima vez em que você se encontrar incapaz de estabelecer conexões com algumas máquinas da sua rede sem nenhuma razão aparente, tente executar as etapas que descrevi aqui. Há uma boa chance de, seguindo as etapas, observando o software de gerenciamento mais atentamente e configurando as conexões permitidas corretamente, conseguir resolver o problema com êxito.

Christopher Stoneff é gerente de produtos da Lieberman Software (liebsoft.com), uma desenvolvedora de softwares de segurança e de gerenciamento de sistemas. Chris tem mais certificações técnicas do que qualquer pessoa sã é capaz. A sua principal motivação não é apenas saber como algo funciona de uma determinada forma, mas por quê.


 Do editor: A conversa vai come&#231;ar
Do editor
A conversa vai começar
Joshua Hoffman

Quase tudo o que é importante que já aconteceu começou com uma conversa.
"Eu não acho que o mundo seja realmente plano. Nós deveríamos verificar isso, você não acha?"
"Por que não enviamos uma pessoa à lua?"
"Posso conversar com você sobre uma idéia que tenho para estes novos PCs?"
"Vamos nos encontrar e tomar uma xícara de café."
(Na verdade, essa última não é um evento importante... Eu simplesmente adoro café. Mas veja bem — se nos encontrarmos para um café, talvez tenhamos uma idéia importante!)
De qualquer forma, a noção de que tudo o que é importante normalmente começa com uma conversa parece ser verdadeira para mim em dois níveis neste mês. O primeiro está relacionado a uma conversa que está acontecendo no momento — em blogs, nos corredores e até mesmo nesta edição da TechNet Magazine (consulte a coluna Anotações de Campo, de Romi Mahajan, na pág. 91). É sobre o consumo de TI. Ela se concentra na noção de que não somos simplesmente profissionais de TI no trabalho. A verdade é que o que fazemos em nossas vidas diárias (contribuímos para caridade, cantamos em um karaokê, jogamos Xbox, entre outras coisas) tem um impacto no trabalho que fazemos e nas decisões que tomamos em nossas vidas profissionais. É uma conversa que eu e Romi, junto com alguns convidados especiais, teremos em uma discussão em painel chamada "O futuro fungível", a ser apresentada na próxima conferência Windows Connections, em Las Vegas. Espero que você se junte a nós ao vivo ou confira a discussão no site WeWantToKnow.net. E sinta-se à vontade para entrar na conversa em nosso blog, em blogs.technet.com/tnmag, porque queremos a sua opinião!
O segundo aspecto que desejo discutir é a tecnologia que usamos para permitir a existência dessas conversas. Na edição deste mês da TechNet Magazine, examinaremos os principais aprimoramentos feitos no Exchange Server para que você consiga se manter conectado de forma mais fácil — seja ao outro lado do corredor ou ao outro lado do mundo. Mostraremos os aprimoramentos que o Exchange Server 2007 SP1 tem a oferecer, como a Replicação Contínua Standby pode fortalecer consideravelmente os seus planos de recuperação de desastres, como a plataforma do Exchange será melhorada pelo Windows Server 2008 e como a Unificação de Mensagens tornará as suas conversas ainda mais poderosas. Há um bônus especial neste mês, a edição impressa da TechNet Magazine inclui o último de uma série de pôsteres extremamente populares dos editores colaboradores Astrid McClean e Martin McClean. Talvez você já tenha visto o pôster premiado de quebra-cabeças do componente Active Directory ou os pôsteres do Windows Server 2008 mostrados aqui. Neste mês, eles terão como tema o Exchange. A conversa vai começar! — Joshua Hoffman

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Ed Banti, Anah Cameron, Chun Yong Chua, Cliff Didcock, Jeremy Kelly, Michael Murgolo, Jon Orton, Jeff Ressler, Kevin Sullivan, Jim Truher, Scot Vidican e Michael Wilson.

Joshua Hoffman


 Cartas: Com a palavra, os leitores
Cartas
Com a palavra, os leitores

Utilitário PageDefrag
Tentei executar o utilitário SysInternals PageDefrag abordado na edição de setembro de 2007. Porém, ele apresentou uma falha no Windows Vista® x64 com o erro "Make sure that you are an administrator. Error loading PageDefrag driver" ("Verifique se você é um administrador. Erro ao carregar o driver PageDefrag.")
—Alex D.

No momento, não há suporte para o utilitário PageDefrag no Windows Vista. Ele só funciona no Windows NT® 4.0, Windows® 2000, Windows XP e Windows Server® 2003. Pedimos desculpas por isso não ter ficado claro no artigo de setembro.

Agendador de backups
Li o artigo "Uma guia para as tecnologias de backup do Windows Vista" na edição de setembro de 2007 com muito interesse, mas tenho algumas dúvidas. A Figura 2 do artigo mostra uma data e uma hora para o próximo backup. Como isso é possível se a ferramenta de backup não contém seu próprio agendador?
Como as alterações feitas nos blocos de disco são a base para determinar o que deve ter backup, o que acontecerá se houver a desfragmentação do disco? Isso resulta no backup de uma grande quantidade de dados porque os blocos foram movidos ou alterados? Além disso, durante uma restauração, caso os blocos sejam restaurados em seu local original, de que forma isso é afetado por uma desfragmentação de disco?
—Bruce G.

Recorremos à fonte (a autora Christine Fok) para o assunto, e aqui está o que ela tinha a dizer:
A Figura 2 mostra a data e a hora do próximo backup de arquivo e pasta, mas apenas a hora do Backup do Complete PC mais recente. É possível agendar um backup em nível arquivo/pasta, mas, como você observou, o Complete PC Backup não contém seu próprio agendador.
Você tem razão ao dizer que a execução do Defrag entre dois Complete PC Backups poderia tornar o segundo maior. E a respeito da restauração após a desfragmentação, você também está correto. O Complete PC funciona no nível do volume, abaixo do sistema de arquivos. Ele recoloca todos os blocos exatamente onde estavam no momento do backup, nos mesmos locais do disco, independentemente de o Defrag ter sido executado após a realização do backup. Por isso, talvez você precise desfragmentar novamente o volume após a restauração.

Ferramenta BGInfo
Gostei muito de toda a coluna Utilitário em destaque da edição de agosto de 2007. A ferramenta BGInfo da SysInternals que coleta informações essenciais sobre a CPU e a rede estava excepcional. Gosto de ler a respeito de pessoas que desenvolvem novos produtos, utilitários, programas ou aplicativos. O Sr. Cogswell desenvolveu outros softwares para a Microsoft?
—Daryl B.

Ficamos contentes em saber que você achou o BGInfo útil! Bryce Cogswell criou vários utilitários práticos, normalmente em parceria com Mark Russinovich, como parte da Sysinternals. Felizmente, a Microsoft adquiriu a Sysinternals em 2006, e agora tanto o Sr. Cogswell quanto o Dr. Russinovich trabalham aqui. Você encontra todos os seus utilitários no site da Sysinternals em microsoft.com/technet/sysinternals.

RPC e firewalls
O artigo "Solucionando problemas de RPC" da edição de julho de 2007 foi muito útil, mas deixou um aspecto importante de lado: o Firewall do Windows também pode causar erros de RPC. Se o Firewall do Windows estiver configurado para permitir solicitações PING, mas não mensagens de entrada não solicitadas, todas as tentativas de gerenciar remotamente uma máquina falharão. Caso você execute RPCPING.exe do Windows Resource Kit, o erro retornado é 1722 (o servidor RPC não está disponível).
Nesse caso, o firewall está fazendo exatamente o que deveria: impedir o acesso de estranhos a um determinado sistema. Infelizmente, ele também fará isso com os administradores, uma vez que eles tentam gerenciar as máquinas em uma rede corporativa.
—Aaron M.

Agradecemos a indicação de outra possível origem de dificuldades com RPC. Esperamos que as ferramentas mencionadas no artigo possam ajudá-lo a solucionar esses problemas.

Licenças do Windows XP
A coluna Anotações de campo, de outubro de 2007, mencionou a possibilidade de comprarmos licenças do Windows XP por apenas US$ 5,00. Somos uma editora sem fins lucrativos, e eu estava me perguntando de que forma podemos consegui-las. Existe alguma forma de fazermos isso por telefone ou email? Tenho email, mas não tenho acesso à Web.
—Ernest B.

Você pode entrar em contato com o parceiro administrativo MAR, a TechSoup, pelo email communitymar@techsoup.org ou ligando para 800-659-3579 ramal 350. Também é possível escrever para: Community MAR Administrator, TechSoup Stock, 435 Brannan Street #100, San Francisco, CA 94107.


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

Monitorar sistemas de rede
ActiveXperts Network Monitor
activexperts.com
Quando você é administrador de sistemas, é melhor saber quando algo dá errado antes de seus usuários começarem a sair de suas salas como uma matilha de cães assustados. O monitoramento de serviços é uma ferramenta fundamental para o gerenciamento proativo da sua infra-estrutura. O ActiveXperts Network Monitor é uma solução robusta que inclui algumas verificações diferentes que podem ser usadas em sua LAN/WAN e em seus servidores Windows®, Novell e *NIX para a garantia de que você descobrirá os problemas antes de ser notificado pelos usuários.
O ActiveXperts Network Monitor é um aplicativo baseado em Windows executado como um serviço na máquina designada como a sua estação de monitoramento — o sistema operacional base dessa máquina pode ser o Windows 2000, o Windows Server® 2003, o Windows XP ou o Windows Vista®. Após a instalação, um rápido assistente de configuração orientará você pela configuração de notificações por email, por SMS e a freqüência de exame padrão ou o limite de falha. Você também pode adicionar um conjunto de verificações padrão que poderá ser usado como exemplo em sua configuração. Isso é muito útil para sair do bloco em execução e mostra o básico de como é possível configurar os diferentes recursos do aplicativo para atender as necessidades do seu ambiente.
O aplicativo é dividido em três componentes separados: o Network Monitor Engine é o serviço do Windows que executa continuamente as suas tarefas de monitoramento; o Network Monitor Manager é um aplicativo do Windows que permite a você ver a atividade de monitoramento atual, exibir os resultados de tarefas e fazer alterações em sua configuração. Uma interface da Web oferece acesso somente leitura às tarefas e aos resultados das tarefas.
Além da execução de verificações de monitoramento, o Network Monitor Engine também manipula notificações, ações disparadas por resultados e logs do aplicativo. O mecanismo de monitoramento é multithreaded, permitindo que ele seja dimensionado para o seu ambiente. O serviço não requer que um agente de ponto de extremidade execute suas verificações de monitoramento, mas isso significa que você terá de fornecer credenciais administrativas para monitorar servidores ou estações de trabalho Windows remotos. Felizmente, você pode especificar vários conjuntos de credenciais para que o monitoramento entre domínios e contextos de segurança diferentes não exija uma única conta muito poderosa e assim sua solução de monitoramento consiga ser executada.
Provavelmente você passará a maior parte do seu tempo no Network Monitor Manager, que lhe oferece um controle granular sobre todos os recursos, configurações e funcionalidade. Aqui, você poderá organizar as suas tarefas de monitoramento em uma estrutura de árvore de pastas, o que o ajudará a localizar e identificar itens de forma mais rápida em ambientes grandes, bem como a filtrar o modo de exibição atual da interface do usuário para um rápido exame de um conjunto de tarefas de monitoramento.
A adição de uma nova verificação de monitoramento é simples. O Network Monitor inclui quase 40 verificações internas, incluindo verificações de IP e de protocolos (como ICMP, LDAP, SMTP e HTTP), verificações do Windows (como verificações de CPU, de processos, de memória e de servidor de terminal), conectividade ODBC, TnsPing Oracle, verificações de banco de dados baseadas em consulta OLEDB, verificações de associação Novell e verificações RSH do *NIX. Além disso, você pode monitorar detalhes ambientais (como temperatura e umidade) usando o monitor SensaTronics da sua rede.
O aplicativo oferece suporte a scripts VBScript e do Shell Remoto, permitindo que você ajuste as tarefas de monitoramento. Foi incluído no aplicativo um conjunto de modelos VBScript para o monitoramento de vários serviços, como antivírus, o® ISA Server e consultas XML, para que você não tenha de começar do zero na criação de tarefas de monitoramento personalizadas.
Você pode definir a freqüência de verificações e o limite de falha para cada tarefa e pode agendar verificações em dia e hora específicos para os casos em que for necessário, por exemplo, verificar os resultados de algum outro processo em execução, como uma tarefa de arquivamento de logs ou a redefinição de um pool de aplicativos do IIS. Você também pode especificar a execução de trabalhos executáveis, de script e em lote quando uma verificação falhar ou se recuperar, assim como forçar a reinicialização de um determinado serviço. Por fim, a interface da Web exibe os dados XML resultantes traduzidos para XSL. As folhas de estilo podem ser facilmente ajustadas para a criação de um modo de exibição personalizado para a sua NOC (Central de Operações de Rede) ou seu dispositivo móvel e, já que os dados estão em XML, será possível recuperá-los com facilidade para utilização em outro aplicativo ou sistema agregado.

Preço: a partir de US$ 395 para venda direta de uma licença de cinco servidores.
ActiveXperts Network Monitor includes sample checks to get you started
ActiveXperts Network Monitor includes sample checks to get you started

Resenha de livro
Resource Kit do Windows Vista
microsoft.com/mspress/books/9536.aspx
À medida que mais e mais organizações estão começando a integrar clientes do Windows Vista às suas infra-estruturas, os profissionais de TI precisam conhecer as ferramentas disponíveis no novo sistema operacional. O recém-publicado Resource Kit do Windows Vista (Microsoft Press®, 2007) aborda grande parte das informações e ferramentas de que você precisará para implementar clientes do Windows Vista na empresa — tudo, desde a automatização da instalação e ativação de volume até a manutenção e gerenciamento da área de trabalho e a utilização de redes IPv6 e assistência remota. Além de suas 1.568 páginas, esse livro também inclui um DVD de suporte com mais de 100 scripts de administração e implantação, um conjunto de ferramentas de depuração, o BDD (Solution Accelerator for Business Desktop Deployment) e outros itens úteis.
Começando com uma visão geral dos novos recursos encontrados no Windows Vista, o livro dá uma atenção especial aos aprimoramentos de segurança, como o UAC (Controle de Conta de Usuário), a criptografia de unidade BitLocker e a DEP (Prevenção de Execução de Dados). Discute também o conceito de proteção de serviços e o kernel patch protection. A partir daí, ele prossegue para a implantação do Windows, explorando as inúmeras ferramentas à sua disposição e que o ajudarão a automatizar o processo. Por exemplo, o livro examina a configuração de uma pré-instalação e ambiente de recuperação do Windows PE 2.0 e mergulha no BDD 2007, oferecendo orientação sobre o planejamento e a implantação do Windows Vista na empresa. Além disso, existem as práticas recomendadas para criação e configuração de imagens de disco e uma discussão informativa sobre como migrar dados de usuário usando a Transferência Fácil do Windows e a Ferramenta de Migração de Perfil do Usuário.
O livro entra em detalhes do gerenciamento do ambiente da área de trabalho por meio de diretivas de grupo, mergulhando nos novos arquivos de modelo administrativo baseados em XML (ADMX). Ele aborda também o gerenciamento de discos e de sistemas de arquivos e examina os novos aprimoramentos, ReadyBoost e BitLocker, do Windows Vista. Explica como funcionam as Versões Anteriores, as Cópias de Sombra e as cotas de disco e até mesmo explora a forma como você pode implantar e gerenciar o Espaço de Reunião do Windows em Grupos de Trabalho, Domínios e ambientes sem fio ad hoc.
A seção sobre a manutenção da área de trabalho aborda tarefas, Relatórios de Erros do Windows, monitoramento de desempenho e Eventos do Windows. Examina também como você pode utilizar a Assistência Remota em seu suporte técnico. A discussão prossegue para as atualizações de software, o BITS (Serviço de Transferência Inteligente em Segundo Plano) e o Windows Update, além das ferramentas de auditoria.
A seção sobre redes detalha o funcionamento do Firewall do Windows e explica os novos aprimoramentos feitos na pilha de rede. Também é mostrada a utilização da Área de Trabalho Remota e conexões de VPN na configuração de usuários remotos e de redes.
Por fim, o livro oferece a você uma boa cobertura da solução de problemas, desde a inicialização até erros de rede, de driver e de dispositivos. Em alguns pontos, há uma ligeira influência oculta de marketing, mas isso não significa, de forma alguma, que sejam mais de 1.500 páginas de algo sem valor. É um exame profundo e abrangente do Windows Vista, de suas ferramentas e do gerenciamento do sistema operacional.

Preço: US$ 59,99 para venda direta.

Análise do tráfego HTTP
Charles Web Debugging Proxy
xk72.com/charles
Considerando a abundância de comunicação baseada em HTTP entre aplicativos e entre as suas estações de trabalho, servidores e a Internet, um bom analisador de tráfego HTTP é uma ferramenta incrivelmente útil para os administradores de sistema. Ela pode ajudá-lo a identificar erros de proxy, preocupações com segurança, erros de conectividade, problemas de configuração e defeitos na comunicação entre aplicativos. Uma ferramenta de que gosto bastante é o aplicativo baseado em Java de Karl von Randow, o Charles Web Debugging Proxy.
Assim como outros proxies de depuração, o aplicativo se define como o intermediário dos tipos — ele se posiciona entre aplicativos de ponto de extremidade, interceptando e interpretando o tráfego que vê. Graças a essa configuração, o aplicativo também permite que você veja o tráfego HTTPS criptografado em sua forma descriptografada de texto sem formatação. A interface do usuário possui um modo de exibição bem organizado da sessão registrada, dando a você uma variedade de informações, desde as solicitações básicas de páginas, imagens, scripts e folhas de estilo até os detalhes essenciais sobre tamanho, latência e tempo. Você também pode ver que cookies estão sendo enviados e recebidos em cada solicitação e o que contêm; pode até mesmo optar por bloquear todos os cookies.
Você pode solucionar problemas de cache de solicitações com o Charles Web Debugging Proxy ao verificar as últimas datas de modificação em respostas 304 Não Modificado ou ao optar por desabilitar o cache removendo os cabeçalhos relacionados a ele das solicitações e respostas pertinentes quando estas passarem pelo aplicativo. Na verdade, utilizando as configurações de regravação do aplicativo, você pode definir um conjunto de regras que regravam um número de cabeçalhos HTTP ou conteúdo do corpo quando as solicitações e respostas passarem pelo aplicativo. Ou você poderia até usar as configurações de falsificação do DNS do aplicativo para substituir o endereço IP de um host, permitindo o teste de solicitações para itens que possam não estar registrados no DNS. Isso é ótimo para o teste de, por exemplo, um novo servidor Web para garantir que ele está escutando e respondendo corretamente ao cabeçalho do host antes de entrar no ar.
Você também pode usar a ferramenta para depurar solicitações e respostas do AJAX e examinar os dados XML brutos da resposta. Na interface do usuário, você pode até ver os dados brutos da solicitação e da resposta no texto para ajudá-lo a encontrar quaisquer cabeçalhos estranhos.
A ferramenta oferece dois bons layouts de dados que realmente lhe dão uma idéia clara sobre a transação de dados: a tabela Summary (Resumo) e a tabela Chart (Gráfico). A tabela Summary permite que você verifique rapidamente os dados de solicitação/resposta, mostrando o tamanho do cabeçalho, o tamanho do corpo, o tempo de resposta, o código de resposta, o tipo MIME e o recurso. A tabela Chart, por outro lado, oferece uma linha de tempo gráfica do ciclo de vida que mostra onde os dados de solicitação/resposta ocorreram na seqüência e qual a duração da transação.
Você pode salvar as suas sessões de gravação para reprodução e análises posteriores. Isso pode ser útil na captura daquele fluxo de solicitação/resposta complicado que causa erros esporádicos de comunicação; quando ele acontecer, você poderá reproduzi-lo. Você pode até importar arquivos de rastreamento de HTTP para uma nova sessão, além de exportar a sessão atual para o formato CSV ou HTTP.
Para simulações de solicitação em larguras de banda menores — por exemplo, quando você estiver tentando descobrir por que uma solicitação falha em uma linha de modem de 56k mas não em sua rede corporativa — o aplicativo oferece um recurso de transmissão que permite a você optar por um dos itens comuns predefinidos de um conjunto ou definir um novo com base em quatro pontos de transmissão: largura de banda, percentual de utilização, latência de ida e volta e a Unidade Máxima de Transmissão. Você também pode configurar o proxy de depuração para que ele aja como um proxy reverso ou um encaminhador de porta, vinculando uma porta local a um ponto de extremidade remoto (e porta), para que todo o tráfego enviado para aquela porta seja redirecionado para o endereço remoto.

Preço: a partir de US$ 50 para venda direta de uma licença de usuário.
Charles Web Debugging Proxy analyzes HTTP traffic
Charles Web Debugging Proxy analyzes HTTP traffic

Limpar os arquivos desnecessários
Wise Disk Cleaner 2
wisecleaner.com
Um disco rígido é um tipo de casa — as coisas se acumulam ali com o tempo e são coisas que você não precisa realmente manter. De vez em quando, é uma boa idéia passar algum tempo jogando fora o lixo. Existem alguns métodos padrão para a limpeza de discos rígidos com ferramentas internas do Windows, como a ferramenta do sistema Limpeza de Disco e a funcionalidade de pesquisa. Mas, em algumas ocasiões, um utilitário rápido e fácil de usar é a melhor opção — especialmente se você puder obtê-lo gratuitamente. Uma dessas ferramentas é o Wise Disk Cleaner 2, que pesquisa os seus discos rígidos procurando por arquivos incômodos que só estão juntando poeira e que podem ser removidos com segurança do seu sistema.
Uma das características de que eu realmente gosto dessa ferramenta é que ela apresenta todos os arquivos encontrados na interface do usuário, facilitando a localização de qualquer problema potencial. Outro ótimo recurso, ela permite que você adicione padrões de arquivo adicionais para verificação e remoção. Caso seja necessário, o Wise Disk Cleaner também limpa arquivos temporários da Internet e você ainda pode optar por reter os cookies para não perder as preferências de site que possam estar armazenadas neles. Você também pode remover os arquivos de desinstalação do Windows Update, além de limpar a fonte do Windows Update, a lista de arquivos recentes e as pastas temporárias do Windows e do usuário. Você pode até executar automaticamente o aplicativo, definindo suas preferências para excluir os itens permanentemente ou somente movê-los para a sua Lixeira. O aplicativo também registra em log suas atividades para revisão posterior — nada mal para uma ferramenta gratuita.

Preço: gratuito.
Wise Disk Cleaner 2 finds files that you can safely delete
Wise Disk Cleaner 2 finds files that you can safely delete

Gerenciar dispositivos de rede
iReasoning Networks MIB Browser Personal Edition
ireasoning.com/mibbrowser.shtml
Se você possui algum dispositivo, aplicativo ou sistema de rede habilitado com o protocolo SNMP em sua infra-estrutura, o iReasoning Networks MIB Browser permite que você carregue um conjunto de arquivos da MIB (Base de Informações de Gerenciamento) e navegue pela estrutura hierárquica por meio de um modo de exibição muito parecido ao do Windows Explorer. Aqui, você pode ver os detalhes do objeto selecionado, incluindo o OID (identificador do objeto), a sintaxe, o acesso leitura/gravação e a descrição.
Você pode emitir com facilidade uma solicitação SNMP para recuperar dados de um dispositivo de rede por meio da interface do usuário. Basta digitar o endereço IP do dispositivo, selecionar o objeto da MIB e clicar em Go (Ir). Se necessário, você também pode definir a porta, a versão de solicitação de SNMP e as cadeias de caracteres de comunidade de leitura e de gravação. Fazer alterações em um agente é muito simples (supondo que o seu dispositivo permita isso). Basta selecionar o OID, o tipo de dados e o valor e clicar em OK. Além disso, existe um utilitário interno para enviar e receber interceptações que permite a você emitir interceptações e examinar sua atividade (para a qual é possível aplicar filtros e tornar o dispositivo em questão mais fácil de ver).
O iReasoning Networks MIB Browser Personal Edition é gratuito mas não oferece suporte ao SNMPv3 e está limitado à carga simultânea de cinco MIBs. Talvez você queira considerar a Professional Edition (US$ 269 para venda direta de licença), que inclui recursos adicionais e oferece suporte a SNMPv3, descoberta de rede e comparação de dispositivos.

Preço: gratuito.
iReasoning Networks MIB Browser
iReasoning Networks MIB Browser

Greg Steen é profissional de tecnologia e entusiasta em busca de novas ferramentas e métodos para ajudar a tornar as tarefas operacionais e de desenvolvimento mais fáceis para os profissionais de TI.


 P+R SQL: Configura&#231;&#227;o da mem&#243;ria, cria&#231;&#227;o de perfil de desempenho, configura&#231;&#227;o do fator de preenchimento e muito mais
P+R SQL
Configuração da memória, criação de perfil de desempenho, configuração do fator de preenchimento e muito mais
Edited by Nancy Michell

Configuração da memória
Dica: criação de perfil mais simples
Você sabia que agora pode correlacionar o PerfMon ao SQL Server 2005 Profiler?
Talvez você tenha notado picos de uso de CPU, consumo excessivo de memória ou desempenho geral lento no Monitor de Desempenho da sua máquina com SQL Server e queira saber o que causou essas anomalias de desempenho. Antes do SQL Server 2005, você tinha de usar o Profiler para capturar um rastreamento, examinar processos do sistema no Enterprise Manager e, por fim, capturar os logs do seu Monitor de Desempenho — o que, é claro, exigia a execução do PerfMon. E depois de todo esse trabalho usando todas essas ferramentas, você ainda precisava reconciliar manualmente os eventos entre as ferramentas para descobrir qual era o problema de desempenho. E isso significava trabalhar arduamente e repassar os logs um por um. Não era divertido, mas você tinha de fazer isso se quisesse chegar ao fundo dos seus problemas de desempenho.
Com o SQL Server 2005, você ainda precisa capturar um rastreamento e examinar os logs do seu PerfMon, mas o Profiler agora permite que você os anexe. Você pode rolar pelas suas instruções T-SQL e o Profiler mostrará automaticamente e de forma gráfica o que aconteceu. Se você clicar na interface do usuário do Monitor de Desempenho no Profiler, pulará para a instrução relacionada ao carimbo de data/hora. Isso poupa muito tempo na solução de problemas do seu ambiente SQL Server.
Vamos ver como anexar logs do PerfMon ao Profiler:
  1. Inicie o Monitor de Desempenho e comece a capturar informações do servidor de banco de dados.
  2. Crie um novo log de contador nos Alertas e Logs de Desempenho e digite um nome para ele.
  3. Adicione novos contadores, como % Tempo de Processador. Você também vai querer definir o início da captura dos logs manualmente ou agendá-la usando a guia Agenda.
  4. Clique em OK e, se a opção manual tiver sido a escolhida, não se esqueça de iniciar a captura de logs.
  5. Configure um rastreamento em seu SQL Server por meio do Profiler. Faça isso clicando em New Trace (Novo Rastreamento) no menu File (Arquivo). Não se esqueça de incluir a hora de início e hora de término em seu rastreamento, dê um nome a ele e defina-o para ser salvo em um arquivo. Por fim, você deve utilizar ao máximo o seu servidor para simular alguma atividade de transação, e depois interrompa a captura de dados do Monitor de Desempenho e do Profiler.
  6. No Profiler, selecione Import Performance Data (Importar Dados de Desempenho) no menu File (Arquivo). Em seguida, escolha o local onde você armazenou o seu log do PerfMon e selecione File | Open | Trace (Arquivo | Abrir | Rastreamento). Por fim, selecione o local onde o seu rastreamento do Profiler foi armazenado.
Depois de terminar, você verá como é muito mais fácil descobrir que efeito em particular as instruções SQL tiveram no tempo de processamento.

P Estou tentando descobrir a melhor configuração de memória para os meus servidores SQL Server™. O administrador antes de mim definiu o Boot.ini para cada máquina com 12 GB de RAM em um cluster de dois nós do SQL Server 2000 como a seguir: Sim /PAE NO /3GB (Nenhum AWE definido para o SQL Server). Com 12 GB de RAM disponíveis, eu deveria remover a opção /3GB do Boot.ini, ativar o AWE e oferecer cerca de 10 GB dos 12 GB ao SQL Server? Não existe nada mais nas máquinas que executam o SQL Server e, portanto, nenhum outro aplicativo precisa da memória.
R Sim, você deve ativar o AWE (address windowing extensions) e pré-alocar um limite superior de RAM para o SQL Server — 10 GB parece ser um bom número para um servidor SQL Server dedicado com 12 GB (observe que a pré-alocação só será válida para o SQL Server 2000. A partir do SQL Server 2005, a utilização do AWE não é mais estática e pode ser alterada de forma dinâmica). Sempre houve um grande debate sobre a utilização ou não das opções /3GB e /PAE ou somente da /PAE obrigatória. Embora na verdade só seja preciso definir /PAE e habilitar o AWE, sugiro que você utilize ambas as opções; no entanto, existem alguns fatores a serem considerados.
A utilização da opção /3GB se resume a ser necessária em sua situação em particular. Estão acabando as áreas MemToLeave da memória que deveriam estar nos 2 ou 3 GB do espaço de endereço virtual? Se você habilitar a opção, estará privando o sistema operacional de memória? (Consulte support.microsoft.com/kb/316739 para obter mais informações). Se você estiver trabalhando em um cluster, poderia definir /3GB em um nó e não no outro. Dessa forma, se você estiver fazendo testes com /3GB e estiver tendo problemas, poderá fazer o failover da instância para o outro nó de forma muito rápida. Tenha em mente que se você tiver mais de 16 GB de RAM, a opção /3GB não terá suporte.
Ao usar /3GB, você estará aumentando o VAS (espaço de endereço virtual) em 50%, para que os aplicativos que colocam pressão de memória no VAS e não somente no cache de dados tenham grandes vantagens. Felizmente, os servidores de 64 bits, tanto o IA64 como o x64, eliminam esse fator incompreendido. Preocupações quanto a privar o sistema operacional não se aplicarão caso a máquina seja dedicada ao SQL Server. Deixar 2 GB para o sistema operacional também é um pouco de exagero; se esse servidor é dedicado ao SQL Server com somente os serviços mínimos e padrão do sistema operacional em execução, você verá que sobrará cerca de 1,3 GB de memória livre no servidor e, portanto, você também poderá deixar que o SQL Server utilize o 1 GB extra. Comece com 10 GB, use o PerfMon para monitorar a memória disponível em um período longo para ver o quanto permanecerá ocioso e faça os ajustes adequados. Lembre-se de que você terá swap se comprometer excessivamente o SQL Server 2000, já que o AWE não é tão dinâmico como no SQL Server 2005. A chave para a decisão de usar ou não a opção /3GB é testá-la em seu ambiente específico.

Nomes de instância para replicação
P Agora posso usar o endereço IP do meu servidor na Replicação do SQL Server 2005 para indicar a instância a ser replicada? No SQL Server 2000, de acordo com o texto "Como: Replicar entre computadores que estejam executando o SQL Server em domínios não-confiáveis ou pela internet" (support.microsoft.com/kb/321822), fazer isso causará erros, mas eu não sei se isso ainda acontece.
R Durante a especificação de instâncias de servidor para a replicação, você deve fornecer o nome de instância registrado do SQL Server. Por exemplo, você deve usar o nome da instância do SQL Server quando especifica os parâmetros Editor ou Assinante para procedimentos armazenados da replicação ou para as configurações de conexão do agente de replicação na linha de comando. Se o nome de rede da instância do SQL Server for diferente do nome de instância registrado, as conexões de replicação por agentes falharão.
Se o nome de rede da instância e o nome da instância do SQL Server forem diferentes, considere a adição do nome de instância do SQL Server como um nome de rede válido. Uma forma de definir um nome de rede alternativo é adicioná-lo ao arquivo hosts local. Por padrão, o arquivo hosts local fica na pasta WINDOWS\system32\drivers\etc ou WINNT\system32\drivers\etc. Por exemplo, se o nome do computador for comp1, se o seu endereço IP for 10.193.17.129 e se o nome da instância for inst1/instname, adicione a entrada a seguir ao arquivo hosts:
10.193.17.129 inst1

SQL Server Integration Services
P Estou instalando um cluster ativo/ativo para o SQL Server 2005 (Enterprise Edition de 64 bits com dois servidores) e terei um total de quatro instâncias do SQL Server 2005. O SSIS (SQL Server Integration Services) será necessário para todas as instâncias. O que você pode me dizer sobre o SSIS em cluster e o efeito disso sobre os planos de manutenção?
R Embora você possa usar o serviço SSIS em cluster, não é necessário fazer isso e isso poderia causar uma variedade de problemas, incluindo a falta de suporte a delegação (consulte msdn2.microsoft.com/aa337083); e isso não inclui várias instâncias — você só pode ter uma instância em execução em um nó por vez.
Anteriormente, o SSIS tinha de ser instalado — não precisava ser executado, só instalado — para o Maintenance Plan Wizard (Assistente de Plano de Manutenção) poder ser executado. No entanto, isso não acontece mais no SQL Server 2005 SP1. Se o SSIS não estiver em execução, os planos de manutenção poderão ser executados pelo SQL Server Agent.
Em vez de usar o SSIS em cluster, você poderia pensar em mantê-lo em execução como um serviço autônomo e editar o MsDtsSrvr.ini.xml para apontar para todas as instâncias em execução. Isso permite que você gerencie os seus pacotes a partir de qualquer nó e ofereça a alta disponibilidade que a maioria dos clientes está procurando sem os problemas associados ao serviço em cluster.
Para obter mais informações sobre a criação de um plano de manutenção com falha, consulte o artigo da Base de Dados de Conhecimento em support.microsoft.com/kb/909036.

Tempos de execução estranhos
P Durante um teste de carga em meu servidor SQL Server 2005 SP1, o SQL Server Profiler registrou diversos valores negativos de tempo de execução de procedimentos armazenados (SP) e, em alguns casos, o tempo de execução de SP não foi igual ao resultado da subtração da hora de início da hora de término.
R Existem muitos aspectos que podem afetar a criação de relatórios de tempo de execução de SP e outros tempos de desempenho no SQL Server Profiler. Lembre-se, o SQL Server 2005 usa milissegundos para contar o tempo de execução e, se você estiver usando uma tecnologia que altere a unidade de medida, obterá relatórios inconsistentes e tempos de execução que não são somados.
Por exemplo, se você estiver usando outros esquemas de energia, nível de CPU ou a tecnologia Cool 'n Quiet da AMD, estará alterando freqüências de CPU, fazendo com que elas não sejam o que o SQL Server Profiler espera quando calcula o tempo de execução.
Existe um artigo da Base de Dados de Conhecimento em support.microsoft.com/kb/931279 que explica os sintomas, a variedade de motivos e algumas soluções.
Dica: verifique o seu fator de preenchimento
Digamos que você tenha um copo totalmente cheio de água e tente colocar ainda mais água. O que acontece? O copo transborda.
Isso também acontece com o SQL Server. Sempre que uma nova linha é adicionada a uma página de índice cheia, o SQL Server move cerca de metade das linhas para uma nova página e assim dar espaço para a nova. Isso é conhecido como divisão da página. As divisões das páginas abrem espaço para novos registros, mas também levam tempo e utilizam recursos com muita intensidade. E causam a fragmentação, o que pode afetar negativamente as operações de E/S. Dessa forma, como você pode evitá-las?
Para evitar essas situações, você precisa determinar, de forma proativa, o valor do fator de preenchimento. Quando um índice é criado ou refeito, o valor do fator de preenchimento determina a porcentagem de espaço em cada página de nível de folha a ser preenchida com os dados, reservando o resto para um crescimento futuro. Por exemplo, a configuração de um valor de fator de preenchimento 60 significa que 40% de cada página de nível de folha ficarão vazios para possibilitar a expansão do índice à medida que os dados são adicionados à tabela subjacente.
O valor de fator de preenchimento padrão sempre é 0, o que é adequado à maioria das situações. Basicamente, um fator de preenchimento 0 significa que o nível de folha é preenchido em quase toda a sua capacidade, mas algum espaço é deixado pelo menos para uma linha de índice adicional (observe que os fatores de preenchimento 0 e 100 são similares).
Você pode definir o valor de fator de preenchimento de índices individuais durante uma instrução CREATE INDEX ou ALTER INDEX ou pode configurar esse valor diretamente no servidor, para que qualquer novo índice criado utilize o padrão.
O exemplo a seguir define o valor de fator de preenchimento no servidor como 70%, o que significa que você deixará 30% de espaço livre para expansão futura. É claro que você deve testar com cuidado essa opção antes de implementá-la em um ambiente de produção.
USE Master; GO SP_Configure 'show advanced options',1; GO SP_Configure 'Fill Factor', 70; GO -- Você deve reiniciar o SQL Server Engine para que as alterações entrem em vigor.
E se você quiser configurar o fator de preenchimento no nível de índice individual? Suponha que você esteja criando a tabela a seguir e queira criar um índice exclusivo na coluna chamada Col_A com um valor de fator de preenchimento 70. O comando seria assim:
-- Criar uma tabela Item USE Item_DB; GO CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200)); GO;

-- Criar um índice exclusivo na coluna Col_A da tabela Item com valor de fator de preenchimento 70 CREATE UNIQUE INDEX AK_Index ON Item (Col_A) WITH (FillFactor = 70); GO
Como você identifica o fator de preenchimento para cada índice? Você pode consultar sys.Indexes para obter o valor de fator de preenchimento para todos os índices de um banco de dados, desta forma:
USE Item_DB; GO SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL; GO


 Utilit&#225;rio em destaque: A ferramenta da Microsoft para avalia&#231;&#227;o de seguran&#231;a
Utilitário em destaque
A ferramenta da Microsoft para avaliação de segurança
Lance Whitney
Faça download do código deste artigo: Microsoft Security Assessment Tool 3.0 (apenas em inglês) (10547.2KB)

O rastreamento de problemas de segurança de rede pode ser difícil e demorado. Uma ferramenta que pode ajudá-lo a identificar e a resolver riscos de segurança é o MSAT (Microsoft® Security Assessment Tool), um utilitário gratuito que apresenta um questionário eletrônico em que você descreve o seu ambiente de segurança. Projetado para empresas de médio porte, com uma estrutura de 50 a 500 computadores, o MSAT possui 172 perguntas organizadas em categorias diferentes e oferece uma análise da sua situação e recomendações sobre como aprimorá-la.
O MSAT começa por um conjunto de consultas sobre o seu modelo de negócios, utilizado para a criação de um BRP (Business Risk Profile, ou perfil de risco de negócios), que avaliará o seu risco de segurança em comparação a outras empresas do seu setor. Normalmente, o questionário pode ser preenchido em duas horas e você pode interrompê-lo e retomá-lo em qualquer ponto. Estas são as categorias com exemplos de perguntas:
Informações básicas A sua organização possui quantos clientes e servidores?
Segurança de infra-estrutura Os seus funcionários trabalham de forma remota? Os prestadores de serviço externos acessam a sua rede?
Segurança de aplicativos A sua empresa desenvolve aplicativos? Ela armazena dados confidenciais processados por seus aplicativos?
Segurança de operações A sua rede corporativa está conectada a redes externas? A sua organização recebe alimentações de dados de partes externas?
Segurança de pessoas A sua empresa terceiriza a manutenção dos computadores? Você permite que os funcionários baixem dados confidenciais da empresa para suas estações de trabalho?
Ambiente A sua organização possui quantos funcionários? Existe uma rotatividade alta em seu departamento de TI?
Em seguida, o MSAT gera uma avaliação que será utilizada como uma medida chamada DiDI (Defense-in-Depth Index, ou índice de defesa detalhada) e que se concentrará nos seus processos de segurança. Usando as mesmas categorias, estas são as perguntas típicas: a sua organização emprega firewalls em todos os locais? Você utiliza macros personalizadas em seus aplicativos do Microsoft Office? Os seus usuários possuem direitos administrativos em suas estações de trabalho? Você possui uma diretiva para a implantação de patches e de atualizações em seus PCs?
De acordo com as suas respostas, o MSAT oferecerá três relatórios. O relatório de resumo exibe um gráfico de barras com os resultados. Uma classificação alta no BRP indica mais risco, enquanto que uma classificação alta no DiDI representa mais segurança. Como o MSAT destaca, embora um BRP baixo e um DiDI alto pareçam ser preferíveis, na verdade é mais importante examinar áreas individuais. Dessa forma, para cada área, o relatório completo indica se você atende ou não a práticas recomendadas, se precisa aprimorá-las ou se alguma delas está ausente (consulte a Figura 1).
Figure 1 The complete report
Figure 1 The complete report
Por fim, o relatório de comparação solicita que você carregue os seus resultados de forma anônima em um site seguro do MSAT, onde poderá comparar os seus resultados aos de outras organizações.
Você pode baixar a ferramenta do site Orientação de Segurança da Microsoft, securityguidance.com, ou do site da TechNet Magazine, technetmagazine.com/code07.aspx.

Lance Whitney é consultor de TI, instrutor e redator técnico. Ele passa incontáveis horas fazendo ajustes em estações de trabalho e servidores do Windows. Jornalista de formação, Lance ingressou corajosamente no mundo de TI há 15 anos.


 The Cable Guy: Servidor de Diretivas de Rede
The Cable Guy
Servidor de Diretivas de Rede
Joseph Davies
Esta coluna se baseia em uma versão de pré-lançamento do Windows Server 2008. Todas as informações aqui contidas estão sujeitas a alterações.

O serviço Servidor de Diretivas de Rede (NPS) do Windows Server 2008 é o substituto do Serviço de Autenticação da Internet (IAS) do Windows Server 2003. O NPS permite que um computador que esteja executando o Windows Server 2008 aja como servidor e proxy do serviço RADIUS. RADIUS é um protocolo da Internet Engineering Task
Force (IETF) especificado nos RFCs 2865 e 2866 que oferece autenticação, autorização e contabilidade (AAA) centralizadas para dispositivos de acesso à rede como, por exemplo, pontos de acesso sem fio. Os servidores RADIUS realizam a AAA para dispositivos de acesso à rede. Já os proxies RADIUS encaminham mensagens RADIUS entre clientes (dispositivos de acesso à rede) e servidores RADIUS.
O NPS inclui muitos aprimoramentos para facilitar a implantação do acesso autenticado à rede, oferecer extensibilidade para componentes de terceiros e dar suporte às tecnologias de rede e plataformas mais recentes. O novo snap-in do NPS é mostrado na Figura 1.
Figure 1 The new NPS snap-in
Figure 1 The new NPS snap-in

Recursos do Servidor de Diretivas de Rede
Nesta coluna, abordarei os recursos do NPS que não estavam incluídos nas versões anteriores do Windows®. Começarei com a forma como a Proteção de Acesso à Rede (NAP) ajuda a impor requisitos de integridade do sistema para a rede e, em seguida, passarei por gerenciamento, configuração, suporte a IPv6 e outros elementos. Também descreverei os recursos do novo snap-in do NPS.
Proteção de Acesso à Rede A NAP, introduzida no Windows Server® 2008, é um conjunto de novas tecnologias capazes de ajudá-lo a impor a conformidade em relação aos requisitos de integridade do sistema, o que lhe permite proteger ainda mais a intranet. As diretivas de integridade podem especificar, por exemplo, que um firewall deve estar instalado e habilitado e que as atualizações mais recentes do sistema operacional devem estar instaladas em todos os clientes que se conectam à rede. Com a NAP, é possível criar diretivas personalizadas para certificar a integridade do computador antes de permitir o acesso à rede ou a comunicação, atualizar automaticamente os computadores para garantir a conformidade permanente e confinar os computadores não compatíveis em uma rede restrita até que obtenham essa conformidade. Para obter mais informações, consulte microsoft.com/nap.
Na implantação de uma NAP, o servidor NPS é um servidor de diretivas de integridade NAP que avalia a integridade de clientes NAP em nome dos pontos de imposição NAP – como, por exemplo, autoridades de registro de integridade (HRAs), pontos de acesso 802.1X, servidores de rede virtual privada (VPN) e servidores do protocolo DHCP. O servidor NPS também determina se os clientes devem ter acesso completo ou limitado à intranet. As diretivas de rede e de integridade, além das configurações NAP, determinam o comportamento de avaliação da integridade do NPS.
EAPHost e suporte a diretivas EAP O NPS dá suporte a EAPHost, a nova arquitetura para métodos de autenticação do protocolo EAP. Essa nova arquitetura permite que os fornecedores de método EAP desenvolvam e instalem facilmente novos métodos EAP para autenticação com base no 802.1X ou no protocolo PPP tanto nos computadores clientes quanto nos servidores NPS.
O EAPHost dará suporte à instalação e ao uso de todos os métodos EAP listados no Registro EAP em www.iana.org/assignments/eap-numbers, bem como a outros métodos de autenticação populares como, por exemplo, o Cisco Systems Lightweight EAP (LEAP). O EAPHost permite a coexistência de várias implementações de um método EAP. É possível, por exemplo, instalar e selecionar tanto a versão da Microsoft quanto a versão da Cisco Systems, Inc. para o EAP protegido (PEAP).
Para fornecedores de métodos EAP, o EAPHost dá suporte a métodos EAP já desenvolvidos para o Windows Server XP e o Windows 2003, além de uma forma mais fácil de desenvolver novos métodos EAP para o Windows Vista® e o Windows Server 2008. Após a instalação, é possível configurar os métodos EAP necessários a um determinado cenário de acesso à rede em uma diretiva de rede. Uma diretiva de rede para o NPS é a mesma diretiva de acesso remoto para o IAS.
Para obter mais informações sobre a arquitetura EAPHost, consulte technetmagazine.com/issues/2007/05/CableGuy.
Configuração armazenada no XML O IAS armazenou as informações sobre sua configuração em um banco de dados Jet. Agora o NPS armazena as informações sobre a configuração no formato XML, o que facilita a exportação da configuração de um servidor NPS e sua importação em outro. Exportar e importar arquivos de configuração é uma forma de sincronizar as configurações de vários servidores NPS em uma configuração tolerante a falhas. É possível exportar a configuração NPS usando o comando netsh nps export e importá-la usando o comando netsh nps import.
Conformidade com os critérios de engenharia mais comuns O NPS foi atualizado para dar suporte à implantação em ambientes que devem atender aos Common Engineering Criteria (CEC) Microsoft® . Para obter mais informações, consulte microsoft.com/windowsserversystem/cer/allcriteria.mspx.
DLLs de extensão eficientes do NPS O serviço NPS pode ser estendido por meio das DLLs de extensão e autorização. Ao contrário do que acontece com o IAS, esses componentes de terceiros são colocados na área de segurança do NPS para que qualquer problema enfrentado por eles não afete a operação ou a execução do serviço NPS.
Suporte a IPv6 O NPS dá suporte a IPv6 e à implantação em ambientes IPv6 nativos ou encapsulados. É possível configurar endereços IPv6 para clientes RADIUS ou servidores RADIUS remotos, e o serviço NPS pode se comunicar sobre IPv6 para operações de autorização e autenticação de conta nos serviços de domínio Active Directory® .
IAS X NPS
Se já estiver familiarizado com o snap-in do IAS para Windows Server 2003, você gostará das seguintes alterações feitas no snap-in do NPS:
  • As diretivas de acesso remoto se tornaram diretivas de rede e foram movidas para o nó Diretivas.
  • O nó Clientes RADIUS foi movido para o nó Clientes e Servidores RADIUS.
  • Não há mais um nó Processamento de Solicitação de Conexão. O nó Diretivas de Solicitação de Conexão foi movido para o nó Diretivas e o nó Grupos de Servidores Remotos RADIUS, para Clientes e Servidores RADIUS.
  • As condições da diretiva de acesso remoto e as configurações do perfil foram reorganizadas nas guias Visão Geral, Condições, Restrições e Configurações em relação às propriedades de uma diretiva de rede.
  • As condições da diretiva de solicitação de conexão e as configurações do perfil foram reorganizadas nas guias Visão Geral, Condições e Configurações em relação às propriedades de uma diretiva de solicitação de conexão.
  • A pasta Registro de Acesso Remoto foi renomeada para Contabilização e não tem mais os nós Arquivo Local ou SQL ServerTM .

Geração automática de segredos compartilhados RADIUS fortes Os segredos compartilhados RADIUS são segredos usados na verificação do envio de mensagens RADIUS por um cliente, servidor ou proxy RADIUS configurado com o mesmo segredo compartilhado. Os segredos compartilhados também são usados para criptografar atributos RADIUS sensíveis como, por exemplo, senhas e chaves de criptografia. Os segredos compartilhados RADIUS fortes são uma longa seqüência (mais de 22 caracteres) de letras, números e pontuações aleatórios.
Com o snap-in do NPS, é possível gerar automaticamente o segredo compartilhado RADIUS forte quando você adiciona ou edita um cliente RADIUS. Esse segredo compartilhado forte pode ser copiado para um editor de textos como, por exemplo, o Bloco de Notas, para que você tenha a possibilidade de configurar o dispositivo de acesso à rede ou o ponto de imposição NAP com o mesmo segredo compartilhado.
Integração com o Gerenciador de Servidores É possível instalar o NPS por meio das ferramentas Tarefa de Configuração Inicial e Gerenciador de Servidores. Em ambos os casos, você instala o NPS com a função Serviços de Acesso e Diretiva de Rede. Para começar, na ferramenta Tarefa de Configuração Inicial em Personalizar Este Servidor, clique na opção Adicionar Funções. Na ferramenta Gerenciador de Servidores, abra Resumo de Funções e clique em Adicionar Funções.
Após a instalação do NPS, é possível clicar em Serviços de Acesso e Diretiva de Rede no nó Funções da árvore de console do Gerenciador de Servidores para verificar o status do serviço NPS e exibir eventos de erro encontrados nas últimas 24 horas. Ao expandir o nó Serviços de Acesso e Diretiva de Rede do console, você pode configurar o NPS usando o snap-in do NPS.
Suporte avançado a Netsh O Windows Server 2003 tinha um conjunto limitado de comandos no contexto netsh aaaa para configurar o IAS. No Windows Server 2008, o novo contexto de netsh nps tem um amplo conjunto de comandos para configurar o NPS na linha de comando ou por meio de um script. Agora, com os comandos netsh nps, é possível configurar clientes e servidores remotos RADIUS, diretivas de rede, registrar em log e, para o NAP, diretivas de integridade, validadores de integridade do sistema e grupos de servidores de atualizações. Os scripts que consistem em comandos no contexto de netsh nps oferecem outra forma de sincronizar as configurações de vários servidores NPS em uma configuração tolerante a falhas.
Marcas de fonte do isolamento da diretiva de rede As diretivas de rede podem ser configuradas para um tipo específico de servidor de acesso à rede ou ponto de imposição NAP como, por exemplo, um servidor DHCP ou HRA, que se torna uma marca de fonte que classifica a diretiva de rede. Os servidores de acesso baseados no Windows Server 2008 e os pontos de imposição NAP incluem essa marca de fonte nas mensagens RADIUS. Quando uma mensagem RADIUS de solicitação de acesso é recebida, o serviço NPS tenta localizar uma diretiva de rede correspondente que tenha a mesma marca de fonte da mensagem de entrada. Caso não haja nenhuma diretiva correspondente, o NPS tenta localizar uma diretiva de rede que corresponda às diretivas que não têm nenhuma marca de fonte especificada.
Usar a marca de fonte na diretiva de rede e as mensagens RADIUS de entrada isola os tipos diferentes de diretivas de rede entre si. Por exemplo, as diretivas de rede dos servidores DHCP não são usadas em conexões VPN.
Integração com o Cisco Network Access Control O NPS dá suporte a recursos que se integram melhor a um ambiente que usa hardware e Network Access Control (NAC) da Cisco. Eles incluem o suporte ao protocolo HCAP (Host Credential Authorization Protocol) e às condições HCAP, além da condição de expiração da diretiva e da configuração da Proteção de Acesso à Rede em estado estendido nas diretivas de rede.
Novas condições das diretivas de rede As diretivas de rede do NPS têm novas condições que devem especificar grupos de computadores, grupos de usuários, tipos de EAP permitidos e endereços IPv6 de cliente e de servidor de acesso. Para o suporte a HCAP, o NPS tem novas condições para grupos de locais e de usuários. Para o suporte a NAP, o NPS tem novas condições de diretivas para tipo de identidade, diretiva de integridade, computadores compatíveis com NAP, sistema operacional e expiração de diretiva.
O snap-in do NPS O novo snap-in do NPS foi aprimorado significativamente para que seja possível criar e gerenciar com mais facilidade clientes e servidores RADIUS remotos, diretivas de rede para cenários de acesso à rede comuns, diretivas de integridade e configurações NAP para cenários NAP, além de configurações de registro em log.
No nó Clientes e Servidores RADIUS, você pode configurar clientes RADIUS (servidores de acesso à rede, pontos de imposição NAP ou outros proxies RADIUS quando NPS está agindo como um servidor RADIUS) e grupos de servidores remotos RADIUS (outros servidores RADIUS quando NPS está agindo como um proxy RADIUS).
No nó Diretivas, é possível configurar diretivas de solicitação de conexão (independentemente do serviço NPS agir como servidor ou proxy RADIUS), diretivas de rede (configurações de autorização, conexão e restrições quando o serviço NPS age como servidor RADIUS), além de diretivas de integridade (conformidade com integridade do sistema para clientes NAP). Quando você seleciona uma diretiva de solicitação de conexão ou uma diretiva de rede no painel de detalhes, o snap-in do NAP exibe as condições e as configurações da diretiva. A Figura 2 mostra um exemplo dessa aparência.
Figure 2 The NPS snap-in enhanced display
Figure 2 The NPS snap-in enhanced display
No nó Proteção de Acesso à Rede, o nó Validadores de Integridade do Sistema lhe permite configurar os requisitos de integridade NAP. O nó Grupos de Servidores de Atualizações permite que você configure o conjunto de servidores que os clientes NAP restritos podem acessar para os métodos de imposição VPN e DHCP NAP. Por fim, no nó Contabilização, é possível configurar como o NPS armazena informações de contabilização.
O snap-in do NPS inclui um amplo conjunto de assistentes para automatizar a configuração inicial de clientes RADIUS e as diretivas necessárias aos métodos de imposição NAP, conexões dial-up ou VPN e conexões com ou sem fio autenticadas por 802.1X. Para métodos de imposição NAP, o assistente NAP configura automaticamente todas as diretivas de solicitação de conexão, diretivas de rede e diretivas de integridade.
Esses novos assistentes estão disponíveis quando você clica no nó NPS do snap-in. Para definir diretivas e configurações dos métodos de imposição NAP, selecione Proteção de Acesso à Rede na caixa suspensa Configuração Padrão e clique em Configurar NAP. Para definir diretivas e configurações dos acessos à rede VPN ou dial-up, selecione Servidor RADIUS para Conexões Dial-Up ou VPN na caixa suspensa Configuração Padrão e clique em Configurar VPN ou Dial-Up. Para definir diretivas e configurações dos acessos com ou sem fio autenticados por 802.1X, selecione Servidor RADIUS para Conexões 802.1X com/sem Fio na caixa suspensa Configuração Padrão e clique em Configurar 802.1X.
Cada um desses assistentes o orienta durante a maioria dos elementos de configuração mais comuns para o cenário escolhido. Os assistentes para os métodos de imposição NAP são especialmente úteis: o assistente NAP para imposição VPN cria uma diretiva de solicitação de conexão, três diretivas de rede (para clientes NAP compatíveis, clientes NAP incompatíveis e clientes sem NAP habilitado) e duas diretivas de integridade (para clientes NAP compatíveis e incompatíveis).
Os novos assistentes NAP e os demais assistentes para a criação de clientes e grupos de servidores remotos RADIUS, além de diretivas de solicitação de conexão e de rede, facilitam – e muito – a configuração do NPS em vários cenários de acesso à rede.

Joseph Davies é redator técnico da Microsoft, ensina e escreve sobre assuntos relacionados a sistemas de rede do Windows desde 1992. Ele tem cinco livros publicados pela Microsoft Press e é autor da coluna online mensal da TechNet, The Cable Guy.


 Windows PowerShell: Indo mais fundo
Windows PowerShell
Indo mais fundo
Don Jones

O Windows PowerShell está repleto de recursos que costumam passar despercebidos por muitos administradores. Se for mais fundo, você encontrará alguns recursos incríveis. É verdade, sempre me vejo descobrindo novos recursos associados a um determinado cmdlet que pensava já conhecer por completo.
Nas aulas sobre o Windows PowerShellTM que ministro, eu recomendo aos administradores a criação de um calendário com o cmdlet do dia para eles próprios – semelhante a um calendário com a palavra do dia que você compra por aí. Dessa forma, em todas as manhãs da semana (eu deixo eles tirarem folga aos fins de semana), eles passam alguns minutos se familiarizando com todos os recursos de um cmdlet. O Windows PowerShell acompanha cerca de 130 cmdlets, o que significa ser possível aprender praticamente tudo o que o Windows PowerShell é capaz de fazer em aproximadamente seis meses, caso você siga o calendário. Nesse ponto, você estará pronto para todos os cmdlets do Exchange Server 2007.
Na coluna deste mês, quero mostrar alguns exemplos do que você pode descobrir e o que é possível obter bastando reservar alguns minutos para explorar os recursos mais avançados de diversos cmdlets.

Melhores relatórios HTML
Um cmdlet pouco usado é ConvertTo-HTML. Esse cmdlet inteligente pode aceitar uma coleção de objetos de entrada – serviços, processos, objetos da WMI (Instrumentação de Gerenciamento do Windows® ) ou o que quer que seja – e transformá-los em uma tabela HTML. Em seguida, é possível orientar o HTML a Out-File, e você tem uma página HTML pronta para ser postada em um servidor Web da intranet. Por exemplo, você pode agendar esta linha simples para ser executada em todas as manhãs:
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML | Out-File C:\ServiceAlert.html
Ela criará um relatório HTML, como o mostrado na Figura 1, dos serviços que devem ser iniciados automaticamente, mas que não estão em execução.
Figure 1 An HTML report of services that aren't running
Figure 1 An HTML report of services that aren't running
É claro que você talvez queira produzir um relatório que seja um pouco mais atrativo. Felizmente, o cmdlet ConvertTo-HTML produz HTML limpo, o que significa que ele não tem nenhuma formatação incorporada no código HTML criado. De acordo com as regras do HTML, você jamais deve aplicar a formatação no HTML (bem, você deve usar o mínimo possível). Na verdade, você deve aplicar a formatação em uma CSS (folha de estilo em cascata) externa e vinculá-la ao HTML. Ao final, é possível criar o link usando ConvertTo-HTML.
A CSS é vinculada à seção <HEAD> de um arquivo HTML. Olhando a ajuda de ConvertTo-HTML, você verá que sua sintaxe inclui alguns parâmetros que talvez tenham passado despercebidos:
ConvertTo-Html [[-property] <Object[]>] [-inputObject <psobject>] [-body <string[]>] [-head <string[]>] [-title <string>] [<CommonParameters>]
O parâmetro –head lhe permite especificar um código HTML adicional a ser inserido na seção <HEAD> do script. Agora eu posso tranqüilamente modificar meu programa one-liner para se vincular a um arquivo CSS existente que contém a formatação que desejo aplicar à tabela HTML:
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML -title "Services" -head "<link rel='stylesheet' href='styles.css' type='text/ css' />" | Out-File C:\ServiceAlert.html
Aqui, eu usei o parâmetro –head para inserir um link para um arquivo CSS localizado na mesma pasta do arquivo HTML de saída. Também usei o parâmetro –title para definir o título da página da Web. O resultado é mostrado na Figura 2. O texto do arquivo Style.CSS que usei é semelhante ao seguinte:
Figure 2 An HTML report that is formatted with a CSS file
Figure 2 An HTML report that is formatted with a CSS file
body { background-color:#EEEEEE; } body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt } th { font-weight:bold; background-color:#CCCCCC; } td { background-color:white; }

Filtragem mais simples
Cmdlet do mês
Neste mês, estou analisando um par de cmdlets: Start-Transcript e Stop-Transcript. Ambos são usados no controle do registro em log das transcrições do Windows PowerShell – ou seja, ele coloca em um arquivo de texto especificado por você tudo o que aparece na janela do console. É bem simples. Execute Start-Transcript e dê a ele um nome de arquivo antes de começar. Em seguida, execute Stop-Transcript para interromper o registro em log e feche o arquivo. Isso proporciona uma ótima maneira de deixar de usar o shell ad hoc e passar ao script formal – assim que tiver as linhas de comando funcionando no shell, basta copiar e colá-las do arquivo de transcrição que você acabou de criar. Ou, é claro, editar toda a transcrição de acordo com o script real. O colega MVP Jeffery Hicks chegou a escrever um script que analisa as transcrições e as transforma em arquivos PS1 do Windows PowerShell. É possível encontrar esse script em blog.sapien.com/current/2006/11/28/powershell-transcripts.html.

Vejamos agora o cmdlet Get-WMIObject: A sua sintaxe, conforme a lista na ajuda interna do Windows PowerShell, dá uma dica sobre seus recursos ignorados:
Get-WmiObject [-class] <string> [[-property] <string[]>] [-namespace <string>] [-computerName <string[]>] [-filter <string>] [-credential <PSCredential>] [<CommonParameters>]
Um erro comum que os novos usuários do Windows PowerShell cometerão é a emissão de um comando WMI como este:
Gwmi Win32_NTLogEvent –comp Server2
Esse comando recuperará as entradas do log de eventos de Server2 – todas elas. Server2 demorará para processar e transmitir essa tarefa, e também levará um certo tempo até que o Windows PowerShell faça alguma coisa de utilidade com uma coleção tão grande.
Uma abordagem melhor é fazer com que Server2 encontre e envie os eventos nos quais você está realmente interessado. É claro que você poderia fazer isso com uma consulta de linguagem WQL. Alguns consideram essa sintaxe de consulta difícil, mas o Windows PowerShell permite que você especifique apenas a parte da filtragem de uma consulta WQL, usando o parâmetro –filter:
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Isso recuperará todos os eventos – de qualquer log – com a identificação do evento 1024. Observe que os critérios do filtro usam = como operador de comparação, e não o operador –eq do Windows PowerShell. Isso porque, como o filtro está sendo passado ao serviço WMI do computador remoto para processamento, os critérios precisam estar na sintaxe da WMI, e não na sintaxe do Windows PowerShell.
Na verdade, há um parâmetro –filter em outros cmdlets como, por exemplo, Get-ChildItem, o cmdlet por trás de aliases como Dir e Ls. Na maioria dos casos, o parâmetro –filter passa os critérios do filtro diretamente para a tecnologia subjacente, resultando naquilo que eu gosto de chamar de filtragem da origem, que é normalmente mais rápida do que trazer todos os objetos e executá-los por meio do cmdlet Where-Object para filtrar aqueles indesejados.

Cmdlets despercebidos
Certamente, esta abordagem diária de estudo dos cmdlets lhe ajudará a compreender melhor aqueles que você imaginava já conhecer. Mas um outro bom motivo para ter um calendário com o cmdlet do dia é evitar deixar completamente despercebidos cmdlets que você talvez jamais descobrisse. Um dos meus favoritos e que muitos deixam de usar é Resolve-Path. Dado um caminho curinga, ele retornará uma coleção de nomes de arquivo e pasta correspondentes ao caminho. Ele é semelhante ao cmdlet Get-ChildItem (ou seja, os aliases Dir ou Ls conhecidos), mas em vez de retornar todos os objetos de arquivo e pasta, ele retorna cadeias de caracteres simples que podem ser orientados a outros cmdlets para filtragens ou processamentos posteriores. O uso dele é bem simples:
Resolve-Path C:\P*
Essa linha simples retornará caminhos como, por exemplo, C:\Arquivos de Programas, C:\Processes.txt, etc. A Figura 3 mostra dois exemplos desse cmdlet em uso.
Figure 3 Using the handy, though overlooked, Resolve-Path cmdlet
Figure 3 Using the handy, though overlooked, Resolve-Path cmdlet

Começar do começo
Quando você estiver pronto para dar início à experiência do cmdlet do dia, execute Gcm, um alias de Get-Command. Você terá uma lista de todos os cmdlets conhecidos pelo Windows PowerShell, inclusive aqueles adicionados por meio de snap-ins como, por exemplo, o Shell de Gerenciamento do Exchange Server 2007, as Extensões de Comunidade do PowerShell etc. Basta escolher o primeiro da lista – o meu foi Add-Content – e ler sua ajuda:
Help Add-Content –full
Como desejará a ajuda completa – e não a ajuda padrão mais concisa –, você poderá obter uma descrição completa do que cada parâmetro faz, ver alguns exemplos do uso do cmdlet e descobrir outras informações detalhadas. Pare uns 5 ou 10 minutos para testar o cmdlet. (Talvez você queira usar uma máquina virtual para não ficar colocando o seu ambiente de produção em jogo.) Recomendo que você reserve uns 10 minutos por semana – e mais ou menos o mesmo tempo diariamente, para que isso se torne um hábito. Não demorará muito para que você tenha uma compreensão avançada de toda a funcionalidade e recursos que o Windows PowerShell tem a oferecer.

Don Jones é o guru de scripts da SAPIEN Technologies e co-autor do Windows PowerShell: TFM (SAPIEN Press, 2007). Para entrar em contato com ele, visite www.ScriptingAnswers.com.


 Ei, Equipe de Scripts!: O retorno do WinRM
Ei, Equipe de Scripts!
O retorno do WinRM
The Microsoft Scripting Guys

Quando a Equipe de Scripts se propôs a criar uma série de duas partes sobre o Windows® Remote Management (WinRM), uma questão importante nos saltou aos olhos: segurança. Afinal, nós da Equipe de Scripts sabíamos muito bem dos problemas relacionados ao lançamento do capítulo final da série Harry Potter: exemplares previamente reservados foram enviados acidentalmente com antecedência e entregues antes da data do lançamento oficial do livro. (Isso se tornou um problema? Não, claro que não; a editora apenas pediu para que as pessoas não lessem o livro até a data de lançamento.)
E não chegamos à metade da história. O livro e o desfecho da série vazaram muito antes dos exemplares estarem disponíveis. (Se você não leu o livro ainda, eis o que acontece: no final, Harry Potter é, na verdade, um tipo de mágico ou coisa parecida!) Da mesma forma, cópias digitalizadas de todas as páginas foram disponibilizadas instantaneamente na Internet e, em alguns casos, até mesmo antes da autora J. K. Rowling escrevê-las. De uma forma geral, isso foi uma amostra da ruína da segurança, e a Equipe de Scripts estava decidida a não deixar isso acontecer com ela. Afinal, se as pessoas estavam tão determinadas a vazar o final da série Harry Potter, imagine até onde elas poderiam ir para conseguir ter em mãos o desfecho da série de duas partes da Equipe de Scripts sobre o WinRM.
Felizmente, a Equipe de Scripts conseguiu ser hábil e manter seus segredos, quer dizer, segredo. Tudo bem, isso aconteceu principalmente pelo fato de que ela realmente não escreveu a segunda parte desta série até bem depois do prazo final para o envio do artigo. Mas, espere lá, o responsável da Equipe de Scripts que escreve esta coluna estava em férias durante o mês de agosto e, surpreendentemente, ao contrário de uma grande porcentagem de funcionários da Microsoft, ele sequer olha, tampouco usa, um computador quanto está em férias.
Certo, então: ele raramente olha ou sequer usa um computador, mesmo quando não está em férias. Mas essa é outra história.
Cada um à sua medida, sabemos que muitos de vocês não conseguiram dormir durante as últimas quatro semanas, se debatendo e com a preocupação de como a saga do WinRM terminará. Bem, a boa notícia é que essas longas semanas de agonia e de insônia acabaram. Aqui, em primeiríssima mão, está a emocionante conclusão da série de duas partes da Equipe de Scripts sobre o WinRM. Bem, na verdade, está tudo lá, na Figura 1.
Figure 1 The denouement (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation") Set objSession = objWRM.CreateSession("http://" & strComputer)

strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL" strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*" strFilter = "Select Name, DisplayName From Win32_Service Where State = 'Running'"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

    Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

    Set objElement = objXMLDoc.documentElement Wscript.Echo "Name: " & objElement.ChildNodes(0).ChildNodes(0).NodeValue Wscript.Echo "Display Name: " &  objElement.ChildNodes(1).ChildNodes(0).NodeValue Wscript.Echo Loop
Sim, já sabemos: a impressionante reviravolta deu calafrios também na gente. objElement.ChildNodes(0).ChildNodes(0).NodeValue! E quem sabia disso? É claro: é porque, como parte do nosso bloqueio de segurança, até mesmo a Equipe de Scripts não fazia idéia de como a série acabaria. Mas agora o segredo já foi revelado.
Antes de irmos adiante, devemos recapitular rapidamente a série como um todo, apenas caso haja alguém que, inexplicavelmente, deixou de ler a Parte 1 (que pode ser encontrada em technetmagazine.com/issues/2007/11/HeyScriptingGuy). Voltando à Parte 1, nós apresentamos o WinRM, uma nova tecnologia, encontrada no Windows Server® 2003 R2, no Windows Vista® e no Windows Server 2008, que simplifica muito o gerenciamento de computadores na Internet, mesmo por meio de firewalls. Tudo bem, o WMI (Instrumentação de Gerenciamento do Windows) sempre contou com a capacidade de gerenciar computadores remotamente; no entanto, o WMI depende do Distributed COM (DCOM) como tecnologia de gerenciamento remoto. Tudo bem, exceto pelo fato de que, por padrão, muitos firewalls bloqueiam o tráfego DCOM. É verdade ser possível abrir as portas apropriadas e permitir o tráfego DCOM, mas muitos administradores de rede relutam em fazer isso; sua principal preocupação é que a abertura para DCOM também abrirá, simultaneamente, a porta para todos os tipos de dano mal-intencionado.
Por isso, o WinRM, é "a implantação da Microsoft do protocolo WS-Management, um protocolo padrão baseado em SOAP que permite a interoperabilidade entre hardwares e sistemas operacionais de diferentes fornecedores". Na verdade, trata-se apenas de uma forma mais elaborada de dizer que agora é possível realizar o gerenciamento remoto usando protocolos de Internet padrão como HTTP e HTTPS.
Como observamos no mês passado, o WinRM facilita a conexão e a recuperação das informações do WMI de computadores remotos. Então isso quer dizer se tratar de uma tecnologia absolutamente perfeita? Bem, não, não exatamente. Como dissemos, quando o WinRM envia os dados novamente para o script de chamada, eles retornam em formato XML. Nem é preciso dizer que XML pode ser um pouco confuso de analisar e usar, especialmente para administradores do sistema com pouca experiência nessa área. Por isso, o WinRM acompanha uma transformação XSL que converte os dados retornados em um formato mais legível.
Isso é ótimo, exceto por isso também significar que a saída sempre será mais ou menos assim:
Win32_Service AcceptPause = false AcceptStop = true Caption = User Profile Service CheckPoint = 0 CreationClassName = Win32_Service
Não se trata de algo necessariamente ruim, exceção feita ao fato de também significar que a saída será sempre gravada na janela de comando; por padrão, não é possível salvar prontamente os dados em um arquivo de texto, gravá-los em um banco de dados ou em uma planilha do Microsoft® Excel®, ou ainda fazer muita coisa com os dados senão exibir as informações na tela. Isso ainda não está bom.
Além de tudo, o problema é exacerbado caso você opte por retornar apenas um número selecionado de propriedades de uma classe do WMI (algo que você pode fazer para ajudar a reduzir o tráfego de rede). Ao trabalhar com apenas algumas propriedades de uma classe – e não todas elas – você obtém uma saída semelhante a esta:
XmlFragment DisplayName = Nome do log de eventos do Windows = EventLog

XmlFragment DisplayName = Nome do sistema de eventos do COM+ = EventSystem
Interessante, mas não a mais estética forma de exibição das informações que já vimos (especialmente o título XmlFragment exibido em todo o relatório).
E o que você pode fazer a respeito? Escrever códigos personalizados para analisar e formatar esses dados XML? Isso não parece ser algo que um criador de scripts para a administração do sistema deva fazer. Ou parece?

Se quiser que algo seja feito corretamente, faça você mesmo
Acontece que trabalhar com os dados XML brutos retornados pelo WinRM não é uma tarefa tão árdua quanto possa parecer. Neste mês, mostraremos a você uma forma simples de analisar e formatar dados XML. A abordagem que usaremos não é, de maneira nenhuma, a única forma de trabalho com XML, mas tudo bem; o nosso principal objetivo aqui é apenas demonstrar que você não precisa depender da transformação XSLT. Uma vez compreendida a idéia básica, bem, daí em diante o céu é o limite em relação ao que você pode fazer com os dados do WinRM.
Há um pequeno detalhe aqui: para que a coluna caiba no espaço destinado a ela, nós ignoraremos grande parte do script que acabamos de lhe mostrar na Figura 1. No entanto, isso não deve significar um grande problema, porque os dois primeiros terços do script foram descritos detalhadamente na coluna do mês passado. Na verdade, nos atentaremos para o terceiro terço do script, a parte em que efetivamente trabalhamos com os dados retornados.
Como você pode ver, este episódio das Crônicas do WinRM se dá depois que nós criamos uma instância do objeto WSMan.Automation, consultamos um computador remoto (no caso, atl-fs-01.fabrikam.com) e recebemos informações sobre todos os serviços em execução no computador. Isso nos traz de volta à linha no script em que configuramos um loop Do Until para leitura e processamento dos dados XML retornados; esse loop continuará até que não haja nada a ser lido e processado. (Ou, para deixar claro que sabemos do que estamos falando, o loop continuará até o momento em que a propriedade AtEndOfStream do arquivo XML for True.)
Esta é a linha de código de que falamos, e é onde a história deste mês começa:
Do Until objResponse.AtEndOfStream
Dentro do loop, a primeira coisa que fazemos é usar o método ReadItem para ler a primeira seção dos dados XML retornados. (Como estamos trabalhando com o WinRM e recuperando as informações do serviço, a primeira seção consistirá em todos os dados retornados referentes ao primeiro serviço da nossa coleção.) Depois de armazenar esses dados (que, mais uma vez, estão no formato XML) em uma variável chamada strXML, criamos uma instância do objeto Microsoft.XMLDom. Dessa forma, isso nos dá um documento XML em branco com o qual podemos trabalhar:
Set objXMLDoc = _ CreateObject("Microsoft.XMLDom")
Assim que o nosso documento em branco estiver pronto, definimos o valor da propriedade Async como False e chamamos o método loadXML.
O que nos traz a – o que foi mesmo que você disse? Por que definimos o valor da propriedade Async como False? E por que chamamos o método loadXML? Boas perguntas; se tivéssemos pensado nelas sozinhos!
Para os iniciantes, a propriedade Async indica se o script permite um download assíncrono das informações XML. Se essa propriedade for True, o download começará e o controle retornará imediatamente para o script, mesmo que o download não tenha terminado. Tudo bem, isso parece ser ótimo. Mas, infelizmente, o script continuará como se tivesse todas as informações necessárias. E caso ele não tenha todas as informações de que precisa, bem, aí é melhor você se preparar para os problemas. É por isso que definimos o valor da propriedade Async como False.
Observação: certo, você poderia escrever um código para monitorar periodicamente o status do download, o que garante que o script não seja encerrado de maneira prematura. Isso funciona, mas uma abordagem muito mais simples é definir o valor da propriedade Async como False. Quando você faz isso, o script permanece bloqueado até a conclusão do download; em outras palavras, assim que o download começar, o script aguardará pacientemente a sua conclusão antes de fazer qualquer outra coisa.
Já em relação ao método loadXML, ele basicamente faz o que o nome sugere: carrega um documento XML bem formado (ou fragmento de documento) no nosso documento em branco. Tudo o que temos de fazer é chamar o método loadXML, passando a variável strXML como sendo o único parâmetro do método:
objXMLDoc.loadXML(strXML)
O resultado líquido? Agora nós transformamos os nossos dados do WinRM em um documento XML virtual. E isso significa que podemos começar a usar métodos XML padrão para analisar esse documento virtual.
Para isso, precisamos usar a seguinte linha de código a fim de criar uma referência de objeto para o elemento raiz no arquivo XML:
Set objElement = objXMLDoc.documentElement
Neste ponto, estamos prontos para alguma diversão. (Considerando, é claro, que a sua idéia de diversão seja de análise de um arquivo XML. É certamente isso o que nós da Equipe de Scripts consideramos divertido.)
Como você deve se lembrar, a nossa consulta WQL (WMI Query Language) (ou, usando a tecnologia WinRM, o nosso Filter) é semelhante à seguinte:
strFilter = "Select Name, DisplayName " & _ "From Win32_Service Where State = 'Running'"
Como você pode ver, solicitamos duas propriedades da classe Win32_Service: Name e DisplayName. (Também incluímos uma cláusula Where que limita os nossos dados retornados aos serviços em execução. No entanto, não há nada com o que devemos nos preocupar aqui.) É importante o fato de termos solicitado duas propriedades? A ordem dessa solicitação é importante? Talvez. E como deveríamos saber disso?
Ah, bem observado. Talvez, por sermos os autores deste artigo, nós realmente devêssemos saber as respostas para essas perguntas. Tudo bem. Acontece que sabemos que a resposta para essas duas perguntas é sim. É importante o fato de termos solicitado duas propriedades em nossa consulta WQL? Sim, é; afinal, esses serão os únicos valores de propriedade retornados para nós. (Ao contrário de fazer uma consulta Select * From, que retorna valores para todas as propriedades de uma classe.)
Então a ordem dessas duas propriedades também é importante? Pode apostar que sim. A ordem em que especificamos os nomes de propriedade é a mesma na qual os valores de propriedade são retornados. Isso é importante porque todos os valores de propriedade serão retornados como um nó filho (ou seção) do nosso elemento raiz. Qual será o valor de propriedade a retornar como sendo o primeiro nó filho? Esta é uma pergunta fácil. Nesse caso, o primeiro nó filho será a propriedade Name, porque essa é a primeira propriedade listada em nossa consulta WQL. Qual será a propriedade a retornar como sendo o segundo nó filho? Certo, será a propriedade DisplayName, por se tratar do segundo item listado em nossa consulta.
Espere um pouco. Você chegou a essa conclusão sozinho ou alguém vazou uma cópia desta coluna em primeira mão para você? Hmmmm...
De qualquer forma, isso simplifica a recuperação do valor da propriedade Name. Tudo o que precisamos fazer é referenciar NodeValue do primeiro item (item 0) na primeira coleção ChildNodes (item 0), assim:
Wscript.Echo "Name: " & _ objElement.ChildNodes(0).ChildNodes(0).NodeValue
E como referenciamos o valor da propriedade DisplayName? Nesse caso, referenciamos o NodeValue do primeiro item na segunda coleção ChildNodes (item 1):
Wscript.Echo "Display Name: " & _ objElement.ChildNodes(1).ChildNodes(0).NodeValue
E se tivéssemos uma terceira propriedade (digamos, Status) em nossa consulta WQL? Nesse caso, simplesmente referenciaríamos o NodeValue do primeiro item na terceira coleção ChildNodes (item 2):
Wscript.Echo "Status: " & _ objElement.ChildNodes(2).ChildNodes(0).NodeValue
E assim por diante até você chegar à última propriedade.
E como ficará a saída do nosso script agora? Algo parecido com:
Display Name: Nome do log de eventos do Windows: EventLog

Display Name: Nome do sistema de eventos do COM+: EventSystem
Tudo bem, isso não parece ser tão diferente em relação à saída do WinRM padrão (muito embora tenhamos conseguido nos livrar daquele título XmlFragment tolo). A diferença é: trabalhando com os valores de propriedade individuais, nós não estamos mais limitados à formatação padrão (observe que usamos o rótulo Display Name, e não DisplayName), nem restritos à exibição das informações apenas na janela de comando.
Mas você acharia melhor gravar esses dados em uma planilha do Excel? Isso é fácil de fazer. Para começar, insira o seguinte bloco de código (que cria e configura uma nova planilha do Excel) logo após a linha no script do WinRM que chama o método Enumerate:
Set objExcel = _ CreateObject("Excel.Application") objExcel.Visible = True Set objWorkbook = objExcel.Workbooks.Add() Set objWorksheet = objWorkbook.Worksheets(1)

i = 2 objWorksheet.Cells(1,1) = "Name" objWorksheet.Cells(1,2) = "Display Name"
Agora substitua o loop Do Until original pelo exibido na Figura 2. Faça uma tentativa e veja o que acontece.
Figure 2 New Do Until loop (Close Figure 2)
Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

  Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

  Set objElement = objXMLDoc.documentElement objExcel.Cells(i, 1) = objElement.ChildNodes(0).ChildNodes(0).NodeValue objExcel.Cells(i, 2) = objElement.ChildNodes(1).ChildNodes(0).NodeValue i = i + 1 Loop

WinRM, Parte 3?
Entre as colunas deste mês e do mês passado, você viu o bastante para começar a usar o WinRM. Esperamos que sim; o WinRM é uma nova tecnologia intrigante que promete tornar o gerenciamento remoto dos computadores muito mais fácil (ao mesmo tempo em que mantém a segurança). O que, é claro, nos remete diretamente à pergunta que está na cabeça de todos: isso quer dizer que haverá um terceiro capítulo da saga sobre o WinRM?
Desculpem, mas não podemos revelar essa informação. Não por conta de preocupações com a segurança, mas apenas devido ao processo de tomada de decisão e de planejamento habituais da Equipe de Scripts, não temos a menor idéia se escreveremos mais alguma coisa sobre o WinRM. Como dizem por aí, fique ligado!
O desafio do script do Dr. Scripto
Houve um pequeno acidente com o Doctor Scripto. Ele deixou um de seus scripts por aí (em vez de guardá-lo em um bom criador de scripts), e tropeçou por acidente sobre ele, mandando pedaços do script pelos ares. Ele conseguiu encontrar todas as variáveis, palavras-chave, símbolos e, assim, os colocou em ordem alfabética, mas agora precisa reuni-los novamente para recriar todo o script. Vai demorar um pouco, mas ele espera ter a resposta pronta quando a TechNet Magazine do próximo mês for lançada. Enquanto isso, sinta-se à vontade para fazer uma tentativa e ver se você consegue transformar esse conjunto aparentemente aleatório de scripts em um script completo. Boa sorte!
Dica: certo, aqui está uma pequena ajuda. O script final excluirá todos os arquivos do computador local que tiverem uma data posterior à especificada.

O desafio do script do Dr. Scripto
Resposta: o atarefado Doctor Scripto, dezembro de 2007
Sim, o Dr. Scripto conseguiu reunir novamente seu script. Aqui está o script reconstruído, funcional, que exclui todos os arquivos do computador local que tiverem uma data posterior à especificada:
strDate = "20060102000000.000000+000"

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
    Wscript.Echo objFile.Name
Next

The Microsoft Scripting Guys trabalha para a — bem, é empregada da — Microsoft. Quando não está jogando/treinando/assistindo beisebol (e diversas outras atividades), ela administra o Script Center da TechNet. Confira no site www.scriptingguys.com.


 Security Watch: Diretivas de senha de dom&#237;nio do Windows
Security Watch
Diretivas de senha de domínio do Windows
Derek Melber

Caso seja um administrador de um domínio do Windows, você já conhece bem as restrições relacionadas às diretivas de senha para contas de usuário do domínio. Mas com o advento do Windows Server 2008, algumas dessas limitações desaparecerão. Vejamos como o novo sistema operacional resolve um problema: a impossibilidade de implementação de várias diretivas de senha.
Caso esteja executando qualquer versão do domínio do Windows® atualmente (Windows NT®, Windows 2000 Active Directory® ou Windows Server® 2003 Active Directory), você está limitado a uma única diretiva de senha por domínio. Na realidade, não é apenas a diretiva de senha que o limita, mas também o maior escopo das configurações nas Diretivas de Conta. A Figura 1 mostra essas diretivas e configurações.
Figure 1 Account policies (Close Figure 1)

Diretiva de senha
Impor histórico de senhas
Tempo de vida máximo da senha
Tempo de vida mínimo da senha
Comprimento mínimo da senha
A senha deve satisfazer a requisitos de complexidade
Armazenar senhas usando criptografia reversível
Diretiva de Bloqueio de Conta
Duração do bloqueio de conta
Limite de bloqueio de conta
Zerar contador de bloqueios de conta após...
Diretiva do Kerberos
Aplicar restrições ao logon do usuário
Tempo de vida máximo para o tíquete de serviço
Tempo de vida máximo para o tíquete de usuário
Tempo de vida máximo para a renovação do tíquete de usuário
Tolerância máxima para a sincronização do relógio do computador
Por padrão, essas configurações da diretiva se aplicam a todas as contas de domínio e de usuário associadas a domínios. Isso acontece por conta da forma de herança da Diretiva de Grupo em toda a estrutura do Active Directory. Para entender melhor como essas diretivas afetam as contas de usuário locais e de domínio, é importante saber onde as diretivas são definidas e como a herança da Diretiva de Grupo afeta todas as diferentes contas de usuário. (Observe que as configurações da diretiva Kerberos só se aplicam a contas de usuário do domínio, já que elas são as únicas a usar Kerberos na autenticação. Já as contas de usuário locais usam NTLMv2, NTLM ou LM na autenticação.)

Configurando diretivas de conta
Dentro do Active Directory, a Diretiva de Grupo estabelece e controla as Diretivas de Conta para todo o domínio. Isso ocorre na instalação inicial do domínio do Active Directory, sendo realizado com um GPO (Objeto de Diretiva de Grupo) padrão vinculado ao nó do domínio no Active Directory. Esse GPO, chamado de Diretiva de Domínio Padrão, tem configurações padrão para todas as três seções das Diretivas de Conta. A Figura 2 mostra uma lista abrangente das configurações iniciais dos itens da Diretiva de Senha em um domínio do Windows Server 2003.
Figure 2 Default password policies for Windows Server 2003 domain
Figure 2 Default password policies for Windows Server 2003 domain
As configurações nesse GPO controlam as diretivas de todas as contas de usuário do domínio, bem como de todos os computadores do domínio. É importante lembrar que todos os computadores do domínio (desktops e servidores) têm um SAM (Gerente de Contas de Segurança) local. É esse SAM o controlado pelas configurações no GPO padrão. É claro que os SAMs locais também têm contas de usuário locais do respectivo computador.
As configurações na Diretiva de Domínio Padrão afetam todos os computadores do domínio em meio à herança normal dos GPOs na estrutura do Active Directory. Como esse GPO está vinculado ao nó do domínio, todas as contas do computador no domínio serão afetadas por ele.

O que não é possível fazer sem as diretivas de senha atuais
Várias concepções equivocadas relativas aos controles de senha cercam a implementação atual do Active Directory (no Windows Server 2003), apesar dos anos de testes rigorosos e de jamais haver uma evidência que comprovasse a veracidade dessas concepções. Está claro, ou deveria estar, que a diretiva não funcionará de maneira diferente da que foi projetada.
Dito isso, muitos administradores acreditam ser possível ter várias diretivas de rede para os usuários no mesmo domínio. Eles acham que você pode criar um GPO e vinculá-lo a uma OU (unidade organizacional). A idéia é mover as contas de usuário para a OU de forma que o GPO afete os objetos. Dentro do GPO, as Diretivas de Conta são modificadas para criar uma Diretiva de Senha mais segura, talvez configurando o comprimento máximo da senha em 14 caracteres. Mas, por vários motivos, essa configuração jamais proporcionará o resultado desejado. Primeiro, as configurações da Diretiva de Senha baseiam-se no computador, e não no usuário. Com essa base para as configurações, elas jamais afetarão uma conta de usuário. Segundo, a única forma de modificar as configurações da diretiva de uma conta de usuário do domínio é dentro de um GPO vinculado ao domínio. Os GPOs vinculados à OU configurados para alterar as configurações da Diretiva de Conta modificarão o SAM local dos computadores que residem na OU ou que estejam nos sub-OUs da OU vinculada.
Uma segunda concepção equivocada dá conta de que as configurações das Diretivas de Conta estabelecidas no domínio raiz (o domínio inicial da floresta do Active Directory) serão repassadas ou herdadas até os domínios filho da floresta. Novamente, esse não é o caso e você não pode deixar as configurações funcionarem dessa maneira. Os GPOs vinculados ao domínio e as OUs dentro de um domínio não afetarão os objetos em outro domínio, mesmo que o domínio em que o GPO está vinculado não seja o domínio raiz. O único método para que as configurações do GPO incluam objetos em domínios diferentes é vinculando GPOs aos sites do Active Directory.

O que é armazenado para as senhas
Como acabamos de ver, as versões atuais do Windows lidam com as senhas de conta do usuário de maneira bastante simples. Isso inclui um único conjunto de regras de senha para todas as contas de domínio, bem como o gerenciamento das Diretivas de Conta por meio de um GPO vinculado ao nó do domínio no Active Directory. Tudo isso fica para trás quando falamos do Windows Server 2008.
O Windows Server 2008 e a infra-estrutura do Active Directory que o acompanha usam uma abordagem diferente. Em vez de manter as Diretivas de Conta em um GPO, que permitia a configuração de apenas uma diretiva para todas as contas de usuário do domínio, agora as configurações passaram para uma parte mais avançada do Active Directory. Além disso, as Diretivas de Conta não se baseiam mais nas contas do computador. Agora é possível direcionar para usuários individuais e grupos de usuários o controle das restrições de suas senhas. Trata-se de um conceito radicalmente novo para os administradores do Windows, na medida em que lidamos com diretivas de contas do computador há muito tempo.

Diretivas de conta dentro do Windows Server 2008
No Windows Server 2008, você não estabelecerá Diretivas de Conta usando a Diretiva de Domínio Padrão. Na verdade, você não usará nenhuma GPO na criação de Diretivas de Conta para contas de usuário do domínio. No Windows Server 2008, você será direcionado para o banco de dados do Active Directory a fim de fazer suas modificações. Mais especificamente, você usará uma ferramenta como ADSIEdit para modificar o objeto do Active Directory e seus atributos associados.
O motivo dessa alteração é que a Diretiva de Grupo não foi projetada para várias senhas dentro do mesmo domínio. A implementação do recurso de várias senhas por domínio no Windows Server 2008 é elegante, mas nem um pouco amigável como todos gostariam que fosse. Porém, com o tempo, o acesso à interface para definir as configurações ficará mais fácil. Por ora, você precisa colocar a sua cartola feita para o banco de dados do Active Directory para poder inserir as alterações no sistema.
Você não precisa usar ADSIEdit para modificar as configurações da diretiva de conta, caso prefira fazê-lo de uma forma diferente. É possível usar qualquer outra ferramenta de edição LDAP capaz de explorar o banco de dados do Active Directory, ou até mesmo de script. Ao implementar as diretivas de senha no Windows Server 2008, você precisará usar uma abordagem muito diferente da que havia à disposição no passado. Os novos recursos permitem que você considere quais usuários e grupos receberão quais configurações de senha.
Você deve considerar não apenas o comprimento da senha, mas também as restrições adicionais que acompanham as configurações da Diretiva de Senha, inclusive as durações mínima e máxima, o histórico etc. Outras preocupações incluem a forma de controle das configurações de diretiva de bloqueio do usuário e as configurações Kerberos. Há uma relação um-para-um entre as configurações atuais da Diretiva de Conta e as definidas no banco de dados do Active Directory no Windows Server 2008. No entanto, é importante observar que os nomes de cada configuração de diretiva são diferentes agora que se tratam de objetos e atributos do Active Directory.
Para implementar as novas configurações de senha, você deve criar um PSO (objeto Configuração de Senha) chamado msDS-PasswordSettings no contêiner Configuração de Senha, que tem o caminho LDAP de "cn=Password Settings,cn=System,dc=domainname,dc=com". Observe que o nível funcional do domínio no qual você está trabalhando deve ser definido como Windows Server 2008. Nesse objeto, você especificará as informações referentes a vários atributos, como mostra a Figura 3.
Figure 3 Password attributes in Active Directory (Close Figure 3)

Nome do atributo do Active Directory | Descrição do atributo
msDS-PasswordSettingsPrecedence | Estabelece o que tem precedência em situações nas quais um usuário é associado de vários grupos com diretivas de senha diferentes.
msDS-PasswordReversibleEncryptionEnabled | Alterna caso a criptografia reversível esteja habilitada.
msDS-PasswordHistoryLength | Determina quantas senhas intermediárias devem ser únicas antes que uma delas possa ser reutilizada.
msDS-PasswordComplexityEnabled | Estabelece o número e o tipo de caracteres necessários em uma senha.
msDS-MinimumPasswordLength | Estabelece o comprimento mínimo de uma senha.
msDS-MinimumPasswordAge | Determina por quanto tempo um usuário deve utilizar uma senha antes de alterá-la.
msDS-MaximumPasswordAge | Determina por quanto tempo um usuário pode utilizar uma senha antes de ser solicitada sua alteração.
msDS-LockoutThreshold | Determina quantas tentativas de senha malsucedidas serão permitidas antes do bloqueio da conta do usuário.
msDS-LockoutObservationWindow | Determina o tempo após o qual o contador de senhas incorretas será zerado.
msDS-LockoutDuration | Determina por quanto tempo a conta será bloqueada após muitas tentativas de senha malsucedidas.
Como você pode ver, todas as configurações da Diretiva de Grupo relacionadas às configurações da Diretiva de Conta são duplicadas como atributos. Observe que também existe uma configuração de precedência; isso é essencial à implementação de várias senhas no mesmo domínio, uma vez que certamente surgirão conflitos, e um mecanismo para lidar com eles deve estar em vigor.

Direcionando configurações da diretiva de conta
Para cada objeto criado, você precisará preencher todos os atributos a fim de adaptar a Diretiva de Conta a cada usuário. Existe um novo atributo, msDS-PSOAppliesTo, que determina os objetos que receberão o conjunto de configurações da diretiva. Trata-se do atributo-chave que lhe permite direcionar configurações específicas para determinados usuários. A lista nesse atributo pode ser de usuários ou de grupos, mas assim como acontece com qualquer coisa em meio à definição de uma lista de controle de acesso, é melhor usar grupos em lugar de usuários. Os grupos são mais estáveis, mais visíveis e costumam ser muito fáceis de lidar.

Levanta e aplauda
Durante anos, nós quisemos usar várias senhas dentro do mesmo domínio do Active Directory, e agora podemos. Cada usuário em todo o domínio não precisará mais estar no mesmo nível de segurança quando chegar às senhas. Agora, por exemplo, você poderá ter usuários normais com uma senha de 8 caracteres e profissionais de TI (que podem ter privilégios de Administrador) com uma senha mais complexa, de 14 caracteres.
Levará algum tempo para nos acostumarmos a acessar o banco de dados do Active Directory para estabelecer ou modificar as configurações da Diretiva de Conta. No entanto, felizmente, você já está familiarizado com a nova aparência das configurações. Não se esqueça de explorar essas novas configurações assim que tiver o Windows Server 2008 em mãos, uma vez que elas certamente estarão entre os primeiros conjuntos de configurações que você fará.

Derek Melber, MCSE, CISM, MVP, é consultor e instrutor independente. Ele ensina e divulga a tecnologia Microsoft, concentrando-se no Active Directory, na Diretiva de Grupo, na Segurança e gerenciamento de desktop. Derek é autor de vários livros de TI, inclusive Microsoft Windows Group Policy Guide (Guia da Diretiva de Grupo do Microsoft Windows; Microsoft Press, 2005). Você pode entrar em contato com ele pelo email derekm@braincore.net.


 Os arquivos da &#225;rea de trabalho: Implantando o Windows em um mundo virtual
Os arquivos da área de trabalho
Implantando o Windows em um mundo virtual
Wes Miller

A computação virtual está em todos os lugares. Se você ainda não está aproveitando as suas vantagens, deveria estar. A virtualização reduz a dependência do hardware ao criar, essencialmente, sua própria camada de abstração de hardware e ao permitir que você mova um ou mais sistemas convidados, como os sistemas operacionais Windows Server ou o cliente do Windows, entre os sistemas host.
É claro que a virtualização é diferente da emulação, já que ela não imita o processador do convidado. Ela simplesmente representa os recursos do sistema host de uma forma que os sistemas convidados possam acessá-lo. Como resultado, os sistemas host são genéricos para os convidados. Geralmente você pode mover um convidado virtual de um sistema criado por um OEM para um criado por outro OEM — o hardware do host normalmente não importa. Mas é preciso fazer algumas advertências. Por exemplo, se você mover um convidado do hardware com um processador de um fornecedor de CPU, como a AMD, para outro, como a Intel, poderá ter problemas (dependendo da tecnologia de virtualização utilizada). Isso acontece porque a tecnologia de computação virtual só passa informações de um host para o convidado e vice-versa; ela não emula uma CPU específica para o convidado (como faz, por exemplo, o Microsoft® Virtual PC executado em um Macintosh baseado em PowerPC herdado).
No entanto, a virtualização emula componentes fundamentais de hardware para o convidado. Quase sempre isso está limitado à rede, vídeo (geralmente um dispositivo bastante limitado sem uma GPU emulada avançada) e armazenamento em massa. Isso abrange todas as funções ao apresentar um ou mais tipos de dispositivos emulados por software para o convidado. Agora, se você lê a minha coluna há algum tempo, observará que é a mesma lista de dispositivos considerada pelo Windows® PE. Na virtualização, esses são os mesmos tipos de dispositivos que você precisa ter para que o Windows realmente funcione. Adicionalmente, todas as tecnologias de virtualização devem emular um BIOS. Embora também possam emular a EFI (Extensible Firmware Interface), a seleção limitada de sistemas operacionais baseados em EFI de hoje faz com que essa característica tenha um uso limitado. Toda essa emulação permite que os convidados virtuais sejam reinicializados. O BIOS e cada um dos dispositivos emulam um dispositivo real em software e o apresentam aos convidados. Isso significa que eles exigem os mesmos drivers (nem sempre os drivers fornecidos pelo Windows) que o dispositivo real exigiria. Esse é um conceito importante que você deve ter em mente.
Embora algumas tecnologias de virtualização também permitam que dispositivos USB (ou USB 2.0) façam interface com eles, não mergulharei em seus aspectos particulares aqui. Além dos dispositivos USB que exigem outros drivers (impressoras, placas sem fio USB e assim por diante) ou certo suporte a DirectX® (que geralmente não está presente na maioria das tecnologias de virtualização), não há muito que fazer para que tudo funcione. Tenha em mente que o suporte para USB e outros dispositivos não emulados depende, é claro, da tecnologia de virtualização utilizada. Certifique-se de que você conhece as limitações (as pontas afiadas, como gosto de dizer) do produto de virtualização que está usando antes de tentar fazer com que novos dispositivos funcionem com ele.
Hoje, existem dois fornecedores principais de tecnologia de virtualização para Windows: a Microsoft e a VMware (vmware.com). Também existem outros fornecedores promissores, como a Parallels (parallels.com).
Agora que você tem uma idéia do que é a virtualização, vou passar o resto desta coluna explicando como configurá-la, como evitar as armadilhas mais comuns e como implantá-la em algumas máquinas do seu ambiente.

Implantação virtual
A implantação de sistemas virtuais não precisa ser diferente da implantação de sistemas físicos. Mas como você verá, existem alguns bons motivos para ser diferente.
Nos primórdios do Windows NT®, você tinha que implantar via configuração. Você podia criar um script, mas tinha de passar por todo o processo. Após a conclusão da configuração, a cópia dessa imagem para vários sistemas, embora fosse um conceito bastante útil, simplesmente não era suportado.
Entretanto, eventualmente, a Microsoft decidiu que fazia sentido oferecer suporte a sistemas Windows NT em discos duplicados ou "clonados". Assim, hoje, todos os métodos disponíveis para a implantação de sistemas físicos também estão disponíveis para a implantação de sistemas virtuais. Você pode usar: o Winnt32 (ou setup.exe no caso do Windows Vista® e do Windows Server® 2008); o Windows PE (1.x ou 2.x, dependendo do cliente que está sendo implantado, como explicado em minhas colunas anteriores); o RIS (Serviços de Instalação Remota), o WDS (Serviços de Implantação do Windows) ou o Sysprep (a ferramenta Preparação do Sistema para implantação apresentada no Windows NT 4.0) e a sua tecnologia de duplicação de discos favorita (o ImageX, por exemplo).
Mas é claro que você só terá de fazer isso na primeira vez em que implantar um sistema operacional específico. Depois disso, talvez você só queira copiá-lo. Mas há um problema com os métodos de duplicação baseados em disco como os que acabei de mencionar.

Usando o Sysprep
A decisão original da Microsoft de não oferecer suporte à duplicação baseada em disco foi estimulada principalmente pelo SID (Identificador de Segurança do Windows NT). Felizmente, o Sysprep oferece uma solução. Mas primeiro vamos examinar o problema que ele resolve. Como discutido em support.microsoft.com/kb/314828, o SID consiste em um número de revisão de estrutura de SID (normalmente um Identificador Global Exclusivo, ou GUID) que identifica um computador individual baseado em Windows. Esse ID é usado como a raiz do identificador para todas as contas locais. As contas locais possuem seu próprio identificador exclusivo, chamado de RID (Identificador Relativo). O RID consiste em um ID de conta concatenado no final do SID. Assim, a combinação dos dois se torna o identificador de contas locais.
Vamos ver porque isso é um problema ao usarmos o SID de Administrador S-1-5-21-191058668-193157475-1542849698-500. Aqui, S-1-5 é o descritor que define que esse é um SID (o S é onipresente na representação textual do SID) e que 1 e 5 representam o número de revisão do SID do Windows NT e o valor do identificador de autoridade (aqui, a Segurança do Windows), respectivamente. O resto é o SID real, incluindo o número 500, que o identifica como um SID reconhecido — o da conta Administrador do Windows. A conta Administrador é criada por padrão (e que não pode ser excluída) em todas as instalações do Windows e possui um SID que termina em 500. As contas de usuários locais adicionadas ao Windows após a instalação iniciam a iteração a partir de 1000.
O PSGetSID, disponível no Windows Sysinternals (mencionado em minha coluna sobre PSTools, em technetmagazine.com/issues/2007/03/DesktopFiles), permite que você enumere um SID para um determinado usuário em um sistema ou o SID do sistema. Consulte a Figura 1 para ver a saída de PSGetSID para o SID do meu sistema virtual e o SID da minha conta de usuário, 1003.
Figure 1 Output of PSGetSID for a virtual system's SID and the SID of user account 1003
Figure 1 Output of PSGetSID for a virtual system's SID and the SID of user account 1003
Uma vez que os RIDS de contas locais se baseiam nesse SID, o problema que acontece quando você duplica um sistema em disco ou simplesmente copia uma imagem de máquina virtual deve se tornar relativamente aparente. Ao não alterar o SID (a principal tarefa do Sysprep, embora não seja a única), você poderia terminar com uma cópia do componente principal que torna um sistema Windows exclusivo. Se o Sistema A e o Sistema B tiverem o mesmo SID de Administrador, os usuários em cada um dos sistemas poderiam se identificar de forma legítima como o mesmo usuário. O mesmo seria verdadeiro para todas as contas locais do Sistema B quando se autenticassem no Sistema A e vice-versa. Pior, esses sistemas teriam o mesmo SID quando apresentados no Active Directory®. Dessa forma, se você permitir que o Sistema A se autentique em um recurso do domínio, mas não permitir que o Sistema B faça isso, acarretará uma colisão. Se você definir que B deve ser negado, então A também será negado.
Portanto, é fundamental que você regenere os SIDs em sistemas que utilizam o Sysprep — especialmente em cenários de sistemas virtuais, uma vez que as imagens de sistema podem ser propagadas com muita facilidade. Além disso, não utilize uma ferramenta de alteração de SID de terceiros — somente o Sysprep. O Sysprep foi projetado, testado e suportado pela Microsoft para a preparação de sistemas para duplicação (até mesmo os sistemas virtuais). Consulte a Figura 2 para obter um exemplo da aparência do Sysprep antes da alteração do SID em um sistema. Mantenha sempre a opção "Não regenerar os identificadores de segurança" desmarcada se estiver preparando o sistema para duplicação como sua próxima etapa.
Figure 2 "Don't regenerate security identifiers" should be unchecked when preparing for duplication
Figure 2 "Don't regenerate security identifiers" should be unchecked when preparing for duplication
Além da atualização do SID para um novo ID, o Sysprep também modifica os armazenamentos de dados privados que reconhece para refletir o SID e o nome da máquina ou para alterar sua criptografia para que ela funcione com o novo SID. Alguns exemplos são os armazenamentos de dados e os valores das Tarefas Agendadas da Metabase do IIS (caso o IIS esteja instalado).
O Sysprep também exclui obrigatoriamente todas as NICs do sistema e leva com ele os dados de configuração de rede das placas. Como a configuração de rede "se destaca" da NIC no registro, e o relacionamento dessa NIC se baseia em seu ID de Hardware (que fora de uma passagem de sistema virtual para virtual é freqüentemente corrompido), o Sysprep limpa esses dados tradicionalmente abandonados.
O Sysprep também limpa todas as informações de associação ao Active Directory de um sistema. Como resultado, ele deve forçar a remoção de um sistema do domínio como parte de seu trabalho. Isso garante que os sistemas que acabaram de receber novos SIDs possam ser associados ao domínio com segurança. Alguns utilitários que alteram o SID permitem que você mude o SID de uma máquina sem removê-la do domínio, mas isso não é confiável nem seguro. Se for imprescindível que você execute o Sysprep em uma máquina membro de um domínio, remova-o do domínio antes da execução ou execute-o e deixe que ele cuide dessa tarefa para você.
Em uma situação parecida, se você estiver virtualizando qualquer um dos seus controladores de domínio (DCs), precisará duplicar sistemas que sejam simplesmente servidores autônomos que ainda não foram promovidos a controlador de domínio e que ainda não se associaram ao domínio. Com a exceção do Windows Server 2003 Small Business Server Edition, não é possível duplicar um controlador de domínio em disco com segurança. Para criar novos controladores de domínio com segurança, crie uma imagem em disco de um servidor que esteja pronto para se associar ao domínio e para ser promovido a controlador de domínio. O Sysprep (exceto na instância SBS, bastante especializada, que é uma floresta única/servidor único) não sabe como alterar SIDs em um controlador de domínio com segurança.
Por fim, além da alteração do SID e da remoção da máquina do domínio, o Sysprep também altera o nome da máquina.
Pode parecer tirânico dizer que você precisa executar todas as etapas anteriores durante a criação de imagens (ou até mesmo durante a cópia) de sistemas virtuais. Mas é fundamental — especialmente se você estiver usando esses sistemas em uma rede com outros sistemas físicos ou virtuais, em um domínio ou em qualquer outra cópia deles na rede.
Se você não utilizar o Sysprep na duplicação de sistemas virtuais, certamente encontrará alguns dos problemas óbvios (colisões no Active Directory ou de rede) e outros tantos que talvez sejam inesperados. Por exemplo, as suas imagens virtuais são muito suscetíveis a ataques de hackers, já que o acesso a elas garante o acesso às outras.

Os drivers e as camadas de abstração de hardware
Eu mencionei que os dispositivos virtuais incluídos em uma imagem virtual podem não ter drivers "nativos" para o Windows. Verifique se você possui drivers úteis para os seus dispositivos quando estiver implantando (ou quando estiver implantando imagens de disco usando o Sysprep), já que o temido erro 0x0000007B de driver pode aparecer facilmente durante a mudança de uma imagem virtual de um driver de barramento de armazenamento para outro da mesma forma como quando trabalhamos com hardware físico. O mesmo se aplica às NICs. Embora a maioria dos produtos de virtualização tenham conseguido oferecer um dispositivo virtual quase universal, talvez você ainda precise de um driver adicional para ele.
Também não é possível ignorar aquela incômoda HAL (camada de abstração de hardware). Teoricamente, você deseja criar as suas máquinas virtuais para que suportem multiprocessadores ACPI (interface de energia e configuração avançada) (consulte intel.com/technology/iapc/acpi), se é para isso que a sua tecnologia de virtualização oferece suporte. A conversão entre HALs geralmente não é suportada (consulte support.microsoft.com/kb/309283 para obter mais informações específicas). No entanto, algumas tecnologias de virtualização — ou, mais importante, muitas tecnologias de migração — prometem que podem mover com segurança uma instalação do Windows não ACPI para uma instalação ACPI ou vice-versa. Isso não é verdade e a instalação do Windows resultante não será suportada pela Microsoft quando e se você encontrar problemas. As mesmas limitações discutidas na página da Web de suporte que acabei de mencionar são verdadeiras para os sistemas virtualizados. Consulte a Figura 3 para obter um exemplo da HAL no Gerenciador de Dispositivos em uma de minhas máquinas virtuais — nesse caso, executada com a HAL do uniprocessador ACPI. Para não ser confundido com um único processador, ele é intercambiável com sua família de multiprocessadores.
Figure 3 HAL in Device Manager on a virtual machine
Figure 3 HAL in Device Manager on a virtual machine

Alterações diversas
Mude o que você pode e aceite o que não puder mudar
Quando estiver considerando a migração do físico para o virtual e vice-versa, você precisa se lembrar daquilo que pode ou não mudar. Você pode alterar os seguintes aspectos de uma instalação do Windows:
  • A HAL (mas somente do uniprocessador para o multiprocessador ou vice-versa, desde que eles se baseiem na mesma configuração de energia).
  • Os controladores de armazenamento em massa (isso não é fácil —mas a maioria das soluções de migração física para virtual já tenta fazer isso por conta própria). Observe que a maioria dos fornecedores oferece uma solução de armazenamento IDE e uma SCSI. Escolha com sabedoria durante a implantação, já que mudar de uma para outra não é muito fácil. Geralmente, escolher a SCSI resulta em um dispositivo mais confiável (esse é o caso das implementações de emulação de dispositivos SCSI da maioria dos fornecedores).
  • O controlador de rede (embora isso geralmente seja igual para as tecnologias de um fornecedor em um cenário de migração virtual para virtual).
Você não pode alterar os seguintes aspectos de uma instalação do Windows:
  • A HAL (exceto no caso mencionado anteriormente, quando for usada a mesma configuração de energia). Você não deve supor que uma solução de migração que faz isso resultará em uma instalação do Windows estável ou confiável (e, mais importante, ela não será suportada pela Microsoft).

Além da alteração do SID e do nome da máquina, você também precisa alterar certos valores que podem ser específicos da tecnologia de computação virtual utilizada. Em particular, você precisa alterar o endereço MAC (a identificação exclusiva para dispositivos de rede). E mais, muitos aplicativos virtuais também possuem seu próprio identificador exclusivo. A maioria os armazena em seus próprios arquivos de configuração das máquinas e, portanto, você vai querer saber como manipular essas entradas (e manter a sua validade). Observe que muitos produtos de virtualização que oferecem suporte a PXE (Pre-Boot Execution Environment) têm o UUID do SMBIOS baseado em sua própria identificação exclusiva — enfatizando a necessidade de alterá-lo (ou deixar que o software de virtualização se encarregue disso, se houver suporte) caso você esteja se associando a um domínio; caso contrário, o gerenciamento de sistemas WDS ou de clientes RIS pode se tornar impossível (se houver conflitos de GUID). A maioria das soluções de virtualização com que trabalhei pode ter graves problemas de rede se existirem endereços MAC duplicados; dessa forma, se você não está simplesmente movendo uma máquina virtual, é muito importante que altere o endereço MAC caso o software de virtualização não faça isso em seu lugar.
Outros componentes que devem ser considerados na preparação de um sistema virtual para implantação são quaisquer discos ou instantâneos vinculados. Dependendo da sua solução de virtualização, eles também podem ser chamados de discos diferenciais ou por outro nome. Mas se você executar o Sysprep para preparar um sistema e se tiver instantâneos (ou outro estado reversível) que funcione com o sistema virtual, eles deverão ser destruídos para que a imagem permaneça segura, confiável e protegida quando for duplicada. No caso de um instantâneo ou de outra abordagem da tecnologia "desfazer alterações de disco", a reversão de um instantâneo poderia significar voltar ao ponto onde mais de um sistema que foi gerado a partir da máquina virtual original agora está em conflito com outra (ou até mesmo com o sistema original, caso ele seja ligado novamente). Assim, execute o Sysprep em quaisquer instantâneos ou relacionamentos de discos diferenciais.

Otimização
A maioria das tecnologias de virtualização inclui adições de máquinas virtuais ou ferramentas que ajudarão a aperfeiçoar o desempenho e a experiência de interação entre o convidado e o host. Isso normalmente inclui a otimização da entrada de mouse e de teclado, entre outros aprimoramentos de desempenho, e quase sempre inclui a interação avançada de copiar e colar (ou outra interação do host para o convidado). Instale a versão mais recente dessas ferramentas em seus sistemas virtuais antes da implantação.
Você também precisa garantir que a memória do cliente seja configurada de forma ideal para o sistema operacional convidado, mas também no contexto com os hosts em que será implantada. Afinal, a última coisa que você deseja é implantar uma imagem do Windows XP definida para usar 1 GB de RAM em sistemas host que não possuem tanta memória assim.
Lembre-se também das limitações da maioria das tecnologias virtuais de hoje — é importante para os seus usuários a forma de interação com os periféricos conectados ao sistema virtual assim como quais aplicativos funcionarão ou não no sistema operacional convidado (a maioria não oferece suporte ao DirectX 9 ou 10, por exemplo, ou oferece suporte a versões mais antigas de forma limitada). Os usuários podem não saber o que isso significa ou como se manifesta (alguns aplicativos não lidam muito bem com falhas).

Preocupações com o host
Observe que, em geral, não há muito com que se preocupar em relação ao PC host que está executando a tecnologia de virtualização, a despeito do que está sendo executado seja um sistema operacional completo ou um Hypervisor de tipo 1 executado diretamente sobre o hardware. A maioria das tecnologias de virtualização foi projetada para garantir que o sistema operacional convidado não precisasse saber nada (ou muito pouco) sobre o host. No entanto, é preciso saber que hosts estão sendo usados, caso um convidado movido de um host para outro tenha problemas. Verifique também se você conhece as limitações do produto do seu fornecedor de virtualização em certas plataformas. Embora você possa ser capaz de mudar de um para outro, talvez perca ou ganhe certos recursos do Hypervisor de tipo 2 do sistema operacional do host (o aplicativo de virtualização) no processo.

Outros mecanismos de implantação
Links sobre o Sysprep relacionados
Os documentos a seguir oferecem muita ajuda sobre o Sysprep:
  • Projetando instalações baseadas em imagem com o Sysprep
  • Como usar a ferramenta Sysprep para automatizar uma implantação do Windows XP
  • Como usar a Ferramenta de Preparação do Sistema (Sysprep.exe) para executar a duplicação de discos
  • Usando a Ferramenta de Preparação do Sistema em computadores diferentes

A utilização do Sysprep ou a duplicação de disco (ou simplesmente a execução do Sysprep e a cópia da máquina virtual) são opções óbvias para a implantação de sistemas virtuais, mas existem outras. Na verdade, se forem usadas imagens ou a configuração, a utilização do Windows PE pode ser mais fácil com a virtualização do que com máquinas físicas, já que você estará trabalhando com arquivos ISO em vez de um CD físico. Observe que algumas tecnologias de virtualização não lidam bem com mídia de DVD e, portanto, não se esqueça de verificar se há suporte do fornecedor de virtualização. Você pode usar o winnt32 ou o setup.exe (no caso do Windows Vista ou do Windows Server 2008), mas não há quaisquer vantagens específicas. Se você usar outras tecnologias de implantação da Microsoft, como o Automated Deployment Services, a sua tecnologia de virtualização oferecerá suporte ao PXE para iniciar uma implantação baseada em rede como se RIS ou WDS estivessem sendo utilizados.

Migração
Por fim, além da migração real de um PC completo, não se esqueça da USMT (Ferramenta de Migração de Perfil do Usuário). A USMT permite que você mova as configurações de um usuário de um cliente físico para um novo sistema virtual com facilidade. Dessa forma, se os seus usuários quiserem migrar seus dados e configurações antigos para uma nova máquina virtual, você pode, por exemplo, obter com facilidade os arquivos e as configurações do Windows XP, armazená-los em um UNC e enviá-los para uma nova máquina virtual.

Wes Miller mora em Austin, no Texas. Já trabalhou na Winternals Software, em Austin, e na Microsoft, como gerente de programas e gerente de produtos do Windows. Entre em contato com ele pelo email technet@getwired.com.


 Anota&#231;&#245;es de campo: O futuro fung&#237;vel
Anotações de campo
O futuro fungível
Romi Mahajan

O filósofo e economista Karl Marx escreveu em um de seus tratados que "tudo o que é sólido se dissolve no ar", fazendo referência às relações mutáveis entre categoriais sociais trazidas pelo surgimento da industrialização e do capitalismo na Europa do século 19. Essa noção poderosa, de que as divisões e categorias nunca se cristalizam totalmente, se mostra de muitas formas e contextos, não só no mundo da tecnologia — um mundo em que a única constante é a mudança.
Nesse setor que se movimenta com rapidez, não há um exemplo melhor de velocidade de mudança (e do desafio que enfrentamos por causa dela) do que o surgimento da tecnologia orientada ao consumidor. Na verdade, a TI se tornou "consumível" e os principais indicadores de mudança recaem diretamente no mundo do pessoal, com efeitos enormes sobre os negócios e sobre a vida. Esse fenômeno apresenta inúmeras formas:
  1. O mundo Web 2.0 está relacionado à Internet de leitura/escrita; escrever na Internet está intimamente ligado à função do escritor como consumidor.
  2. Os aplicativos e tecnologias de consumidor estão criando um efeito de "halo" para os negócios.
  3. A principal estrutura da Internet tem sido planejada e testada para o consumo de TI.
  4. Formações de TI como suporte técnico devem planejar, lidar e aprender com as linhas turvas da distinção entre as tecnologias para uso doméstico e para uso nos negócios.
  5. As pessoas tomam decisões e elas são tão consumidores como são profissionais.
  6. A tecnologia "favorita" de uma pessoa é quase sempre um produto para consumidor e não um produto de negócios.
As implicações são profundas e as categorias são intercambiáveis, como você pode perceber a partir de alguns poucos exemplos. Um amigo que trabalha em uma empresa de tecnologia me disse que 8% de todas as chamadas de suporte técnico de sua empresa estavam relacionadas a atualizações do iTunes. O white paper da Cisco, "A era do exabyte", parte de dois pontos — que a Internet não está entrando em colapso sob o peso do fluxo contínuo de vídeo e que o YouTube é somente o começo. A Apple Corporation tinha quase 10% do mercado de varejo de laptops no mês de março de 2007, de acordo com um relatório do NDP Group — o efeito de halo do iPod no trabalho. A Microsoft está investindo intensamente em áreas como jogos, música, fotografia digital e hospedagem de vídeos. E, por fim, as empresas fazem reuniões no Second Life.
Além disso, marcas de tecnologia têm sido elevadas e generalizadas até o ar rarefeito da permanência. As pessoas procuram tudo no "Google", todos falam sobre iPods, precisam entrar no "myspace" e jogam no "Xbox®". Uma conexão emocional foi criada entre as pessoas e suas tecnologias e o efeito dessa conexão funciona de forma provisória do escritório para casa, de volta ao escritório e então em relação às empresas que criam esses dispositivos, aplicativos, sites e comunidades. À medida que criamos percepções — boas, ruins ou neutras — elas viverão conosco tanto em nossa encarnação pessoal como na profissional.
O que é relevante para um indivíduo é, portanto, um assunto complexo. E uma mudança de cultura fundamental será necessária caso as empresas não vençam o desafio simultâneo de dimensionar suas mensagens, mostrando um relacionamento próximo e um cuidado com seus clientes. Antigamente, antes da profunda especialização das funções, as mensagens genéricas eram a substância do marketing. Nos últimos anos, ao contrário, as mensagens "focadas" se alastraram, possibilitando a precisão como a do laser contra categorias como título da função, segmento de mercado, tamanho da empresa e tecnologias específicas. No entanto, perdeu-se o fato de que tudo o que é sólido se dissolve no ar e que atraente para as pessoas em suas encarnações pessoal/consumidora é a forma — a única forma — de criar uma conexão e ter um desempenho melhor.
Ser fungível significa ser intercambiável e não possuir grandes distinções entre categorias. Em outras palavras, não podemos mais erguer muros entre as nossas noções de consumidores e de tecnologias de negócios. O consumo de TI chegou e o futuro é verdadeiramente fungível.

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


 Segredos do Windows: Um joystick n&#227;o precisa ser um microondas
Segredos do Windows
Um joystick não precisa ser um microondas
Raymond Chen

Recentemente, eu estava lendo uma postagem feita em um blog por um colega meu, o Audio Fool, e me lembrei de um erro que cometi há muitos anos e que continuava a me incomodar. Quando a interface do joystick com force feedback DirectInput® estava sendo desenvolvida, os fabricantes de joysticks foram convidados a uma visita aos escritórios da Microsoft em Redmond, estado de Washington, para discutir os detalhes da interface proposta e oferecer alguns comentários.
Muitos problemas foram discutidos durante essas reuniões, mas o que ficou gravado em minha mente foi uma desavença sobre as forças periódicas, se devem ser expressas como um período ou como uma freqüência. Um dos fornecedores presentes estava criando uma confusão porque sua empresa já tinha escrito um driver que especificava suas forças periódicas em termos de freqüência e ele não queria ter de mudar isso. Considerando que essa era uma reunião para a discussão dos detalhes de uma interface novíssima, como qualquer fornecedor poderia esperar deixar o recinto sem ter de fazer qualquer alteração em seu driver?
Mas esse fornecedor reclamou tanto que nós finalmente desistimos e concordamos em usar freqüência em vez de período na especificação da taxa de forças periódicas. Afinal, isso não importava muito. Uma força com uma freqüência de 10 oscilações por segundo é igual a uma força com um período de um décimo de segundo. Período e freqüência são apenas o inverso uma da outra.
Ops, isso não é totalmente verdadeiro. O período é expresso em milissegundos, o que oferece um intervalo dinâmico de 1 ms para uma tonalidade em 50 dias. Um período de 50 dias é imperceptível em uma escala de tempo humano e um período de 1 ms é tão rápido que não é nem registrado como um fenômeno periódico — em vez disso, é percebido como um tom musical.
Por outro lado, a freqüência é expressa em hertz, o que oferece um intervalo dinâmico de 1 Hz para 4 bilhões de ciclos por segundo. Você acha que é estranho reproduzir música com o seu joystick? Imagine gerar forças cujo intervalo suba até a banda de freqüência de microondas!
O problema é que o poder expressivo praticamente inútil do topo do intervalo da freqüência veio às custas da extremidade inferior. Acontece que simuladores de vôo são grandes fãs de forças periódicas com períodos comparativamente longos. Eu não conheço a física por trás disso, mas me disseram que um dos efeitos com que os pilotos têm de lidar é uma força periódica lenta sobre o controle na ordem de alguns minutos. O avião tem uma tendência natural de viajar em uma curva senóide vertical muito lenta e os pilotos precisam tomar medidas para neutralizar essa tendência para manter o vôo nivelado. Se a taxa da força fosse expressa por seu período, o programa simulador de vôo poderia especificar um período de 120.000 milissegundos. No entanto, como freqüência, isso seria 0,0083 hertz, que é bem mais lento do que a menor freqüência que pode ser expressa na interface do driver — ou seja, 1 Hz. Portanto, a força mais lenta que um simulador de vôo pode solicitar é aquela repetida a cada segundo, o que é bem rápido em relação ao efeito físico que ele deseja imitar.
Já que esse erro continuava a me incomodar após todos esses anos, recentemente examinei a documentação do force feedback. Para a minha surpresa, parece que a estrutura DIPERIODIC usa período em vez de freqüência para expressar efeitos periódicos (e, além disso, utiliza microssegundos, o que significa que agora você pode reproduzir músicas ou pilotar um avião). Ou o problema foi corrigido ou estou ficando senil e a minha memória está pregando peças em mim. De qualquer forma, não preciso mais me preocupar com esse erro — se é que ele aconteceu mesmo.

Raymond Chenpossui um site, The Old New Thing (A velha novidade), e escreveu um livro homônimo (Addison-Wesley, 2007) para tratar da história do Windows e da programação Win32. Esta cor fica ótima em você.