Julho 2008 Julho 2008
IIS: Go-Live com o IIS 7.0
O lançamento do Internet Information Services 7.0 estabelece novos padrões, oferece melhorias fundamentais e traz novos recursos para consolidar os ambientes Web. Explore os aprimoramentos mais importantes e obtenha um guia detalhado para testar, preparar e migrar seus aplicativos Web para o IIS 7.0. Fergus Strachan
Comunicação e colaboração: Planejando a migração para a Unificação de Mensagens
A migração de um sistema de correio de voz herdado para uma plataforma de unificação de mensagens pode ser um processo bastante fácil com pouca interrupção para os usuários finais... contanto que você tenha um bom plano em mãos. Veja o que você precisa saber para planejar a migração, testar os novos sistemas e implementar a unificação de mensagens em sua organização. Jeff Goodwin
Comunicação e colaboração: como a voz reforça o OCS 2007
O Microsoft Office Communication Server traz importantes alterações à telefonia empresarial. Examine como as chamadas de voz são feitas camada por camada, saiba como as chamadas podem ser roteadas para vários pontos de extremidade e explore a importância das conversas em comunicações OCS. Rajesh Ramanathan
Comunicação e colaboração: Crie conexões poderosas com o Groove e o SharePoint
O Microsoft Office Groove e o SharePoint Server fornecem recursos avançados de colaboração. Saiba em que eles diferem e como se complementam, e descubra como integrá-los para fornecer uma solução de colaboração fácil e flexível com suporte aos usuários em diferentes locais. Alan Maddison
Administração do Windows: Introduzindo o cluster de failover do Windows Server 2008
Os usuários reclamavam há anos que o clustering no Windows Server era muito complicado. Com o lançamento do Windows Server 2008, o clustering ganhou uma nova cara. Explore alguns dos avanços mais importantes encontrados no novo Cluster de Failover e veja como essa nova implementação torna os clusters muito mais fáceis de configurar e manter. Chuck Timon
Columns
Do editor: Impressão em papel já era: | Cartas: Com a palavra, os leitores: | Toolbox: Novos produtos para profissionais de TI:
Perguntas e respostas do Exchange: Balanceamento de carga, transporte de borda e mais: Tem dúvidas sobre o Exchange? Nesta edição, respondemos às dúvidas sobre como usar o Exchange com o SharePoint, trabalhar com a replicação contínua em espera, instalar servidores de Caixa de Correio do Exchange 2007 no Windows Server 2008 e mais.Henrik Walther | Utilitário em destaque: Microsoft SharedView: Procurando uma maneira de colaborar rapidamente com alguém localizado em outra cidade? Veja como o Microsoft SharedView, um utilitário gratuito, permite compartilhar com facilidade documentos e telas com membros de um pequeno grupo, mesmo que esteja em outro local.Greg Steen | Explorando o SharePoint: Integrando aplicativos do Office: Saiba como os aplicativos do Microsoft Office integram e se comunicam com o SharePoint e explore maneiras de integrar aplicativos que não sejam da Microsoft ao SharePoint usando os mesmos princípios.Pav Cherny
Windows PowerShell: A caixa de depósito: Don Jones discute as funções de filtragem, o pipeline, objetos personalizados e como a bola de pingue-pongue pode revelar o segredo para entender o Windows PowerShell.Don Jones | Ei, Equipe de Scripts!: Adrenalina pura: A Equipe de Scripts fala sobre scripts cheios de adrenalina e mostra como o novo armazenamento de dados de configuração da inicialização no Windows Vista e Windows Server 2008 pode ser acessado usando scripts.A Equipe de Scripts da Microsoft | Os arquivos da área de trabalho: Inicializando o Windows em rede: Conheça a história do RIS (Serviços de Instalação Remota) e outras tecnologias relacionadas a PXE usadas na Microsoft.Wes Miller
Security Watch: Senhas e cartões de crédito, Parte 1: A primeira edição de uma série de três partes que examina como as práticas comuns e os conselhos relacionados à segurança estão desatualizados e até atrapalham os esforços de segurança.Jesper M. Johansson | Anotações de campo: Garanta a precisão da eleição: Examine as vulnerabilidades do atual sistema eleitoral dos EUA e veja como a criptografia pode ser usada para criar resultados de eleição totalmente verificáveis.Josh Benaloh | Segredos do Windows: A história ganhando espaço: O Microsoft Bob é muito mais difundido do que você imagina. Raymond Chen explica como o Microsoft Bob ganhou a confiança de milhões de pessoas.Raymond Chen


IIS
Go-Live com o IIS 7.0
Fergus Strachan
Visão geral:
  • Implantação do IIS 7.0 em um ambiente de farm da Web
  • Aprimoramentos de segurança e desempenho
  • Migração de aplicativos Web ASP.NET do IIS 6.0 para o IIS 7.0
  • Migração de aplicativos Web PHP para o IIS 7.0

Conteúdo
Preparar, configurar, testar
Minha configuração de teste
Aprimoramentos importantes para administradores de TI
Arquitetura do IIS
Modos clássico e integrado
Módulos e funcionalidade
Migração de aplicativo Web
Conclusão
A equipe do IIS na Microsoft diz que o IIS (Internet Information Services) 7.0 é a maior versão na história do IIS. Essa versão define novos padrões, oferece melhorias fundamentais e
apresenta novos recursos para consolidar ambientes da Web. O IIS 7.0, incluído com o Windows Server® 2008 e Windows Vista® SP1, já capacita o Microsoft.com, e várias empresas de hospedagem da Web já começaram a fornecer hospedagem pelo IIS 7.0 a Web designers e desenvolvedores que desejam conduzir seus aplicativos Web existentes para a nova plataforma de servidor Web.
Neste artigo, irei explorar as principais melhorias do IIS 7.0 mais importantes para profissionais de TI e, em seguida, entrarei em detalhes sobre a migração do ASP.NET e aplicativos Web PHP. Mas, primeiro, quero descrever um laboratório de teste que seja parecido com um ambiente de produção básico.
Essa é uma tarefa importante. Antes de implantar o IIS 7.0 nos seus servidores de produção, você precisa passar um tempo fazendo um teste completo em um ambiente de laboratório para garantir que seus aplicativos Web sejam executados sem problemas no novo servidor Web.

Preparar, configurar, testar
Meu laboratório de teste inclui sistemas que executam o Windows Server 2003 e IIS 6.0, que hospedam aplicativos ASP.NET, bem como servidores que executam a distribuição do Linux Ubuntu 7.10 e Apache HTTP Server 2.2, que hospedam aplicativos Web baseados em PHP. Meu objetivo final é implantar o Windows Server 2008 em sistemas de preparação e produção e, em seguida, fazer a transição de aplicativos Web complexos para substituir instâncias do Apache e o IIS 6.0 pelo IIS 7.0.
Tenho dois aplicativos Web principais: DotNetNuke 4.7 e osCommerce 3.0a4. O DotNetNuke é uma estrutura de aplicativo Web baseada em ASP.NET 2.0 e Microsoft® SQL Server®. O outro aplicativo, osCommerce, é a versão alfa mais recente de uma solução de comércio eletrônico cheia de recursos criada com base em PHP e MySQL. Então, vamos colocar esses aplicativos avançados no IIS 7.0!
Quero deixar claro que não é minha intenção comparar versões de software, produtos ou plataformas. Existem, no entanto, várias vantagens para se padronizar para o Windows Server 2008 e IIS 7.0 que eu devo salientar. Ou seja, a complexidade administrativa é reduzida e você pode minimizar o número total de servidores Web em execução.
A Figura 1 apresenta uma visão geral do laboratório de teste que estou usando para este artigo. Se deseja seguir minhas explicações no seu próprio ambiente de teste, você pode encontrar links para os componentes de software necessários, bem como instruções de instalação detalhadas, passo a passo no material complementar disponível na seção de downloads de códigos no site da TechNet Magazine em .com.
Figura 1 O ambiente de teste para implementar o IIS 7.0 (Clique na imagem para ampliá-la)
Observe que, no momento em que eu estava concluindo este artigo, a Microsoft lançou uma ferramenta de linha de comando (MSDeploy.exe) para suportar a implantação dos clientes, a sincronização e a migração de aplicativos Web para o IIS 6.0 e 7.0. Recomendo que você conheça essa ferramenta. Informações detalhadas podem ser encontradas no blog da equipe de implantação Web da Microsoft em go.microsoft.com/fwlink/?LinkId=118272.

Minha configuração de teste
No momento em que este artigo foi escrito, o Windows Server 2008 ainda estava em pré-lançamento, então, portanto, eu não substituí o Windows Server 2003 em servidores de bancos de dados ou controlador de domínio. Com a versão oficial do Windows Server 2008, convém considerar também a migração da sua infra-estrutura do Active Directory®. Migrar bancos de dados SQL Server® 2005 e MySQL para o SQL Server 2008 também está além do escopo deste artigo.
Eu implantei o SQL Server 2008 no meu servidor de preparação principalmente porque é preciso menos esforço do que para instalar o SQL Server 2005 com Service Pack 2. O DotNetNuke não apresentou problemas ao ser executado com um banco de dados do SQL Server 2008. A instalação do MySQL 5.0 no Windows Server 2008 também foi simples, sem complicações.
Embora o IIS 7.0 esteja disponível em Server Core, eu não usei uma instalação Server Core devido a certos requisitos para o meu teste. Meu servidor de preparação exigia uma instalação completa porque esse foi meu primeiro sistema de teste. Além disso, o Microsoft .NET Framework não está disponível em Server Core.
O PHP é executado bem em Server Core, mas meu objetivo é consolidar aplicativos ASP.NET e PHP, então o Server Core simplesmente não é uma opção. Até que o .NET Framework seja suportado em Server Core, você precisará executar uma instalação completa para suportar aplicativos ASP.NET. Para obter diretrizes passo a passo detalhadas para instalar o ambiente de teste, consulte o arquivo 01_install_testlab.htm no material complementar.
Eu optei por executar uma instalação limpa do Windows Server 2008 (em vez de atualizar servidores existentes). Entre outras coisas, a instalação limpa facilita a implementação de um cenário de migração preparado como o da Figura 2. A estratégia subjacente é manter as farms da Web existentes em execução até que todos os componentes relevantes dos aplicativos Web tenham sido testados com êxito no servidor de preparação e movidos para a nova farm da Web do IIS 7.0.
Figura 2 Preparando a transferência para o IIS 7.0 (Clique na imagem para ampliá-la)
Você pode mover todos os aplicativos Web existentes de uma vez ou gradualmente, dependendo da complexidade do seu ambiente. Para cada aplicativo Web ou site, após executar um teste final de aceitação na nova farm da Web, você pode fazer a transferência alterando registros DNS relevantes para direcionar os navegadores para a nova farm da Web do IIS 7.0. Isso mantém o mínimo de tempo de inatividade e interrupções.

Aprimoramentos importantes para administradores de TI
A MSDN® Magazine possui um excelente artigo de Mike Volodarsky chamado "Explore o servidor Web do Windows Vista e muito mais" (disponível em msdn2.microsoft.com/magazine/cc163453.aspx), que rapidamente chama a sua atenção para que você conheça as melhorias encontradas no IIS 7.0.
Outra boa leitura é uma postagem do blog da equipe do Microsoft.com, chamada "Os pedaços saborosos encontrados na "ração para cachorro" (disponível em go.microsoft.com/fwlink/?LinkId=117436). A postagem resume as experiências iniciais com o IIS 7.0 dos membros da equipe. Em resumo, eles classificaram as principais melhorias como:
  1. Configuração simplificada.
  2. Excelente compatibilidade.
  3. Inexistência de metabase.
  4. Configuração centralizada por meio do arquivo applicationHost.config colocado em um compartilhamento UNC.
  5. Configuração delegada por meio dos arquivos web.config em diretórios de aplicativos
  6. Ferramentas de gerenciamento aprimoradas.
  7. Rastreamento de solicitação com falha.
  8. Filtragem de solicitação sem a necessidade de URLScan.
  9. Disponibilidade de sincronização de conteúdo simplificada por meio de compartilhamentos UNC.
  10. Cache de saída de conteúdo dinâmico.
A configuração simplificada definitivamente está na minha lista. Na postagem do seu blog, a equipe do Microsoft.com demonstra como você pode implantar todos os recursos do IIS 7.0 (ou, é claro, apenas os recursos que desejar) com uma única linha de comando. Eu incorporei ansiosamente essa abordagem nas instruções de configuração do meu laboratório de teste, com a linha de comando exibida na Figura 3.
De fato, esse comando é bem longo. (Se você desejar copiar esse comando, recomendo que você copie e cole-o a partir do site da TechNet Magazine, em vez de redigitá-lo a mão.) Embora esse comando coloque todos os módulos disponíveis no computador do IIS 7.0, ele não inclui PHP. O IIS 7.0 não inclui PHP e a noção de baixar e instalar pacotes Debian pela Internet é um conceito estranho para o Gerenciador de Pacotes do Windows® (pkgmgr.exe). Informe o Kit de Instalação Automatizada (AIK) do Windows.
Figura 3 Implantação dos recursos do IIS 7.0 com uma única linha de comando
start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).
Com o AIK, você pode criar um DVD de instalação personalizado para o Windows Server 2008 que inclua o IIS 7.0 e PHP 5. Você também pode incluir o MySQL, arquivos de aplicativos Web e qualquer outro componente necessário na sua implantação. Todos os componentes podem ser parte da sua Instalação do Windows Server 2008, permitindo que você aplique personalizações de forma consistente em todos os seus servidores Web. Não há a necessidade de linhas de comando ou edição de arquivos de configuração.
Você pode até mesmo criar um DVD personalizado para instalações totalmente autônomas. O AIK inclui documentação e ferramentas para criar um arquivo AutoUnattend.xml, que você, em seguida, coloca na pasta raiz do DVD. O arquivo Custom Image Deployment.htm no material complementar oferece instruções passo a passo.
Vários administradores também concordam que a compatibilidade é uma melhoria-chave. Eu esperava encontrar alguns problemas de compatibilidade com o DotNetNuke e osCommerce, mas a transição para o IIS 7.0 foi bem tranqüila, apesar do fato de que esses dois aplicativos Web incluem recursos avançados, como autenticação de formulário e URLs de mecanismo de pesquisa amigáveis.
Com o DotNetNuke, não encontrei nenhum problema até que passei para um cenário de farm da Web complexo com compartilhamento de conteúdo UNC em uma plataforma de 64 bits. O problema, no entanto, foi pouco relevante. No final das contas, essa compatibilidade aprimorada significa que menos tempo é necessário para colocar seus aplicativos Web em execução no IIS 7.0.
Se, por acaso, você encontrar problemas de compatibilidade com seus aplicativos Web, o diagnóstico interno e o suporte a rastreamento rapidamente se tornarão um dos seus recursos novos favoritos. As informações detalhadas de diagnóstico são muito significativas e os caminhos de solução sugeridos são úteis e realmente funcionam.
A Figura 4 mostra as informações de diagnóstico que você obtém ao executar o DotNetNuke 4.7 no IIS 7.0 no modo integrado. Neste exemplo, existem três opções (exibidas na seção "Coisas que você pode tentar"). Alterar o aplicativo para suportar o modo integrado é provavelmente a melhor escolha para desenvolvedores do DotNetNuke. Ignorar o erro é provavelmente uma má idéia. Eu gosto da terceira opção, habilitar o modo clássico alternando o aplicativo Web para o AppPool clássico do .NET, porque quero executar o DotNetNuke 4.7 inalterado no IIS 7.0.
Figura 4 Informações de diagnóstico para DotNetNuke em execução no modo integrado (Clique na imagem para ampliá-la)

Arquitetura do IIS
Você pode estar pensando o que esses modos integrado e clássico são e por que eles afetam o aplicativo ASP.NET (DotNetNuke), mas não o aplicativo PHP (osCommerce). Para compreender melhor isso, você primeiro deve dar uma olhada na arquitetura do IIS 7.0. Versões anteriores integram o runtime do ASP.NET no servidor Web principal, principalmente por uma extensão ISAPI (aspnet_isapi.dll). O IIS 7.0, por outro lado, permite que módulos ASP.NET se conectem diretamente no servidor Web principal por meio de um módulo HTTP de nível global chamado ManagedEngine, que carrega a DLL de suporte do ASP.NET (webengine.dll) no pipeline de processamento de solicitação do IIS 7.0.
Módulos nativos usam a API de Server Core da Web do IIS para se registrarem em eventos específicos no pipeline, como BeginRequest, AuthenticateRequest, AuthorizeRequest e ExecuteRequestHandler. ManagedEngine fornece o suporte necessário para integrar módulos ASP.NET no pipeline de solicitação também. Com essa nova arquitetura, o IIS 7.0 pode invocar módulos nativos e do ASP.NET em qualquer estágio, durante o processamento da solicitação, independentemente do tipo de conteúdo solicitado.
Como exemplo, vamos considerar a autenticação do usuário do ASP.NET. No IIS 6.0, é possível para um módulo HTTP baseado em ASP.NET se registrar para eventos OnAuthenticate (como FormsAuthentication.OnAuthenticate e WindowsAuthentication.OnAuthenticate) para definir a identidade do usuário no HttpContext atual. Isso funciona muito bem dentro do runtime do ASP.NET, mas você não pode usar esse código do ASP.NET para proteger recursos expostos por meio de um aplicativo Web baseado em PHP.
De acordo com a configuração do seu mapa de script, o IIS 6.0 encaminha solicitações para os tipos de conteúdo do ASP.NET a aspnet_isapi.dll, mas ele não encaminha solicitações para tipos de conteúdo PHP à extensão ISAPI para o ASP.NET. Afinal, o ASP.NET não processa códigos PHP, mas isso também significa que o código de autenticação do ASP.NET não é executado se uma página PHP for solicitada. portanto, com o IIS 6.0, você precisa duplicar a lógica de autenticação porque aplicativos PHP devem implementar seus próprios mecanismos de autenticação.
O IIS 7.0 usa um modelo de processamento acionado por evento que suporta a combinação e a correspondência de módulos individuais no pipeline de solicitação. Entre outros componentes, o IIS 7.0 acompanha módulos gerenciados WindowsAuthentication e FormsAuthentication que geram eventos OnAuthenticate quando o pipeline de solicitação dispara o evento AuthenticateRequest. Você pode agora possuir um módulo nativo, como RequestFilteringModule ou IpRestrictionModule, manipular o evento BeginRequest para recusar solicitações críticas o mais cedo possível e, em seguida, executar código de autenticação do ASP.NET personalizado no evento AuthenticateRequest e fazer com que FastCgiModule execute o mecanismo de script PHP (php-cgi.exe) no evento ExecuteRequestHandler para processar páginas PHP.
O resultado dessa arquitetura integrada é que desenvolvedores da Web não precisam duplicar códigos para implementar uma lógica de negócios comum. Você pode usar código de autenticação do ASP.NET personalizado para proteger todos os seus recursos do IIS, incluindo aplicativos PHP. E você pode executar outras tarefas de pré e pós-processamento por meio de módulos do ASP.NET, como a reconfiguração de URL, o rastreamento personalizado e o log de erros.

Modos clássico e integrado
O efeito colateral causado por essa nova arquitetura é que aplicativos ASP.NET existentes podem requerer alterações de código e configuração que devem ser executadas por desenvolvedores de aplicativos para garantir que as alterações não levem a conflitos de módulos no pipeline de solicitação. Mas, se você não puder conduzir imediatamente um aplicativo Web existente, pode habilitar o modo clássico no pool de aplicativos que o processo de trabalho usa para executar o aplicativo Web. O IIS 7.0 não carrega o ManagedEngine nos processos de trabalho do modo clássico, o que implica, neste caso, que o pipeline de solicitação não pode resolver ou invocar módulos ASP.NET. Em vez disso, o IIS 7.0 ativa um número de manipuladores ISAPI, baseados em IsapiModule (aspnet_isapi.dll), para processar tipos de conteúdo ASP.NET similares ao IIS 6.0. Você poderá ver isso, se analisar a seção de manipuladores em system.webServer no arquivo applicationHost.config, que pode encontrar por padrão na pasta %WinDir%\System32\InetSrv\Config.
Procure a cadeia de caracteres aspx, como exemplo, e você encontrará uma entrada apontando para PageHandlerFactory-Integrated (carregado nos processos de trabalho do pool de aplicativos do modo integrado, de acordo com a configuração preCondition="integratedMode") e outras entradas apontando para PageHandlerFactory-ISAPI-2.0 e PageHandlerFactory-ISAPI-2.0-64 (carregados nos processos de trabalho do pool de aplicativos do modo clássico, de acordo com a configuração preCondition="classicMode").
Como o modo de pipeline está definido no nível do pool de aplicativos, o IIS 7.0 pode executar aplicativos Web nos modos integrado e clássico simultaneamente. E os processos de trabalho apenas precisam ser executados em diferentes pools de aplicativos, mas podem ser hospedados no mesmo servidor.
Tenha em mente que os modos integrado e clássico afetam apenas como o IIS 7.0 integra o ASP.NET no pipeline de solicitação. Esses modos de pipeline não afetam aplicativos PHP diretamente. O FastCgiModule e todos os outros módulos nativos são carregados sem pré-condições do modo pipeline nos modos integrado e clássico. FastCGI é a interface preferida para executar o mecanismo de script PHP no IIS 7.0. Em vez de usar FastCGI, você também pode criar um mapeamento de manipulador para o mecanismo de script PHP por CGI ou pode usar o IsapiModule em conjunto com PHP-ISAPI (php4isapi.dll).
Eu, no entanto, considero essas alternativas de configuração de estilo do IIS 6.0 ultrapassadas, agora que o FastCGI oferece desempenho e estabilidade substancialmente aprimorados. O CGI é mais lento, pois o IIS deve inicializar um novo processo de CGI para cada solicitação de HTTP enquanto o FastCGI reutiliza processos CGI para várias solicitações. O ISAPI requer uma compilação segura para thread, que envolve mais sobrecarga do que executar PHP não seguro para thread.
Talvez, ainda mais importante, nem todas as extensões PHP estejam disponíveis em uma versão segura para thread, e executar extensões não seguras para thread com ISAPI seja uma má idéia porque pode causar problemas de estabilidade no servidor. O FastCGI, por outro lado, é um ambiente de uma única simultaneidade como o CGI. Usado para executar PHP não seguro para thread, o FastCGI é estável e rápido e é claramente a melhor maneira para se usar com PHP 5 no IIS 7.0. Ele também está disponível no IIS 6.0, se você ainda não estiver pronto para uma transição para o IIS 7.0.

Módulos e funcionalidade
O IIS 7.0 apresenta uma arquitetura altamente modularizada — ou, como o desenvolvedor do IIS diz, um conjunto de recursos dividido em componentes. Isso é uma boa notícia para os administradores da Web que desejam manter a superfície da memória e do ataque do IIS 7.0 o menor possível. Habilitando diferentes módulos ou talvez, até mesmo, substituindo módulos padrão por módulos personalizados, você pode obter o controle total sobre os recursos do IIS 7.0 nos seus servidores Web.
Para executar o ASP.NET no modo integrado ou clássico, bem como aplicativos PHP no mesmo servidor, você deve instalar, como mínimo, a função do servidor Web e os módulos principais para suportar o processamento de solicitação, a configuração do servidor, ASP.NET, ISAPI e CGI (que inclui o módulo FastCGI). Isso pode ser feito com a seguinte linha de comando:
start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI
Eu geralmente prefiro instalar o IIS 7.0 com todas as opções disponíveis no meu servidor de preparação para garantir que todos os componentes e ferramentas administrativas estejam disponíveis para colocar meus aplicativos Web em funcionamento rapidamente. Minha estratégia é verificar se as coisas estão funcionando e, então, eu restrinjo a configuração desinstalando serviços de função e desabilitando módulos. Quando um aplicativo Web começa a não funcionar direito, eu adiciono serviços de função de apoio ou módulos que removi.
Você também tem a opção de usar o Gerenciador de Pacotes (pkgmgr.exe) ou a ferramenta de linha de comando do IIS 7.0 (appcmd.exe) ou editar a seção globalModules no arquivo applicationHost.config diretamente, mas eu considero as ferramentas gráficas muito convenientes. Tenha em mente que alguns módulos, como RequestFilteringModule e StaticCompressionModule, são bem úteis, mesmo que não sejam — a rigor — necessários para seus aplicativos Web serem executados. Se você desinstalar um módulo necessário para um pool de aplicativos, você receberá um erro de HTTP ao acessar seu aplicativo Web, como ilustrado na Figura 5.
Figura 5 Um aplicativo ASP.NET não será executado no modo clássico porque IsapiModule está faltando (Clique na imagem para ampliá-la)
Observação: como uma prática recomendada, certifique-se de que o mesmo conjunto de módulos esteja instalado e habilitado em todos os seus servidores do IIS 7.0. Para verificar os componentes instalados, vá para HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ e verifique as chaves do Registro. Um valor REG_DWORD de 0000 0001 para uma chave do Registro, como para NetFxEnvironment ou CGI, indica que o componente correspondente está instalado.

Migração de aplicativo Web
Chega de teoria, agora é hora de arregaçar as mangas e mover alguns aplicativos Web para o IIS 7.0. Como mencionei anteriormente, meu servidor de preparação executa o IIS 7.0 com todos os componentes disponíveis e PHP 5 não seguro para thread registrado com FastCGI. Antes de começar, preciso fazer algumas perguntas básicas:
  • O aplicativo Web requer um sistema de gerenciamento de banco de dados, como SQL Server ou MySQL?
  • Eu preciso instalar ou configurar componentes adicionais, como conexões ODBC, objetos COM ou certificados SSL?
  • O aplicativo Web requer contas de serviço especiais e permissões de acesso remoto ou local elevadas para compartilhamentos de arquivos e outros recursos?
  • Existe alguma dependência de recursos específicos da plataforma indisponíveis no IIS 7.0, como dependências do módulo Apache para reconfiguração de URL (mod_rewrite)?
Fazer perguntas como essas ajudará a colocar seus aplicativos Web em execução no IIS 7.0 mais rapidamente. Por exemplo, se você estiver tentando migrar um aplicativo PHP do Apache 2.2 que usa mod_rewrite (digamos, para um mecanismo de pesquisa amigável ou para impedir o seqüestro de largura de banda por imagens vinculadas), terá problemas até implementar uma solução de reconfiguração de URL personalizada compatível no IIS 7.0. Felizmente, o osCommerce não requer funcionalidade mod_rewrite no IIS 7.0, mas alguns pacotes de otimização de mecanismo de pesquisa podem exigir.
Agora que determinei e instalei os componentes adicionais necessários no servidor de preparação, estou pronto para colocar meus aplicativos Web em funcionamento. Novamente, existem algumas coisas que quero perguntar a mim mesmo:
  • Qual é a configuração mais simples que posso usar para suportar o aplicativo Web?
  • Que configuração é usada atualmente no ambiente de produção?
  • Posso otimizar a configuração do aplicativo Web na nova plataforma?
  • Qual é o conjunto mínimo de serviços de função e módulos que o aplicativo Web precisa para funcionar na configuração desejada?
Colocar o aplicativo Web em execução na configuração mais simples é uma forma rápida de certificar-se de que ele funciona. Se tudo der certo, é hora de aplicar uma configuração similar ao ambiente de produção existente e importar os dados de produção nos bancos de dados de teste. É claro que alguns problemas podem apenas surgir em configurações avançadas.
Você pode notar também oportunidades para melhorias ao fazer o espelhamento da sua configuração de produção em um laboratório de teste. Colocar o arquivo applicationHost.config em um compartilhamento UNC é uma ótima maneira de centralizar a configuração de vários servidores Web. Para aumentar a tolerância a falhas pela redundância e sincronização de conteúdo, considere a implementação de replicação de Sistema de Arquivos Distribuído (DFS), que é um mecanismo de replicação multimestre baseado em estado disponível com o Windows Server 2003 R2 e Windows Server 2008. Você pode também minimizar os requisitos de armazenamento em front-ends da Web colocando os arquivos de conteúdo dos seus aplicativos Web em compartilhamentos UNC.
Outras otimizações possíveis podem envolver segurança ou cache dinâmico. Eu não resolvi otimizações de segurança e desempenho no meu laboratório de teste porque isso está além do escopo deste artigo. Nem configurei DFS para evitar a instalação de mais servidores. As instruções passo a passo no material complementar fornecem um exemplo simplificado de como hospedar o arquivo applicationHost.config e conteúdo da Web em compartilhamentos UNC. E a Figura 6 ilustra como implementar uma farm da Web baseada em UNC com o DFS.
Figura 6 Implantação de farm da Web com arquivo applicationHost.config e conteúdo da Web em compartilhamentos UNC (Clique na imagem para ampliá-la)

Conclusão
O IIS 7.0 é uma plataforma de servidor Web impressionante. Ele apresenta uma arquitetura básica reprojetada, ao mesmo tempo em que mantém aproximadamente 100% de compatibilidade com a versão anterior IIS 6.0. Ele deve poder executar a maioria dos aplicativos Web ASP.NET existentes sem modificação. Mas, devido à extensão das alterações na arquitetura, não é possível supor que você não encontrará problemas de compatibilidade.
Esteja você migrando aplicativos Web ASP.NET ou PHP para o IIS 7.0, é melhor assumir uma abordagem de preparação com ênfase no planejamento adequado, na preparação, nos testes e na documentação de códigos e alterações de configuração.
O IIS 7.0 vale o trabalho envolvido. Existem várias melhorias em áreas como segurança, desempenho, configuração e flexibilidade. Seria necessário um livro todo para discutir todas elas. A configuração centralizada e o compartilhamento de conteúdo com base em compartilhamentos UNC, a configuração delegada por meio de arquivos web.config em diretórios de aplicativos, ferramentas de gerenciamento aprimoradas, informações detalhadas de diagnóstico e rastreamento de solicitação com falha e o cache de saída dinâmico são maneiras certeiras de ganhar os corações dos administradores da Web.
O recurso de combinar módulos nativos e gerenciados no pipeline de processamento de solicitação beneficia os desenvolvedores de ASP.NET. E as melhorias no desempenho e na estabilidade que acompanham o FastCGI no IIS 7.0 são notícias excelentes para desenvolvedores de aplicativos PHP.
E há mais uma coisa importante que ajuda os profissionais de TI a obterem sucesso com o IIS 7.0: o portal da comunidade do IIS da Microsoft (www.iis.net). Ele contém todas as informações de que você precisa, incluindo artigos detalhados sobre a nova arquitetura, código-fonte para desenvolvedores de C++ e ASP.NET, demonstrando como criar módulos do IIS 7.0, e instruções passo a passo para colocar os aplicativos PHP em funcionamento. Você definitivamente irá querer visitar esse site. É uma boa primeira parada para obter respostas para suas perguntas relacionadas ao IIS.

Fergus Strachan é fundador e diretor da Maestra Ltd London, uma firma de consultoria especializada em design de infra-estrutura de TI e suporte a gerenciamento de projetos, que atende bancos internacionais e instituições educacionais do Reino Unido. Ele escreve artigos sobre a tecnologia de servidor da Microsoft e é autor do livro Integrating ISA Server 2006 with Microsoft Exchange 2007 (Integrando o ISA Server 2006 com o Microsoft Exchange 2007). Ele também é co-autor do livro Microsoft Exchange Server 2003 Resource Kit (Kit de Recursos do Microsoft Exchange Server 2003).

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.


Comunicação e colaboração
Planejando a migração para a Unificação de Mensagens
Jeff Goodwin
Visão geral:
  • Um breve histórico da caixa postal
  • Coisas a serem consideradas durante o planejamento da migração
  • Estratégias de migração
  • Desafios multissite

Conteúdo
Um breve histórico da caixa postal
Planejando a migração
Estratégias de migração práticas
Uma migração passo a passo
A importância de seguir um plano
Migrar de um sistema de caixa postal herdado para uma plataforma de unificação de mensagens pode ser um projeto desafiador. Mas com algum planejamento apropriado, é possível realizar essa migração com certa facilidade ao mesmo tempo em que se minimiza qualquer interrupção que os usuários finais possam vir a enfrentar. Na verdade, minimizar a
interrupção do serviço deve provavelmente ser o objetivo principal em meio à execução de um projeto de migração desse tipo.
Para saber em relação ao que você precisa se planejar durante a migração, você deve primeiro compreender por que as empresas consideram a caixa postal um aplicativo de missão crítica. Essas informações básicas ajudarão a compreender quais recursos você precisa implementar ao migrar para a Unificação de Mensagens e por que esses recursos serão importantes para os administradores.

Um breve histórico da caixa postal
Como não é possível planejar realmente como chegar ao destino sem saber por onde começará a jornada, quero retroceder e apresentar uma breve visão geral dos sistemas de caixa postal – tanto de onde eles vêm quanto da forma com que são arquitetados. Existem argumentos sobre quem inventou o primeiro sistema de caixa postal. No entanto, o primeiro sistema de caixa postal disponível comercialmente se chamava VMX, que significava Voice Message Exchange.
O VMX foi projetado originalmente para fornecer uma forma de comunicação por voz com outras pessoas dentro da empresa, assim como o email é usado atualmente. O sistema tinha comandos como, por exemplo, enviar, encaminhar e responder uma mensagem. Quando uma mensagem era esquecida, o usuário era notificado. Havia vários métodos de notificação, inclusive chamadas de saída (ligando para a pessoa em um número de telefone específico) e uma luz de espera de mensagem (uma luz indicadora no telefone da pessoa).
À medida que o VMX continuava ganhando popularidade, as organizações começaram a ligar seus sistemas de caixa postal. Isso proporcionava à empresa uma ampla solução em caixa postal na qual os funcionários podiam enviar mensagens de difusão para listas de distribuição de toda a empresa.
Obviamente, para fornecer uma forma de interação com o sistema de caixa postal, era necessário criar uma TUI (interface de telefone). Essas TUIs variaram com o passar dos anos e, infelizmente, ainda não há nenhuma interface padrão para a caixa postal. Caso tenha caixa postal no seu telefone celular, você provavelmente já se acostumou a ouvir coisas como "aperte 1 para acessar a caixa postal". Mas com os sistemas de caixa postal controlados por voz, que usam VUIs (interfaces de voz), se tornando mais e mais comuns, a própria TUI deixou de ter a importância que costumava ter. No entanto, você não deve subestimar a ligação que os usuários podem ter com uma determinada interface.
Os sistemas de caixa postal corporativos usados atualmente dependem de duas arquiteturas distintas: distribuída e centralizada. Na Figura 1, os escritórios de Seattle, Nova York e Austin contam com uma arquitetura de caixa postal distribuída, na qual os sistemas de caixa postal são colocados em cada um desses locais. Por outro lado, os escritórios de Londres, Paris e Glasgow têm um modelo centralizado, no qual a infra-estrutura PBX permanece integrada e todas as chamadas são encaminhadas para o local central em Londres. Ambos os modelos têm vantagens e desvantagens. Mas observe que, mesmo em um modelo distribuído, os sistemas de caixa postal podem permanecer ligados tendo em vista a entrega de mensagens entre os locais.
Figura 1 Os dois modelos de arquitetura de caixa postal comuns (Clique na imagem para ampliá-la)
Há três razões principais pelas quais uma organização pode optar por usar um modelo distribuído: a necessidade de disponibilidade local, o uso de sistemas PBX diferentes que não podem ser ligados e as restrições do plano de discagem uniforme.
Algumas organizações exigem o sistema de caixa postal para que, em caso de falha na rede, o PBX local e o sistema de caixa postal continuem funcionando normalmente, proporcionando pela funcionalidade do sistema no local. Os sistemas IVR (resposta interativa de voz) continuarão funcionando, e chamadores externos ainda podem deixar mensagens. Dessa forma, não existe impacto algum sobre os usuários finais, e o trabalho continua normalmente. Isso pode parecer familiar – é por essa mesma razão que muitas organizações optam por localizar os servidores com o Microsoft® Exchange Server em execução. A organização talvez queira realizar uma avaliação dos riscos para determinar se essa sustentabilidade localizada é necessária.
Quando uma organização cresce com aquisições, os locais remotos normalmente contam com plataformas PBX que não podem ser ligadas em rede ao restante da infra-estrutura. Nesse caso, as organizações podem substituir o PBX, o que pode ser um projeto caro, ou deixar o local intacto e ligar a plataforma da caixa postal para proporcionar uma troca de mensagens direta. Também há servidores de terceiros disponíveis para ajudar a ligar sistemas de caixa postal diferentes.
Para ligar PBXs, um UDP (plano de discagem uniforme) é obrigatório. Um UDP diz que extensões de telefone e de caixa postal não podem se sobrepor. Na Figura 1, você perceberá que Seattle, Nova York e Austin apresentam intervalos de extensões sobrepostos. Isso porque não existe nenhum UDP para os locais nos Estados Unidos. Um UDP poderia ser criado ampliando-se os intervalos de extensões até 7 ou 10 dígitos, embora isso crie outros problemas.
Talvez você precise alterar os modelos de discagem em cada telefone, alterar todas as extensões do usuário no PBX e alterar todos os aplicativos integrados ao sistema. E isso pode causar a frustração dos funcionários, que agora devem lembrar e discar números de 7 ou 10 dígitos para chamar alguém no corredor.
Embora esses recursos básicos e os desafios arquitetônicos tenham sido aprimorados com o passar dos anos, as noções básicas da caixa postal continuam as mesmas. Troca de mensagens, rede, métodos de notificação, interface do usuário e arquitetura são todos fatores importantes que você deve ter em mente ao planejar uma migração.

Planejando a migração
A Unificação de Mensagens introduz alterações em todas as partes da organização – desde como os usuários interagem com a caixa postal até a maneira com que a arquitetura foi projetada, passando pela forma com que os administradores tratam o gerenciamento. Todas essas diferenças devem ser abordadas quando você migra para um sistema de unificação de mensagens. A seguir está uma lista de verificação das coisas que você deve levar em conta ao planejar a migração.
Sistema de mensagem Qualquer organização que migre de uma plataforma de caixa postal herdada para a Unificação de Mensagens do Exchange deve passar por um período de coexistência. Caso a organização já tenha implantado um sistema de mensagem, um sistema para interoperar sistemas de caixa postal diferentes, basta adicionar o sistema de Unificação de Mensagens à lista dos sistemas existentes. É altamente recomendável o sistema de mensagem para qualquer organização que tenha vários locais com sistemas PBX ou de caixa postal separados.
Infra-estrutura Criar a infra-estrutura da Unificação de Mensagens exigirá que você tome decisões quanto aos requisitos de rede, à integração de telefonia, à colocação do servidor etc. Caso você não esteja familiarizado com estratégias de implantação básicas, leia o meu artigo anterior, "Implantando a Unificação de Mensagens com o Exchange Server 2007" (consulte technet.microsoft.com/magazine/cc137737).
Atendedores automáticos Muitos sistemas contêm vários atendedores automáticos – diferentes para, digamos, o dia, a noite e vários departamentos. Você precisará trabalhar com a equipe de telecomunicação da organização para espelhar os atendedores automáticos nos sistemas de caixa postal herdados.
Indicação de mensagem em espera Talvez você queira que a solução não tenha indicadores de mensagem em espera, mas os usuários certamente pedirão esse recurso. Portanto, não subestime a ligação dos usuários com aquela notificação pela luz vermelha. Felizmente, há várias empresas que desenvolveram aplicativos indicadores de mensagens para o Exchange Server.
Suporte a fax Muitas plataformas de caixa postal herdadas oferecem suporte ao recebimento de fax. Como a Unificação de Mensagens do Exchange também oferece suporte a recursos para o recebimento de fax, você talvez queira planejar oferecer suporte a ele na nova implantação.
Resposta interativa de voz Algumas plataformas de caixa postal herdadas oferecem suporte a aplicativos IVR (resposta interativa de voz) que a Unificação de Mensagens do Exchange não é capaz de duplicar. Você talvez queira deixar esses sistemas in-loco até encontrar uma alternativa melhor.
Administração A Unificação de Mensagens do Exchange depende do Active Directory® e da função de servidor Caixa de Correio do Exchange. Você precisará se planejar quanto à forma com que a administração, os requisitos do sistema etc. serão afetados pela implantação de uma Unificação de Mensagens.
Interface do usuário Ao implantar uma nova interface do usuário, você deve fornecer treinamento para os usuários. Como a Unificação de Mensagens do Exchange emprega uma interface muito semelhante à da maioria dos provedores de telefonia celular, ela deve ser bastante intuitiva para a maior parte dos usuários. Além disso, ela usa reconhecimento de fala, logo, os usuários não precisam usar discagem de tons. No Exchange Server, isso é conhecido como Outlook® Voice Access.
Treinamento A Unificação de Mensagens introduz uma mudança de paradigma na forma como os usuários se comunicam e usam a caixa postal. Além da interface do usuário, você deve fornecer treinamento para os usuários a fim de apresentar as práticas recomendadas e as formas novas, mais eficientes, com as quais poderão se comunicar. Por exemplo, os usuários talvez não saibam como interagir com a caixa postal na caixa de entrada do email ou como configurar algumas definições avançadas da unificação de mensagens.

Estratégias de migração práticas
Existem desafios, sem dúvida, na migração de uma grande organização para uma solução em unificação de mensagens. No entanto, trabalho na unificação da comunicação há 10 anos e já vi até mesmo a mais complexa das organizações, com requisitos muito específicos, ser migrada com êxito.
Independentemente de estar lidando com uma organização de site único ou multissite, ajudará se você criar uma estratégia de migração levando em conta estas cinco etapas básicas:
  1. Planeje e crie a sua solução.
  2. Instale e configure a função de servidor Unificação de Mensagens.
  3. Migre um grupo piloto.
  4. Revise o design com base nos comentários do grupo piloto.
  5. Migre os usuários.
Obviamente, as organizações multissite se deparam com determinados desafios que não costumam ser encontrados em cenários de site único. Abordo esses desafios separadamente na barra lateral "Desafios multissite".
Individualmente, planejar e criar a solução é a etapa mais importante do processo de migração. Recomendo que você atribua uma equipe de Unificação de Mensagens ao projeto. Ela deve incluir representantes de várias partes da organização com experiência em telecomunicações, Active Directory, Exchange, rede, segurança, treinamento e gerenciamento de projetos. Além disso, obtenha um desenho detalhado da arquitetura das infra-estruturas de PBX da empresa, da caixa postal e de email existentes.
Assim que tiver um design, será possível instalar e configurar a função de servidor Unificação de Mensagens. Não tenha receio de instalar um servidor Unificação de Mensagens em paralelo ao sistema de caixa postal herdado existente. Apenas não se esqueça de seguir as práticas recomendadas documentadas.
A esta altura, você está pronto para experimentar o servidor Unificação de Mensagens. Designe e migre um pequeno grupo piloto de usuários para o novo sistema. Um grupo entre 25 e 50 usuários será o bastante. Escolha esses usuários com cuidado, criando um grupo piloto que consista em um grupo variado de usuários, desde das equipes de TI e de telecomunicações até gerentes e a equipe de vendas. Envolvendo essa ampla gama de pessoas, você pode determinar melhor se o design está adequado, quais são os requisitos específicos que precisa levar em conta, qual é o treinamento que pode ser necessário aos usuários etc.
Depois de receber os comentários do grupo piloto, você precisará revisar o design para corrigir todos os problemas revelados durante os testes. Mais especificamente, reveja os itens que abordei na seção "Coisas a serem consideradas" e veja se você corrigiu esses pontos da maneira apropriada para a organização. Observe que as alterações mais comuns feitas aqui se referem ao treinamento.
A etapa final é migrar os usuários. Existem muitas opiniões e estratégias a respeito de como migrar o sistema para plena produção. As duas metodologias principais são uma migração gradual e um desligamento rápido.
Se optar por migrar gradualmente a comunidade de usuários dentro de um período de semanas ou meses, você criará ilhas de caixa postal entre os usuários da Unificação de Mensagens e os herdados. Isso impede que os usuários encaminhem mensagens para outros usando a caixa postal. E se o design não incluir uma solução em sistema de mensagem, você interromperá algumas das comunicações comerciais. Se for fazer isso, recomendo que você não se esqueça de incluir uma solução em sistema de mensagem no design inicial.
Na migração com desligamento rápido, você move todos os usuários em uma só fase. As organizações costumam realizar esse tipo de migração durante um final de semana para que possam ter tempo de testar o sistema, fazer alterações na configuração e reverter a migração caso algum empecilho grave seja encontrado.
Independentemente do método que você escolha, não se esqueça de treinar a equipe de suporte técnico para as perguntas comuns e as respostas obtidas com o grupo piloto. Você também deve ter a certeza da proficiência dos funcionários do suporte técnico na realização de tarefas importantes, inclusive habilitar um usuário, validar se um usuário está habilitado e alterar uma senha.

Uma migração passo a passo
Enquanto percorro a minha migração de exemplo, tenha em mente que o objetivo principal de uma migração bem-sucedida para a Unificação de Mensagens é migrar a caixa postal do usuário de uma plataforma herdada para a Unificação de Mensagens com a menor interrupção possível para os usuários (tanto internos quanto externos).
A Figura 2 detalha a arquitetura de uma organização. Ela não tem planos para alterar essa arquitetura do Exchange mista. Os escritórios com sede nos EUA contam com um data center principal localizado em Seattle. Todos os aplicativos de TI em Austin são atendidos em Seattle, e o escritório de Nova York garante serviços do Exchange localizados. A caixa postal dos locais nos EUA está distribuída por conta da infra-estrutura de PBX diferente. Tecnicamente, a infra-estrutura de PBX não pode ser ligada em rede para proporcionar uma caixa postal centralizada. Já os escritórios com sede na Europa contam com um data center centralizado localizado em Londres. Todos os aplicativos de TI e de telecomunicações na Europa são atendidos nesse data center central.
Figura 2 Arquitetura de exemplo antes da migração (Clique na imagem para ampliá-la)
Toda a infra-estrutura de caixa postal se baseia na plataforma Octel (agora conhecida como Avaya). Todos os sistemas de caixa postal foram ligados usando o OAN (Octel Analog Networking), um protocolo de rede proprietário que usa linhas telefônicas analógicas e chamadas interurbanas para enviar mensagens de caixa postal em rede. Essa arquitetura possibilita um sistema de mensagens de voz em toda a empresa entre os locais.
Desafios multissite
As organizações multissite enfrentam vários desafios ao implantar a Unificação de Mensagens. Felizmente, é possível aprender com alguns dos desafios que outras organizações já enfrentaram. Não posso abordar todos eles neste artigo, mas posso mostrar os desafios mais comuns que já enfrentei durante o trabalho com várias organizações.
"Tenho uma arquitetura do Exchange Server centralizada e um ambiente de telefonia misto."
É fácil de criar um ambiente distribuído. Você coloca um servidor Unificação de Mensagens e o integra ao PBX de cada local. Mas e se você tiver um ambiente centralizado ou mesmo misto? A pergunta que você deve se fazer é se precisa da sustentabilidade da Unificação de Mensagens no local. Com a sustentabilidade da Unificação de Mensagens local, essa localização pode perder a conexão com o servidor do Exchange centralizado e, ainda assim, fornecer a funcionalidade de atendedor automático e permitir que chamadores externos (bem possivelmente clientes) deixem mensagens. A resposta provavelmente dependerá da importância desse local e da possibilidade de gerenciamento que a solução terá.
Caso você precise de sustentabilidade local, um servidor Unificação de Mensagens remoto no local pode ser uma boa opção. Caso esse não seja um requisito, é possível instalar um gateway SIP no local. A Unificação de Mensagens do Exchange conta com a flexibilidade de não exigir a ligação da infra-estrutura de PBX, não havendo nenhum requisito quanto a um UDP.
"Estou em meio ao processo de atualização da minha arquitetura do Exchange."
Muitos clientes hesitam em começar a migração da Unificação de Mensagens enquanto estão em meio ao processo de atualização da infra-estrutura do Exchange. O meu conselho é que, caso já tenha tomado a decisão de migrar para a Unificação de Mensagens, você vá em frente e migre enquanto o servidor do Exchange está sendo atualizado. Basta seguir os planos de atualização, e não deverá haver nenhuma complexidade substancial adicionada ao projeto.
"Tenho muitos locais pequenos com menos de 10 pessoas e alguns deles não possuem um PBX."
Em locais menores que contam com um PBX no local, tudo o que você tem a fazer é instalar um gateway SIP no local. Nos locais em que não há um PBX, existem técnicas de telefonia que podem ser usadas para encaminhar os telefones para o PBX central tendo em vista o encaminhamento das chamadas para o sistema de Unificação de Mensagens. Em suma, é possível implantar os serviços de Unificação de Mensagens aos menores locais remotos da organização a custo mínimo.
É importante observar que esses locais menores, na verdade, proporcionam um ótimo ambiente de teste para a migração. Uma estratégia de migração comum é começar na borda da rede e se mover até o núcleo. Você migra os menores sites primeiro e, em seguida, realiza um postmortem com a equipe da Unificação de Mensagens para saber o que foi bem e quais foram os desafios enfrentados. Assim, é possível implementar essas lições aprendidas durante a migração do próximo local.
A equipe de Unificação de Mensagens optou por migrar da borda da rede até o núcleo. Em todos os locais, a colocação do servidor Unificação de Mensagens seguirá as práticas recomendadas da seguinte arquitetura do servidor do Exchange. A equipe cria sua própria documentação de planejamento de cada site, tendo em mente os itens abordados na seção "Coisas a serem consideradas". A documentação é usada durante a instalação e a configuração dos servidores, durante o treinamento do usuário e o planejamento das estratégias de migração.
Para cada local, a equipe planeja o desligamento rápido dos usuários, tendo em vista o sistema de Unificação de Mensagens, e deixar a plataforma herdada in-loco para oferecer suporte a aplicativos IVR que continuarão sendo usados até que uma solução alternativa seja encontrada. A equipe optou por aguardar 30 dias após a migração, antes de passar ao próximo local. A espera deve garantir que cada local tenha se ajustado à nova plataforma antes da migração de mais usuários e da adição de mais chamadas de suporte técnico.
A organização opta por migrar Austin primeiro. Como o email de Austin é atendido em Seattle, a equipe instala a função de servidor Unificação de Mensagens em Seattle e fornece a integração de PBX instalando um gateway SIP em Austin. E como a plataforma de caixa postal herdada está ligada em rede, a equipe deve atender à necessidade de rede da plataforma de Unificação de Mensagens instalando um servidor do sistema de mensagem. Como os usuários são treinados no novo sistema e a migração transcorre normalmente, a equipe opta por migrar Nova York na seqüência.
Nova York conta com servidores Caixa de Correio e Transporte de Hub próprios. Por isso, as práticas recomendadas dizem que um servidor Unificação de Mensagens deve ser instalado em Nova York. A equipe instala o servidor, seguindo os documentos de planejamento da migração. O servidor é adicionado à lista de nós no servidor do sistema de mensagem a ser incluído na rede de caixa postal. Os usuários são treinados e a migração transcorre normalmente para a Unificação de Mensagens.
Seattle já conta com um servidor Unificação de Mensagens implantado da fase de migração de Austin. A equipe determina que o servidor contém portas de caixa postal o suficiente para oferecer suporte a Seattle e a Austin. Os usuários em Seattle são treinados e a migração é feita para a Unificação de Mensagens.
A arquitetura na Europa é muito mais fácil de criar. A infra-estrutura de PBX está ligada em rede em rede e o Exchange é centralizado. Um servidor Unificação de Mensagens é implantado em Londres e cada local é migrado, começando pelo menor. A Figura 3 ilustra a arquitetura final.
Figura 3 Arquitetura de exemplo depois da migração (Clique na imagem para ampliá-la)

A importância de seguir um plano
Sou chamado para resolver muitas migrações malsucedidas para Unificação de Mensagens. Muitas dessas organizações desrespeitaram uma ou mais das regras principais.
Primeiro, sempre se lembre de que não se trata apenas de um sistema de caixa postal. Trata-se de um aplicativo de missão crítica, devendo ser tratado como tal. Os usuários dependem de tecnologias de caixa postal para trocar informações. Tenha em mente que se trata de um aplicativo de negócios e planeje a migração para levar em conta todas as considerações que abordei neste artigo.
Você deve envolver a equipe de telecomunicações por completo em qualquer migração para a Unificação de Mensagens. Ela terá a melhor compreensão dos aplicativos de telefonia integrados à infra-estrutura corporativa.
Ao migrar para a Unificação de Mensagens, planeje a solução da empresa. Embora talvez só esteja implementando um único local inicialmente, você deve sempre ter uma visão ampla em mente. Por exemplo, implementar um único local sem fornecer um sistema de mensagem aos demais locais terá impacto sobre a comunicação entre os usuários. É claro que essa pode ser uma tarefa grande, então não tenha receio de consultar um especialista para criar uma arquitetura que leve em conta todos os aplicativos de TI.
Por fim, não subestime a importância do treinamento. A Unificação de Mensagens introduz uma mudança de paradigma na forma como os usuários se comunicam e interagem com a caixa postal. O que parece intuitivo para você pode não ser tão intuitivo para os outros. Um bom treinamento é a chave para criar a transição mais tranqüila possível.

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

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.


Comunicação e colaboração
como a voz reforça o OCS 2007
Rajesh Ramanathan
Visão geral:
  • Fazendo chamadas no OCS 2007
  • Como as chamadas são protegidas
  • Conversas multimodais no OCS
  • Integração com a UM do Exchange para serviços de caixa postal

Conteúdo
Chamadas básicas de voz
Usando números de telefone
Chamadas seguras
Atravessando NATs e firewalls
Roteamento de números de telefone
Roteamento de entrada
Relatórios de qualidade e solução de problemas
Unindo todos os elementos
Comportamento multimodal e conversas
Caixa postal
Conclusão
A primeira parte desta série sobre o Microsoft OCS (Office Communication Server) 2007 mostrava como o OCS foi criado com base nos pontos fortes do LCS (Live Communication Server) 2005 para fornecer
às empresas recursos aprimorados de mensagens instantâneas e presença, além de funções avançadas de mídia e telefonia (consulte a edição de fevereiro de 2008 da TechNet Magazine em technet.microsoft.com/magazine/cc194409). Este artigo dá continuidade à proposta, aprofundando-se nos aspectos de VoIP. Explicarei como as chamadas de voz são simples no sistema do OCS e abordarei a tecnologia camada por camada, acrescentando cada componente, junto com a funcionalidade correspondente.
Como foi mencionado no artigo anterior, o OCS pode ser configurado para fornecer telefonia aos usuários de várias formas diferentes:
Enterprise Voice. É a solução completa de comunicação unificada, que utiliza o OCS em conjunto com o Servidor de Mediação Microsoft®, sem a necessidade de um PBX. A UM (Unificação de Mensagens) do Exchange fornece os recursos de caixa postal do sistema. Vou me referir aos usuários deste serviço como "usuários UC" no restante do artigo. Também usarei o termo "ponto de extremidade UC" em referência a um cliente com essa configuração.
Enterprise Voice com integração ao PBX. Essa configuração permite que os usuários obtenham as vantagens da comunicação unificada e, ao mesmo tempo, mantenham os telefones PBX existentes em suas estações de trabalho. O OCS e o PBX podem ser configurados em paralelo, de forma que as chamadas recebidas gerem toques no Office Communicator e nos pontos de extremidade PBX ao mesmo tempo. O PBX continua a controlar o roteamento de chamadas e a fornecer os serviços de caixa postal.
Controle de chamada remota. Esse recurso usa o PBX como telefone principal, permitindo que seja controlado pelo cliente do Office Communicator.

Chamadas básicas de voz
Concentrarei minhas explicações no funcionamento do sistema para os usuários do Enterprise Voice. As chamadas simples de voz são configuradas no sistema do OCS usando o mecanismo SIP INVITE, conforme descrito na RFC 3261. O servidor do OCS desempenha a função de um proxy semelhante a um postmaster, que retransmite mensagens entre clientes (ou pontos de extremidade). Novos SIP INVITEs são originados pelos clientes sempre que uma sessão em tempo real, como uma chamada ou sessão de mensagens instantâneas, é criada. Se o INVITE é reconhecido com uma resposta (ou seja, o ponto de extremidade remoto envia uma resposta 200 OK), a chamada é estabelecida (veja a Figura 1).
Figura 1. Formato INVITE e 200 OK
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**
Na Figura 2, Alice liga para Bob, escolhendo Chamada do Communicator no OC (Office Communicator) 2007, e o OC 2007 origina um INVITE para o URI (Uniform Resource Identifier) SIP de Bob (sip:bob@example.com). O INVITE transporta o descritor de chamada de áudio (denominado SDP, Session Description Protocol) dos pontos de extremidade de mídia onde Alice pode receber áudio. O OCS faz a bifurcação do INVITE para os pontos de extremidade SIP registrados de Bob (por exemplo, o Communicator Phone Edition e o Communicator desktop). O INVITE contém um cabeçalho From sip:alice@example.com, usado pelos pontos de extremidade clientes de Bob em uma RNL (pesquisa de nome inversa) para localizar o nome (Alice) a ser exibido na notificação de chamada recebida.
Figura 2. Roteamento de uma chamada para vários pontos de extremidade (clique na imagem para exibi-la em tamanho maior)
O GRUU (Globally Routable User Agent URI) de cada ponto de extremidade é exibido. O GRUU identifica de forma exclusiva um ponto de extremidade SIP e é obtido durante o processo de registro, emitido pelo servidor do OCS. O endereço GRUU ajuda a rotear mensagens SIP. Assim, depois que a chamada é atendida por um ponto de extremidade, o sinal SIP subseqüente para outras operações realizadas durante a chamada pode ser transportado entre os pontos de extremidade diretamente, com o uso do endereço GRUU.
A Figura 3 continua o processo, sendo que Bob atende no Communicator desktop. O OC de Bob envia uma mensagem 200 OK informando onde ele pode receber áudio. Assim que o proxy do OCS detecta o atendimento em um ponto de extremidade, cancela a chamada para os outros pontos de extremidade do Communicator Phone Edition. Quando a resposta 200 OK alcança o ponto de extremidade do Communicator de Alice, os dois pontos de extremidade do Communicator têm informações suficientes (portas IP, parâmetros de criptografia, e assim por diante) para iniciar a mídia.
Figura 3. Atendimento em um ponto de extremidade (clique na imagem para exibi-la em tamanho maior)

Usando números de telefone
Até agora, vimos o usuário clicar em Chamada do Communicator para criar o convite. O processo é um pouco diferente quando o usuário seleciona ou digita um número de telefone:
  • Primeiro, o cliente normaliza o número de telefone e o representa como um URI TEL, que descreve recursos identificados por números de telefone, conforme indicado na RFC 3966.
  • Como o servidor do OCS somente reconhece URIs SIP, os clientes convertem o URI TEL em um URI SIP correspondente, adicionando o sufixo do domínio e uma marca user=phone.
  • Se o número corresponder a um usuário interno, o OCS roteará o convite diretamente. Se o número for externo, o convite será roteado para o gateway SIP-PSTN mais próximo.
Algumas chamadas para um número PSTN (Rede Telefônica Pública Comutada) exigem que o caminho de mídia seja configurado antes do atendimento da chamada, de forma que comunicados remotos possam ser reproduzidos ou dígitos adicionais coletados para completar a chamada. Em cenários assim, o gateway PSTN envia um indicador de Progresso da Sessão 183 com um SDP de áudio. O Communicator usa essa informação para configurar um caminho de mídia bidirecional com um ponto de extremidade de destino, antes que a chamada seja atendida pelo usuário remoto.
Quando o caminho de mídia preliminar está configurado, o Communicator habilita o teclado DTMF (Dual-Tone Multi-Frequency), ou seja, os toques de sinalização de discagem do telefone, para que o usuário possa inserir os dígitos adicionais requeridos pelo sistema remoto. Os dígitos DTMF inseridos são enviados pelo caminho de mídia como pacotes RFC 2833. O gateway PSTN se encarrega de gerar o sinais de toques DTMF adequados do lado do PSTN.
Observe que, se Bob tiver habilitado o Toque Simultâneo em seu celular, o proxy do OCS deverá rotear a chamada para o gateway e fazer com que os outros pontos de extremidade do Communicator de Bob toquem ao mesmo tempo. Em cenários assim, o proxy do OCS indica que a bifurcação está ativa na resposta de Progresso da Sessão 183. Isso faz com que o Communicator estabeleça um canal de mídia de somente recebimento com o gateway PSTN.

Chamadas seguras
Um dos principais recursos das chamadas de voz configuradas pelo OC é a criptografia de mídia por padrão, usando o protocolo SRTP, conforme definido na RFC 3711. O protocolo SRTP fornece ao tráfego RTP confidencialidade, autenticação de mensagens e proteção contra repetição. Durante a configuração da chamada, os clientes negociam os recursos de segurança e trocam chaves criptográficas, como parte do mecanismo INVITE.
A configuração padrão de criptografia para o OC é "opcional", permitindo que dois pontos de extremidade do OC configurem um canal de mídia criptografado. Essa configuração pode ser ajustada pelo administrador, de forma a adaptar-se às necessidades de conformidade da organização. Pode, por exemplo, tornar-se mais rígida para forçar a criptografia em todas as chamadas, ou então ser totalmente desativada.

Atravessando NATs e firewalls
Os clientes no sistema do OCS usam a tecnologia ICE (Estabelecimento de Conectividade Interativa) para fornecer conectividade de mídia aos usuários protegidos por dispositivos de NAT (conversão de endereço de rede) e firewalls, sem exigir alterações nos componentes de NAT existentes. A tecnologia ICE está sendo padronizada pela IETF (Internet Engineering Task Force). Cada cliente tem conhecimento do Servidor de Borda de A/V (áudio/vídeo) que atende a ele, por meio de um mecanismo de provisionamento inband, e mantém um link autenticado para o Servidor de Borda de A/V durante o logon.
Antes de fazer uma chamada, o cliente aloca recursos nos possíveis locais de conectividade (endereços e portas, também conhecidos como candidatos) no Servidor de Borda A/V (para a retransmissão de mídia), no NAT ou no cliente host propriamente dito. Quando o SIP INVITE é enviado, transporta as informações de conectividade como parte do INVITE. A resposta 200 OK transporta informações semelhantes sobre o ponto candidato. Quando cada ponto de extremidade já tem uma lista de pontos candidatos, um mecanismo elaborado de classificação e verificação seleciona o caminho ideal entre os dois pontos para garantir o sucesso da mídia.

Roteamento de números de telefone
O roteamento de números de telefone introduz uma certa complexidade no mecanismo básico de chamada, devido aos seguintes fatores:
  • As organizações podem ter diferentes planos de discagem implantados internamente para chamadas de curta distância.
  • Talvez os números estejam armazenados em formatos não padronizados (por exemplo, é possível que cadeias de caracteres de sete dígitos tenham sido salvas pelos usuários no Microsoft Office Outlook®).
  • Pode ser que haja políticas diferentes mapeadas para números de saída diferentes. Por exemplo, a discagem internacional pode estar bloqueada para determinados usuários.
O sistema do OCS exige que os números de telefone estejam no formato RFC 3966 TEL URI para que possam ser roteados corretamente. Os números que não estiverem nesse formato serão convertidos antes que o cliente emita um INVITE. O diagrama na Figura 4 mostra como isso ocorre no sistema do OCS.
Figura 4. Roteando números de telefone (clique na imagem para exibi-la em tamanho maior)
Os números disponíveis para o cliente podem ter várias origens. Os números pré-normalizados vêm do ABS (Serviço de Catálogo de Endereços), que pode ter regras de normalização definidas pelo administrador para a conversão de números em um formato E.164 normalizado. Quando um cliente emite um SIP INVITE para o número normalizado, o OCS aplica um processo de conversão que mapeia o número para qualquer usuário interno.
  • A Etapa 1 mostra que os números inseridos no sistema são exclusivos (normalizados, de acordo com o plano de numeração E.164) ou têm um contexto telefônico que identifica sua localização. Esses números são enviados para o servidor como parte do SIP INVITE. O OCS roteia o INVITE para um processo de conversão.
  • O processo de conversão (Etapa 2) tenta mapear o número de telefone para um ponto de extremidade UC usando a RNL do lado do servidor. A conversão pode identificar uma rota para o número levando a um roteamento de saída ou a um usuário UC, ou então apresentar falha na chamada, com um código 4xx, se o número não puder ser convertido corretamente.
  • Se o número for convertido em um número não-UC ou externo, será enviado para o componente de roteamento de saída, que redirecionará o INVITE para o gateway SIP-PSTN adequado para processamento adicional, depois de aplicar ao número as políticas relacionadas ao chamador (Etapa 3A). O roteamento de saída se encarrega de balancear a carga da chamada entre os gateways ou fazer failover para gateways alternativos, se necessário. O processo de roteamento de saída pode falhar ou recusar a chamada e retornar um código de resposta SIP 403, se o acesso a determinado número for proibido. Observe que o roteamento de saída se aplica apenas quando o chamador é um usuário UC. Quando não é esse o caso, o OCS tenta usar as rotas estáticas para gateways configurados para aquele URI.
  • Se o número for convertido em um número de usuário UC, o INVITE será roteado para o URI SIP daquele usuário (Etapa 3B). O roteamento de entrada é uma função do OCS que se aplica somente a usuários UC e a todas as chamadas direcionadas ao URI SIP. Como você verá, o roteamento de entrada aplica regras para tempo limite de toques, encaminhamento de chamadas e encaminhamento de caixa postal para o usuário UC.
Observe que o número de resultados do processo de normalização pode variar, dependendo da localização do cliente. Os administradores podem configurar perfis de localização e atribuir regras de conversão numérica específicas para uma determinada localização (por exemplo, de que forma a discagem de quatro dígitos funcionará naquela localização). Um perfil de localização é atribuído a cada usuário UC, e todos os clientes no sistema baixam as regras específicas a seus perfis de localização usando o provisionamento inband. Em seguida, explicarei em mais detalhes o roteamento de entrada.

Roteamento de entrada
As regras de roteamento de entrada especificam como as chamadas para um usuário devem ser roteadas, na presença ou na ausência de clientes registrados no sistema. O componente de roteamento de entrada também se encarrega de aplicar regras baseadas em presença à chamada recebida; pode, por exemplo, enviar as chamadas recebidas para a caixa postal, se o usuário tiver definido o estado de presença como Não Incomodar. O roteamento de entrada tem conhecimento dos níveis dos contêineres de presença e recusa automaticamente as chamadas de usuários em contêineres bloqueados. A Figura 5 mostra um resumo das opções com suporte do componente de roteamento de entrada do OCS.
Figura 5. Recursos do roteamento de entrada
Recurso | Comentário
Duração do toque | O padrão é de 20 segundos. O usuário pode alterar para, no máximo, 60 segundos. As chamadas são desviadas para o destino de chamadas não atendidas após a duração do tempo limite.
Rotear chamadas não atendidas para a caixa postal | Esse é o padrão, se o usuário tiver a caixa postal habilitada. A chamada é roteada de acordo com as regras do roteamento de entrada.
Gerar notificações de chamada perdida quando o chamador desliga antes que a chamada alcance a caixa postal | Notifica a UM do Exchange sobre essas chamadas perdidas.
Bloqueio de chamadas | Recusa chamadas de chamadores bloqueados (somente chamadas de usuários com identidades SIP podem ser bloqueadas).
Não Incomodar | Roteia as chamadas para a caixa postal. Os destinos de toque simultâneo não são acionados se o usuário está nesse modo.
Lista de interrupções permitidas | Permite chamadas se o usuário estiver no contêiner de Equipe, mesmo que esteja definido como Não Interromper.
Toque simultâneo | Configura as chamadas recebidas para acionar o toque de um número de telefone PSTN, e também dos clientes do Communicator e do Communicator Phone Edition.
Encaminhamento imediato de chamada | Encaminha imediatamente uma chamada recebida para outro usuário, um número de telefone PSTN ou a caixa postal.
Encaminhamento de chamada não atendida | Encaminha uma chamada não atendida para outro usuário, um número de telefone PSTN ou a caixa postal.
Horário de trabalho | Usa o horário de trabalho configurado no Calendário do Outlook para ativar as configurações de encaminhamento de chamada de um usuário.
As regras de roteamento de entrada são carregadas no servidor como um esquema XML, como parte das informações de autoprovisionamento de um usuário. A Figura 6 mostra como funciona o roteamento de entrada. Uma chamada recebida para um usuário no sistema do OCS aciona por padrão o toque do usuário (mostrado como "Eu"). Se a chamada não for atendida no período de duração do toque, a chamada não atendida será enviada para a caixa postal por padrão. O usuário poderá optar por modificar a configuração padrão, escolhendo o encaminhamento imediato para um número, para outra pessoa ou diretamente para a caixa postal.
Figura 6. Roteando chamadas (durante o horário de trabalho) (clique na imagem para exibi-la em tamanho maior)
Todas as chamadas encaminhadas imediatamente para outra pessoa ou número farão com que as regras de roteamento de entrada para aquela pessoa ou número sejam aplicadas. O usuário também pode definir o encaminhamento das chamadas não atendidas para outro número ou pessoa.
Se o usuário marcar a opção Aplicar somente durante meu horário de trabalho do Outlook, nas regras de encaminhamento, as regras mostradas na Figura 6 serão aplicadas durante o horário de trabalho, e o comportamento padrão de toque dos pontos de extremidade registrados será aplicado fora desse horário. Para permitir esse comportamento, a organização precisa ter implantados os clientes do Microsoft Exchange Server 2007 e do Outlook 2007, pois o Communicator usa as informações de horário de trabalho do Web service de disponibilidade do Exchange 2007 e utiliza o suporte à detecção automática do Outlook 2007 para obter a localização do servidor.

Relatórios de qualidade e solução de problemas
Os clientes no sistema do OCS 2007 usam o RTAudio, um codec de áudio de última geração, capaz de tolerar condições imperfeitas da rede como tremulação, perda de pacotes, e assim por diante. Mesmo assim, o monitoramento é fundamental para que os administradores consigam localizar e corrigir possíveis pontos problemáticos. Ao final de todas as chamadas, os clientes no sistema do OCS 2007 enviam para um servidor central de QoE (Qualidade da Experiência) relatórios sobre a qualidade de cada chamada e fornecem estatísticas detalhadas, incluindo largura de banda, perda, tremulação, pontuação média de opiniões (uma medida da percepção do usuário), dispositivos utilizados e muito mais. Isso é feito com o envio da carga em uma solicitação SIP SERVICE para o servidor de QoE, que tem seu endereço programado com o uso do mecanismo de provisionamento inband.
Todos os pontos de extremidade clientes reportam a qualidade das chamadas para o servidor de QoE de forma independente. Caso uma chamada falhe devido a um erro na sinalização, os clientes enviarão o mesmo relatório também para o OCS, que conta com um repositório de todos os erros criados pelos clientes.﻿

Unindo todos os elementos
Agora que já descrevemos vários aspectos da configuração de uma chamada, inclusive a inserção de números, o roteamento de entrada e de saída e as verificações de conectividade, vejamos o processo como um todo. A Figura 7 resume o que acontece a partir do momento em que um usuário faz uma chamada. Os clientes no sistema do OCS desempenham um papel fundamental na configuração de uma chamada, gerenciando todo o processo. O OCS está envolvido no roteamento inicial da chamada, e os servidores de borda ajudam os clientes a localizar a rota de mídia ideal. Vejamos agora o que acontece em seguida — a conversa.
Figura 7. Fluxo completo da chamada (clique na imagem para exibi-la em tamanho maior)

Comportamento multimodal e conversas
O conceito de conversas é essencial ao sistema do OCS. Uma conversa é uma sessão multimodal entre duas ou mais pessoas, podendo incluir voz, vídeo e MI ao mesmo tempo, além de artefatos como transferências de arquivos durante a sessão, emails do Outlook ou notas armazenadas no Microsoft Office OneNote®.
Vários aspectos das conversas podem exercer impacto sobre o design dos sistemas clientes do OCS:
  • Todas as modalidades envolvidas em uma conversa usam a mesma janela. Se uma mensagem instantânea é adicionada a uma conversa de áudio, ela é ﻿associada à mesma janela.
  • As conversas podem ocorrer entre dispositivos. Os usuários podem optar por ter áudio no Communicator Phone Edition, mas ter MIs no Communicator desktop.
  • Todos os modos são escalonáveis para uma conferência conjunta: se isso ocorrer, todas as modalidades de uma conversa deverão ser escalonadas em conjunto, independentemente da modalidade de dispositivo ativada no momento. Por exemplo, se um modo de áudio estiver disponível no Communicator Phone Edition e um modo de MI para a mesma conversa estiver disponível no Communicator desktop, o escalonamento para a conferência garantirá que o áudio e a MI tenham o mesmo conjunto de participantes da conversa.
  • As conversas, e não as sessões individuais, são registradas. Os registros de chamadas contêm informações completas sobre a conversa, inclusive detalhes sobre notas criadas durante a conversa, trocas de mensagens instantâneas, a duração do áudio, e assim por diante. Isso fornece aos usuários uma visão consolidada bastante útil da conversa como um todo, quando abrem o registro de chamadas do Outlook.
  • É possível continuar conversas a partir dos registros de conversas.. Os clientes do OCS vinculam conversas usando um ID de conversa — um número que identifica com exclusividade a conversa entre dispositivos e aplicativos. Existe um mecanismo elaborado para computar deltas de conversas quando novas conversas são iniciadas a partir de um registro de histórico de uma conversa antiga. O mesmo ID de conversa é armazenado como ID do email no Outlook.
O ID da conversa viaja como parte do SIP INVITE, como uma propriedade personalizada, Ms-Conversation-Id. A Figura 8 mostra uma transação assim, na qual a voz é adicionada primeiro, e em seguida uma MI. Ao final da conversa multimodal, o registro de histórico armazenado no Outlook tem o mesmo ID da conversa.
Figura 8. Conversas multimodais e ID da conversa (clique na imagem para exibi-la em tamanho maior)

A UM do Exchange é o sistema de caixa postal do OCS 2007. O OCS somente faz o roteamento de chamadas para usuários com o UC habilitado para a UM do Exchange. O OCS fornece vários recursos de integração com a UM do Exchange:
  • A opção Chamar Caixa Postal, na interface do usuário de telefone do Communicator (veja a Figura 9), permite que o usuário gerencie a caixa postal da UM, altere as saudações, e assim por diante, sem precisar digitar o PIN, pois já está autenticado.
  • O indicador de chamada em espera, na interface do usuário do Communicator (veja a Figura 10), permite que o usuário abra a pasta da caixa postal no Outlook; já o indicador do Communicator Phone Edition permite que o usuário reproduza as mensagens de voz diretamente no telefone.
  • As chamadas podem ser encaminhadas para a caixa postal a partir da interface do usuário do Communicator.
  • As chamadas recusadas são roteadas automaticamente para a caixa postal.
  • A opção Tocar no Telefone, no item de caixa postal do Outlook, aciona diretamente o toque dos clientes do Office Communicator.
Figura 9. Opção Chamar Caixa Postal no Communicator
Figura 10. Indicador de mensagem em espera no Communicator
O mecanismo pelo qual o OC recebe a notificação da caixa postal é diferente daquele do Communicator Phone Edition. O OC se registra para receber notificações de novos emails na pasta de pesquisa da caixa postal, no Outlook, e informa sobre as novas mensagens nessa pasta. O Communicator também usa Conversas Perdidas e Registros de Chamadas.

Conclusão
Mostrei aqui como funcionam as chamadas de voz no OCS 2007, um sistema baseado no protocolo SIP que utiliza várias RFCs. Os pontos de extremidade clientes desempenham um papel central no gerenciamento de chamadas no OCS. Todas as chamadas de voz são criptografadas com segurança por padrão. O OCS conta com componentes flexíveis, que permitem a manipulação de números e o gerenciamento de seu fluxo no sistema.
As conversas são um conceito central no OCS, envolvendo voz, MI e vídeo. O OCS se integra à UM do Exchange e permite que os pontos de extremidade do Communicator recebam notificações da caixa postal, além de acessar a caixa postal via Outlook ou diretamente no servidor.

Rajesh Ramanathan trabalha há 14 anos na área de comunicação. Projetou protocolos de voz, experiências do usuário, recursos de voz e de conferência para o Office Communicator 2007. Ele trabalha atualmente como gerente-chefe de programa na equipe do Office Communicator, na Microsoft. Entre em contato com Rajesh pelo email rajeshra@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.


Comunicação e colaboração
Crie conexões poderosas com o Groove e o SharePoint
Alan Maddison
Visão geral:
  • Criando uma biblioteca de documentos do SharePoint
  • Criando um espaço de trabalho do Groove
  • Sincronizando o Groove e o SharePoint
  • Permitindo o acesso ao espaço de trabalho

Conteúdo
Groove e SharePoint juntos
Introdução
Configurando o controle de aprovação
Criando o espaço de trabalho do Groove
Sincronizando o Groove e o SharePoint
Permitindo o acesso ao espaço de trabalho
Conclusão
Muitas vezes, os profissionais de TI se questionam sobre a aparente semelhança entre o Microsoft Office Groove 2007 (Groove) e o Microsoft Office SharePoint Server 2007 (SharePoint) e têm dúvidas sobre as
circunstâncias nas quais cada um deles seria mais adequado. À primeira vista, os dois produtos parecem muito semelhantes, pois ambos fornecem recursos de colaboração. No entanto, após uma análise mais profunda da arquitetura, você começa a perceber as diferenças entre eles.
O SharePoint® oferece uma estrutura de gerenciamento de conteúdo e um conjunto de ferramentas de colaboração robustos e escalonáveis, com suporte para fluxos de trabalho estruturados. Já o Groove™, por outro lado, é um conjunto de ferramentas de colaboração que permite a implantação rápida de espaços de trabalho, com pouca ou nenhuma sobrecarga da TI. Com suporte para recursos que incluem colaboração em documentos, discussões encadeadas e calendários, o Groove proporciona a estrutura ideal para uma colaboração dinâmica, segura e ad hoc. Em suma, a maioria dos usuários fará naturalmente usos diferenciados desses produtos.
Além disso, o lançamento do Groove 2007 introduziu o suporte interno à integração com o SharePoint, com o uso da ferramenta Arquivos do SharePoint. Essa ferramenta permite que os espaços de trabalho do Groove sejam sincronizados com as bibliotecas de documentos do SharePoint e, como veremos, a integração interna possibilita o máximo aproveitamento dos dois produtos. Na verdade, combinar a flexibilidade e a natureza dinâmica do Groove com a sofisticação e a potência do SharePoint resulta em vantagens consideráveis para muitos usuários.
Groove e SharePoint juntos
O atual mundo de TI exige uma colaboração cada vez maior entre as organizações, seus parceiros e fornecedores. Contudo, as poderosas soluções de colaboração implementadas no momento, com o uso de produtos como o SharePoint, tendem a concentrar-se principalmente nas equipes internas e na necessidade de tornar as informações amplamente disponíveis dentro da organização como um todo. Nesses casos, há desafios consideráveis, tanto do ponto de vista administrativo quanto de segurança, para fornecer acesso aos usuários externos à organização. Diante de tais desafios, a meta consiste em permitir aos usuários o contato ad hoc com parceiros externos.
A combinação entre o Groove e o SharePoint oferece exatamente essa solução. O SharePoint permite a colaboração dentro da organização, a pesquisa de conteúdo e a criação de uma estrutura de fluxo de trabalho. O acréscimo do Groove permite que as empresas estendam esses recursos, passando a incluir com facilidade a colaboração entre organizações. Com o Groove, os usuários podem configurar rapidamente espaços de trabalho colaborativos cruzando as fronteiras da empresa. Além disso, o suporte às chaves simétricas com criptografia AES de 192 bits garante a segurança na colaboração. Na verdade, a segurança do Groove é interna e sempre ativa, de forma que os usuários não tenham a preocupação de configurá-la.
A arquitetura de segurança do Groove fornece um alto nível de proteção para os espaços de trabalho e seu conteúdo, tanto no armazenamento local quanto durante a transmissão via rede. A ferramenta Arquivos do SharePoint permite que essas informações sejam sincronizadas de forma bidirecional com uma biblioteca de documentos do SharePoint, garantindo sua disponibilidade centralizada para facilitar o acesso interno. Vamos ver como funciona esse processo, usando um exemplo concreto.
Introdução
Normalmente, as organizações colaboram com muitas empresas em suas atividades cotidianas de negócios. Em geral, isso envolve, além de organizações externas, indivíduos de departamentos que não necessariamente trabalham juntos com regularidade, como os departamentos financeiro, de comunicação corporativa e jurídico. Então, essas organizações precisam criar uma equipe interna ad hoc de colaboração, e precisam também tornar o produto dessa colaboração disponível para indivíduos que não estão envolvidos no processo propriamente dito, mas que precisam ter acesso ao seu resultado final. Usando o SharePoint e o Groove, é fácil alcançar essas metas.
Se você ainda não tem uma biblioteca de documentos do SharePoint que deseja sincronizar com seu espaço de trabalho do Groove, o primeiro passo consiste em criá-la. Para fazer isso, conecte-se ao SharePoint e selecione o link Exibir Todo o Conteúdo. Depois que a página for carregada, selecione Criar e, depois, conforme mostrado na Figura 1, escolha Biblioteca de Documentos, na coluna Bibliotecas.
Figura 1. Criando uma biblioteca de documentos do SharePoint (clique na imagem para exibi-la em tamanho maior)
Há diversas configurações a serem definidas na página da nova biblioteca de documentos — o nome e a descrição da biblioteca, se a biblioteca será incluída na seção Links Rápidos, se o controle de versões será habilitado e o formato padrão para os novos documentos criados diretamente na biblioteca. A seleção Histórico de Versões do Documento é desabilitada por padrão, mas você deve habilitar esse recurso se o controle de versões for adequado ao seu ambiente. Você também deve levar em consideração alguns dos recursos avançados disponíveis no SharePoint, que podem ser usados como parte da sua implementação do Groove e do SharePoint. Esses recursos avançados incluem:
  • Histórico de versões
  • Controle de aprovação
  • Procedimentos de check-out
  • Controle de fluxo de trabalho
  • Políticas de retenção de documentos
  • Auditoria
  • RSS (Really Simple Syndication)
Essas funções adicionais disponíveis no SharePoint podem acrescentar um valor considerável ao trabalho com o Groove. No meu exemplo, esses recursos adicionais — especialmente o controle de aprovação — se mostram muito úteis. Suponha, por exemplo, que os membros de uma equipe colaboram no Groove para criar o rascunho de um documento. Quando o a versão final do rascunho estiver pronta para revisão, poderá ser sincronizada com o SharePoint e, depois, submetida ao processo de aprovação.

Configurando o controle de aprovação
Para configurar esse recurso, selecione o menu Configurações, na biblioteca de documentos, e escolha o item de configurações. Isso exibirá todas as opções de configuração e personalização. Para configurar a Aprovação, selecione o link de configurações Fluxo de Trabalho, na seção Permissões e Gerenciamento, para abrir a página Adicionar um fluxo de trabalho. Agora, selecione o modelo de Fluxo de Trabalho, que, em nosso exemplo, será o modelo de Aprovação, e digite um nome para o fluxo de trabalho. Em seguida, você precisa decidir se irá usar uma lista de tarefas existente ou criar uma nova. Uma nova lista de tarefas oferece maior confidencialidade. No entanto, como essa questão não é tratada no nosso exemplo, simplesmente escolha o padrão.
Depois de escolher a lista de tarefas, você precisa decidir como o processo de Aprovação deve começar. Vamos torná-lo um processo manual, permitindo que qualquer usuário autenticado com as permissões corretas o inicie. Outras opções permitem automatizar esse processo com base no controle de versão, se ele estiver habilitado na biblioteca de documentos, ou então sempre que um novo documento for adicionado ou um documento existente for alterado.
Depois de pressionar Avançar para aceitar essas opções de configuração, você precisará digitar algumas informações finais de configuração. A primeira opção a ser configurada se refere à forma como as tarefas devem ser atribuídas. Como é possível ter várias pessoas no processo de aprovação, você pode designar os aprovadores em série, sendo que uma pessoa aprova o item e ele passa à próxima pessoa, ou então em paralelo, sendo que qualquer pessoa pode aprová-lo em qualquer momento. Você precisa, então, decidir se permitirá que os aprovadores atribuam tarefas a outras pessoas, e se eles poderão solicitar alterações antes da conclusão da tarefa.
A próxima etapa consiste em selecionar os aprovadores propriamente ditos e, depois, decidir até quando a tarefa deverá ser concluída. Por fim, você decide quando o fluxo de trabalho será concluído. A opção padrão é que o fluxo de trabalho será concluído quando todas as tarefas tiverem sido realizadas. Na opção de configuração final, você especifica se o status de Aprovação será atualizado quando o fluxo de trabalho for concluído. Depois que você pressionar o botão OK, o processo de Aprovação será criado e você poderá iniciar o processo de aprovação de documentos.

Criando o espaço de trabalho do Groove
Depois de criar a biblioteca de documentos do SharePoint, a próxima etapa consiste em criar um espaço de trabalho do Groove. Para fazer isso, primeiro verifique se você tem uma conta do Groove e pelo menos uma identidade. As identidades são a base para a presença e a comunicação no Groove. Cada conta do Groove pode ser associada a várias identidades, e cada identidade é associada a um arquivo de contato exclusivo, permitindo que você personalize suas informações de contato em cada identidade utilizada. Você também pode exportar sua conta do Groove e as identidades associadas, a fim de usá-las em vários computadores.
Depois de criar uma conta e uma identidade, abra a Barra inicial do Groove, clicando duas vezes no ícone do Groove na bandeja do sistema. Clique na opção Novo Espaço de Trabalho, digite um nome adequado para o espaço de trabalho e escolha um tipo de espaço de trabalho Padrão. O espaço de trabalho padrão do Groove facilita a atribuição de presença, alertas e funções aos membros do espaço de trabalho. Quando você clicar em OK, o Groove criará e abrirá o espaço de trabalho. A Figura 2 mostra um novo espaço de trabalho com alguns arquivos adicionados à ferramenta Arquivos. Neste ponto, o espaço de trabalho já está em funcionamento, e você pode concluir sua configuração, definindo alertas ou acrescentando as ferramentas que desejar.
Figura 2. Um novo espaço de trabalho do Groove (clique na imagem para exibi-la em tamanho maior)
Os alertas podem ser configurados em nível de ferramenta, espaço de trabalho ou arquivo individual. Os quatro níveis de alertas são nenhum, médio, alto e automático. A configuração média realça o novo conteúdo; já as configurações alta ou automática reproduzem um arquivo de áudio. Também é possível configurar alertas para notificá-lo quando um usuário entrar em um espaço de trabalho específico. Para configurar alertas, selecione Definir Alertas, no menu Opções. Os alertas de arquivos individuais são definidos nas propriedades do arquivo propriamente dito; clique com o botão direito do mouse no espaço de trabalho e selecione Propriedades.
Além da ferramenta Arquivos, para a colaboração em documentos, e da ferramenta Discussão, para discussões encadeadas, que fazem parte do espaço de trabalho Padrão, há várias outras ferramentas, entre as quais Calendário, Formulários, Acompanhamento de Questões, Reuniões, Bloco de Esboços e, é claro, a ferramenta Arquivos do SharePoint. Cada uma delas fornece recursos adicionais valiosos de colaboração. Para adicionar uma ferramenta, selecione o botão Adicionar uma ferramenta a este espaço de trabalho, no canto inferior direito do espaço de trabalho, e depois escolha aquela que deseja adicionar, conforme mostrado na Figura 3. Também é fácil excluir uma ferramenta quando você desejar.
Figura 3. Adicionando uma ferramenta ao espaço de trabalho do Groove (clique na imagem para exibi-la em tamanho maior)

Sincronizando o Groove e o SharePoint
Depois de adicionar a ferramenta Arquivos do SharePoint, você precisa definir a URL do site do SharePoint que contém a biblioteca de documentos com a qual você deseja fazer a sincronização. Para fazer isso, basta pressionar o botão Configuração, no espaço de trabalho do Groove, mostrado na Figura 4, depois de selecionar a guia Arquivos do SharePoint, na parte inferior da tela do espaço de trabalho.
Figura 4. Configurando a ferramenta Arquivos do SharePoint (clique na imagem para exibi-la em tamanho maior)
Depois de digitar a URL, você verá todas as bibliotecas disponíveis naquele site do SharePoint. Conforme mostrado na Figura 5, você deve, então, selecionar a biblioteca que deseja utilizar. O Groove se conectará e iniciará a sincronização automática. Isso significa que todos os documentos atualmente na biblioteca do SharePoint serão baixados e disponibilizados no espaço de trabalho do Groove. A Figura 6 mostra um exemplo.
Figura 5. Depois que você definir a URL, suas bibliotecas do SharePoint estarão disponíveis no Groove (clique na imagem para exibi-la em tamanho maior)
Figura 6. Sincronizando o Groove e o SharePoint (clique na imagem para exibi-la em tamanho maior)
Os documentos são exibidos como não lidos no espaço de trabalho do Groove porque acabaram de ser baixados. Observe que todos os arquivos sincronizados com o SharePoint tiram proveito do recurso de Check-in/check-out do SharePoint. Além disso, quando você faz check-out de um arquivo, garante que nenhum outro usuário possa fazer alterações enquanto você edita o documento.
Também é importante lembrar-se de que a ferramenta Arquivos do SharePoint permite a sincronização bidirecional. Então, se você adicionar arquivos à ferramenta Arquivos do SharePoint via Groove, eles serão sincronizados com a biblioteca de documentos do SharePoint. Embora a sincronização padrão seja definida para ocorrer automaticamente, você pode iniciar a sincronização manualmente, pressionando o botão Sincronizar Agora. Se fizer isso, você verá um resumo das alterações em todos os arquivos que exigem sincronização e uma ação associada, obter (do SharePoint) ou enviar (para o SharePoint), conforme mostrado na Figura 7.
Figura 7. Após a sincronização manual, você verá um resumo das alterações (clique na imagem para exibi-la em tamanho maior)
Um ponto importante a ser lembrado é que a ferramenta Arquivos implantada como parte do espaço de trabalho Padrão do Groove é diferente da ferramenta Arquivos do SharePoint. A ferramenta Arquivos do Groove não faz a sincronização com o SharePoint e, dependendo das suas necessidades, pode ser removida. Contudo, justamente por não ser sincronizada com o SharePoint, essa ferramenta pode ser usada como um local de armazenamento para arquivos temporários aos quais a equipe precisa ter acesso durante a execução de um projeto. Os arquivos armazenados ali continuarão sendo sincronizados entre os membros do espaço de trabalho.

Permitindo o acesso ao espaço de trabalho
Agora, com a infra-estrutura básica de colaboração já implantada, você pode começar a permitir o acesso de usuários ao espaço de trabalho. No entanto, primeiro é preciso convidá-los, o que pode ser feito usando o email ou o sistema de mensagens instantâneas do Groove. Como alternativa, o Groove permite exportar o convite para um arquivo. Esse arquivo, com uma extensão .grv, associada por padrão ao aplicativo Groove, pode ser entregue de alguma outra forma; por exemplo, pode ser colocado em um site para ser baixado pelo destinatário.
O sistema de mensagens instantâneas do Groove inclui verificações de segurança para garantir que o convite seja legível somente para o destinatário. Quando enviar o convite por email ou usar um arquivo de convite, marque sempre a opção Requerer confirmação da aceitação, para ter certeza de que o participante do seu espaço de trabalho é mesmo o convidado desejado. Isso proporciona uma camada adicional de segurança ao espaço de trabalho. Você também pode cancelar convites pendentes.
Ao convidar usuários para o espaço de trabalho, você precisa selecionar uma função para cada destinatário. As funções incluem Gerente, Participante e Convidado, e a designação padrão é de Participante. Cada função tem direitos específicos no espaço de trabalho e, como regra geral, você deve restringir a função de Gerente àqueles que realmente precisam de todos os direitos disponíveis, como a capacidade de excluir ferramentas. Os criadores do espaço de trabalho obtêm a função de Gerente por padrão. As funções atribuídas podem ser alteradas quando desejado.
Devido à natureza ad hoc do projeto neste artigo, a última tarefa seria excluir o espaço de trabalho do Groove quando tudo estivesse concluído.. Depois de verificar se o espaço de trabalho foi sincronizado com a biblioteca do SharePoint, você abriria o espaço de trabalho, iria até o menu Arquivo e escolheria Excluir Espaço de Trabalho. Então, você escolheria entre as opções de exclusão Deste Computador ou Para Todos os Membros (cada usuário tem uma cópia do espaço de trabalho em seu computador, que persiste indefinidamente, a não ser que você faça a exclusão para todos os membros).
O projeto culminaria em outra oportunidade para aproveitar a natureza complementar do Groove e do SharePoint. Após a sincronização final dos documentos, você estaria em uma situação ideal para tirar proveito das configurações das Políticas de Gerenciamento de Informações do SharePoint. A expiração de dados, especialmente, poderia ser habilitada para fornecer um método de gerenciamento automático dos dados arquivados.
Habilitar a expiração permite que você especifique o período pelo qual os dados serão retidos. Ao final desse período de retenção, o SharePoint poderá excluir automaticamente os dados ou iniciar um processo de fluxo de trabalho. Essa funcionalidade representa uma ótima forma de incorporar os dados do Groove à política de gerenciamento do ciclo de vida das informações da sua empresa. Você pode configurar a política de retenção de dados quando desejar. Na verdade, se não fez isso na configuração inicial da biblioteca, pode fazê-lo agora.
Para habilitar a expiração, selecione o menu Configurações na biblioteca de documentos e escolha o item de menu de configurações da biblioteca de documentos. Você verá, então, a opção de menu Configurações de Política de Gerenciamento de Informações, na seção Permissões e Gerenciamento da página. Depois de clicar no link Configurações de Política de Gerenciamento de Informações, você poderá especificar uma nova política personalizada definida por você, ou então optar por habilitar o uso da política definida no nível do site pela biblioteca de documentos.
Observe que, se você definir uma política personalizada, precisará digitar algumas informações de configuração. Por isso, no meu exemplo, você habilitaria a expiração, depois selecionaria um período de retenção e uma ação a ser realizada quando o período de retenção expirasse.
O Groove é um cliente avançado de colaboração projetado para fornecer uma estrutura dinâmica, intuitiva e segura para a colaboração ad hoc. Com seu conjunto de ferramentas avançado, o Groove proporciona uma plataforma de colaboração leve e adaptável, que pode ser facilmente utilizada dentro de uma organização ou entre organizações diferentes.
Se o SharePoint já fornece uma estrutura de gerenciamento de conteúdo e um conjunto de ferramentas de colaboração com solidez e potência para a sua empresa, certamente você descobrirá que a sua combinação com o Groove resultará em uma solução muito interessante. Os dois produtos são altamente complementares e, quando usados em conjunto, geram um ganho de produtividade considerável para as equipes de colaboração.﻿

Alan Maddison é consultor sênior da Strategic Business Systems, uma divisão da Brocade.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução total ou parcial sem permissão.


Administração do Windows
Introduzindo o Cluster de Failover do Windows Server 2008
Chuck Timon
Visão geral:
  • Snap-in Gerenciamento de Cluster de Failover
  • Novos recursos e aprimoramentos
  • Funcionalidade de backup e restauração
  • Migrando do Windows Server 2003

Conteúdo
Nova interface de gerenciamento
Processos de configuração aprimorados
Procedimento de validação incorporado
Novo modelo de quorum
Recursos de segurança aprimorados
Funcionalidade de sistema de rede expandida
Maior confiabilidade ao interagir com armazenamento
Processos de recuperação internos
Nova funcionalidade de backup e restauração
Migrando Clusters de Servidores do Windows Server 2003
Desde que o clustering foi introduzido no Windows NT 4.0 Enterprise Edition, os usuários reclamam que é muito difícil configurá-lo e muito pior mantê-lo. A administração de um cluster
exige que o administrador não apenas entenda o que é um clustering, mas também conheça as tecnologias de armazenamento e saiba como o serviço de cluster interage com as diversas soluções de armazenamento. Esse conjunto abrangente de habilidades necessário para colocar uma solução de alta disponibilidade em prática, e depois mantê-la, era difícil de encontrar em muitas organizações.
O clustering melhorou com os anos, mas ainda deixou muito a desejar quando a Microsoft começou a trabalhar no Windows Server® 2008. Com isso em mente, a equipe começou a recriar o clustering com o principal objetivo da simplicidade. No Windows Server 2008, o Microsoft® Cluster Services (MSCS) recebeu uma nova cara e agora é chamado de Cluster de Failover.
Isso não significa que simplicidade é a única coisa que a nova implementação do Cluster de Failover coloca em cena. Com os anos, a Microsoft aprendeu muitas lições, conforme as organizações forneceram comentários valiosos sobre o que gostariam de ver em uma solução de clustering atendida. A nova funcionalidade de Cluster de Failover trata de muitos dos principais problemas que os usuários relataram e também apresenta novos recursos interessantes que tornam essa proposta muito atraente. Assim, neste artigo, apresentarei alguns desses novos recursos interessantes que você encontrará no Cluster de Failover do Windows Server 2008.

Nova interface de gerenciamento
Depois de instalar o Cluster de Failover, a interface de gerenciamento de Cluster de Failover poderá ser acessada em Ferramentas Administrativas ou executando Cluadmin.msc. O snap-in Gerenciamento de Cluster de Failover, assim como outras interfaces de gerenciamento do Windows Server 2008, é um Microsoft Management Console (MMC) 3.0. Os veteranos em cluster, ao abrir o snap-in Gerenciamento de Cluster de Failover pela primeira vez, acharão que estão em um país estrangeiro sem nenhum mapa.
A nova interface é dividida em três painéis distintos, conforme mostrado na Figura 1. O painel esquerdo lista todos os Clusters de Failover do Windows Server 2008 em sua organização. O painel central fornece detalhes sobre a parte de uma configuração de cluster que você selecionou no painel esquerdo, e o painel direito mostra as ações que podem ser executadas.
Figura 1 Snap-in Gerenciamento de Cluster de Failover(clique na imagem para obter uma exibição ampliada)
Digamos, por exemplo, que você selecione Armazenamento no painel esquerdo. O painel central irá detalhar qual armazenamento foi provisionado no cluster e qual armazenamento, se houver, está disponível no momento. Como você pode ver na Figura 1, o cluster contém uma parte do armazenamento que oferece suporte a um disco testemunha, o armazenamento que foi provisionado para um Servidor de Arquivos e alguns armazenamentos disponíveis. O painel direito lista ações relevantes, como adicionar mais armazenamento. Observe que o snap-in Gerenciamento de Cluster de Failover não pode ser usado para administrar versões anteriores dos Serviços de Cluster da Microsoft.

Processos de configuração aprimorados
Configurar um Cluster de Failover é muito fácil. Muitas ações de configuração, reconfiguração e manutenção de um cluster possuem assistentes. Graças a eles, a administração não precisa mais se preocupar em saber se os recursos estão configurados corretamente ou se serão colocados online na ordem correta.
A Figura 2 mostra o Assistente para Alta Disponibilidade. Neste exemplo específico, um Servidor de Arquivos foi configurado. À esquerda, é possível ver a lista de etapas que o assistente apresentou ao administrador. Assim que o processo é concluído, uma página de resumo e um relatório são exibidos.
Figura 2 Assistente para Alta Disponibilidade (clique na imagem para obter uma exibição ampliada)

Procedimento de validação incorporado
Nas versões anteriores do Windows Server, que devemos considerar uma solução de cluster com suporte, as configurações de hardware tiveram de ser listadas como uma Solução de Cluster no Windows Server Catalog. Ele incluía clusters multissite, que foram listados separadamente na categoria Geographically Dispersed. A serem listados no catálogo, os fornecedores de hardware tiveram de executar um conjunto de testes do WHQL (Windows Hardware Quality Lab) e enviar os resultados à Microsoft. Foi uma proposta dispendiosa para o fornecedor, e o banco de dados do Windows Server Catalog era difícil de manter.
No Windows Server 2008, um processo de validação interno foi incluído no Cluster de Failover. Esse processo consiste em uma série de testes agrupados em quatro categorias principais, conforme mostrado na Figura 3.
Figura 3 Categorias do teste de validação de Cluster de Failover(clique na imagem para obter uma exibição ampliada)
Como você pode ver, a categoria Rede está expandida para mostrar os testes executados; cada categoria contém uma série de testes. A categoria Armazenamento, que talvez seja a mais crítica das quatro categorias, inclui testes que garantem que as soluções de armazenamento atendam aos novos requisitos que entraram em vigor para os Clusters de Failover do Windows Server 2008.
Especificamente, os fornecedores de hardware agora devem usar drivers baseados no driver Microsoft Storport e devem oferecer suporte às Reservas Persistentes SCSI-3. Além disso, os Módulos Específicos de Dispositivo de software de múltiplos caminhos, quando usados, devem se basear no padrão Microsoft MultiPath I\O.
Com a incorporação do processo de validação, o modelo de suporte foi alterado. Todo hardware deve ter um logotipo do Windows Server 2008 e todos os testes de validação devem ser aprovados. As únicas exceções são os clusters multissite que possuem dois compartimentos de armazenamento separados e distintos (um de cada lado) e a implementação de replicação contínua do Exchange Server 2007, que não usa nenhum armazenamento compartilhado.

Novo modelo de quorum
O Modelo de Quorum também foi alterado no Cluster de Failover do Windows Server 2008. Nos sistemas anteriores, quando um administrador ouvia a palavra quorum, imaginava um disco compartilhado no qual a configuração de cluster e alguns arquivos replicados residiam. Era um ponto único de falha no cluster. Se o disco de quorum falhasse, o serviço de cluster era encerrado e a alta disponibilidade era perdida.
Os Clusters de Servidores do Windows Server 2003 ofereciam um segundo tipo de quorum chamado Conjunto de Nós Principais. Esse tipo de quorum, em geral, era implementado em clusters multissite e não exigiam nenhum armazenamento compartilhado. O quorum Conjunto de Nós Principais consistia em um compartilhamento de arquivos que residia na unidade do sistema em cada nó de cluster. As conexões com esse tipo de quorum eram feitas por meio do protocolo SMB. Novamente, para que o cluster funcionasse, a maioria dos nós tinha de participar.
Depois, com a introdução da CCR (replicação contínua em cluster) do Exchange Server 2007, o recurso FSW (testemunha de compartilhamento de arquivos) foi adicionado aos Clusters de Servidores do Windows Server 2003. Ele permitia que um único nó de cluster CCR do Exchange 2007 (ou qualquer cluster multissite) continuasse a fornecer serviços enquanto uma conexão com o FSW resultasse na participação da maioria.
No Cluster de Failover do Windows Server 2008, o conceito de quorum agora significa consenso. O quorum, ou consenso, é alcançado obtendo votos suficientes para ativar o serviço do cluster. É possível obter votos suficientes de diversas maneiras, dependendo da configuração de quorum. Há quatro modos de quorum disponíveis em um Cluster de Failover do Windows Server 2008 e eles são mostrados na Figura 4. Dos quatro modelos listados, somente os dois primeiros (Maioria dos Nós e Maioria dos Nós e Discos) podem ser selecionados automaticamente durante o processo de criação de cluster. A seguinte lógica deve ser usada:
  • Se um número ímpar de nós for configurado no cluster, selecione o modo Maioria dos Nós.
  • Se um número par de nós for configurado no cluster e o armazenamento compartilhado estiver conectado e acessível, selecione Maioria dos Nós e Discos.
Figura 4 Modos de quorum no Assistente para Configurar Quorum do Cluster (clique na imagem para obter uma exibição ampliada)
Para selecionar um disco de testemunha do armazenamento disponível, selecione o primeiro disco contendo pelo menos 500 megabytes de tamanho e uma partição NTFS configurada. Os modos de quorum restantes só podem ser selecionados manualmente, executando o Assistente para Configurar Quorum do Cluster. A opção Maioria dos Nós e Compartilhamentos de Arquivos, em geral, é usada em uma configuração de cluster multissite ou em um cluster CCR do Exchange 2007. A última opção, o modo Sem Maioria: Somente Disco, é equivalente ao modelo de quorum compartilhado em clusters herdados. É um ponto único de falha e, se possível, não deve ser usada.
Há apenas dois tipos de recursos de testemunha, um disco físico e um compartilhamento de arquivo, que pode ser configurado no cluster para ajudar a alcançar o consenso.
Um disco de testemunha é uma parte do armazenamento que o serviço de cluster pode colocar online. Esse disco está localizado no Grupo Recursos Principais de Cluster com o Nome da Rede e os recursos de endereço IP associados. Quando o disco de testemunha é configurado, uma pasta Cluster é colocada no disco e uma cópia completa da configuração do cluster (um hive ou réplica do cluster) também é colocada no disco.
Um FSW é um compartilhamento de rede localizado, em uma situação ideal, em um servidor na rede que não faça parte do cluster. Uma conexão SMB é feita com o FSW, que mantém uma cópia do arquivo de log de testemunha contendo informações sobre versão para a configuração do cluster.
Só pode haver um recurso de testemunha configurado em um cluster. Esse recurso fornece um voto extra caso o cluster precise disso para alcançar o quorum. Em outras palavras, se faltar um voto (e portanto um nó) para o cluster alcançar um consenso, o recurso de testemunha será colocado online para que o quorum seja alcançado. Se faltar mais de um voto para o cluster alcançar o quorum, o recurso de testemunha será abandonado e o cluster permanecerá em um estado inativo, aguardando a junção de outro nó de cluster.

Recursos de segurança aprimorados
Os Clusters de Failover apresentam vários novos aprimoramentos de segurança. Talvez o mais significativo envolva a remoção do requisito de uma CSA (conta de serviço de cluster). Nas versões anteriores do Microsoft Cluster Service, uma conta de usuário de domínio era necessária durante o processo de configuração. Essa conta, que foi usada para iniciar o serviço de cluster, foi adicionada ao grupo de administradores locais em cada nó do cluster, obtendo os direitos de usuário local necessários para permitir que o serviço de cluster funcionasse corretamente. Como uma conta de usuário de domínio, a CSA estava sujeita a várias diretivas no nível de domínio que podiam ser aplicadas aos nós de cluster. Essas diretivas podiam afetar negativamente a alta disponibilidade causando uma falha no serviço de cluster.
O serviço de cluster agora é executado sob uma conta do sistema local com um conjunto específico de direitos no nó do cluster local que permite que ela funcione adequadamente. O contexto de segurança para o cluster foi transferido para o CNO (objeto de nome de cluster), que é o objeto do computador criado, por padrão, no contêiner Computadores do Active Directory® assim que o cluster é criado. Quando um cluster é criado com êxito e o CNO existe no Active Directory, a conta de usuário usada para instalar e configurar o cluster se torna desnecessária.
Os objetos de computador adicionais criados no Active Directory do contêiner Computadores são adicionados a um Cluster de Failover. Esses objetos, chamados de VCOs (objetos de computador virtual), se equiparam aos recursos Nome de Rede do cluster que é criado como parte dos CAPs (pontos de acesso do cliente) no cluster. O CNO, que é responsável por criar todos os VCOs em um cluster, é adicionado à SACL (lista de controle de acesso do sistema) para o objeto no Active Directory (consulte a Figura 5).
Figura 5 Segurança em um VCO no Active Directory (clique na imagem para obter uma exibição ampliada)
O CNO também assume a responsabilidade de sincronizar as senhas de domínio para todos os VCOs que ele criou. Esse processo é realizado de acordo com a diretiva de domínio configurada para a rotação de senha. Além disso, como o CNO é responsável por criar todos os objetos do computador associados aos VCOs em um cluster, o CNO (Conta de Computador) deve ter o direito no nível de domínio para criar objetos de computador no contêiner em que os VCOs são criados (por padrão, no contêiner Computadores).
Outra alteração é que o Kerberos agora é usado como o método de autenticação padrão. A existência de contas de computador no Active Directory permite esse recurso de segurança aprimorado. Mas o cluster possui a capacidade de usar a autenticação do protocolo NTLM sempre que um aplicativo que não pode usar Kerberos na autenticação precisa acessar os recursos de cluster.
A comunicação entre os nós de cluster que lidam diretamente com o processo de cluster também é mais segura. Toda a comunicação dentro do cluster é assinada por padrão. Usando a CLI (interface de linguagem comum) cluster.exe, essa propriedade do cluster pode ser alterada para que toda comunicação entre os nós seja criptografada para fornecer um nível de segurança adicional.

Funcionalidade de sistema de rede expandida
Os novos recursos de sistema de rede nos Clusters de Failover fornecem mais flexibilidade ao criar soluções de alta disponibilidade e recuperação de desastre. Ao mesmo tempo, esses novos aprimoramentos de sistema de rede fornecem uma conectividade mais confiável entre os nós no cluster.
Provavelmente, o recurso de cliente mais solicitado foi a capacidade de localizar nós de cluster em redes separadas. Agora isso é possível. O driver de rede de cluster foi completamente reescrito para fornecer uma comunicação tolerante a falhas altamente confiável entre os nós de um cluster, desde que cada nó esteja conectado a pelo menos duas redes separadas e roteadas de forma distinta.
O driver de rede de cluster constrói sua própria tabela de roteamento interno com base nas informações de conectividade fornecidas durante o processo de inicialização de cluster. Isso inclui as informações de conectividade local bem com as que são fornecidas no banco de dados de configuração de cluster (hive do registro de cluster).
Parte do processo de validação de cluster inclui um processo de descoberta de conectividade de rede. A capacidade de localizar nós de cluster em redes roteadas diferentes diminuiu os requisitos do sistema de rede para clusters multissite. Ela tornará sua implantação mais fácil e menos dispendiosa para as organizações. Além disso, ela usa o armazenamento iSCSI, uma solução de armazenamento atraente para uso em Clusters de Failover.
Os nós de cluster também podem obter informações do Endereço IP por meio do protocolo DHCP. Isso poderá diminuir o trabalho dos administradores de rede, caso aceitem o uso de endereçamento dinâmico para os servidores no seu ambiente.
A configuração de interfaces de rede de um nó de cluster determina as redes que usarão endereços IP estáticos ou dinâmicos. Mesmo que um recurso de endereço IP em um cluster seja obtido de um servidor DHCP, ele poderá ser alterado para um endereço IP no snap-in Gerenciamento de Cluster de Failover.
No passado, toda comunicação de cluster usava a difusão do protocolo UDP e, às vezes, multicast. A funcionalidade multicast foi descontinuada e as comunicações de cluster agora usam UDP unicast (3343 ainda é a porta comum usada pelos clusters da Microsoft). Muitos administradores de rede ficarão felizes ao ver que a difusão não é mais usada. A verdadeira compensação em um cluster, porém, tem a ver com os novos processos de mensagens que são internos do próprio serviço de cluster (isso, contudo, está além do escopo deste artigo). As comunicações dentro do cluster agora possuem características de comunicação TCP mais confiáveis, muito embora UDP seja usado como mecanismo de transporte.

Maior confiabilidade ao interagir com armazenamento
A forma como os Clusters de Failover interagem com o armazenamento é totalmente diferente. O driver de disco do cluster (clusdisk.sys) foi completamente reescrito e agora é um verdadeiro driver Plug and Play (PnP). Além disso, a forma como ele interage com o armazenamento mudou.
No Windows Server 2003, o driver de disco do cluster ficava em um caminho direto até o armazenamento. Mas, no Windows Server 2008, o driver de disco do cluster se comunica com o driver do gerenciador de partições (partmgr.sys) para interagir com o armazenamento. Essas duas abordagens são ilustradas na Figura 6.
Figura 6 Como a pilha do armazenamento foi alterada no Windows Server 2008 (clique na imagem para obter uma exibição ampliada)
O gerenciador de partições tem como responsabilidade principal proteger os recursos de disco do cluster. Todos os discos em um barramento de armazenamento compartilhado são colocados automaticamente em um estado offline assim que são mapeados para um nó de cluster. Isso permite que o armazenamento seja mapeado simultaneamente para todos os nós em um cluster antes mesmo que o cluster seja criado. Não é mais necessário que os nós sejam iniciados individualmente, os discos preparados em um nó e depois o nó desligado, outro nó iniciado, a configuração de disco verificada, e assim por diante.
Ainda há, contudo, os testes de armazenamento, que são executados como parte do processo de validação de cluster e exigem que os discos sejam inicializados. Isso pode ser feito em um dos nós do cluster antes que o processo de validação seja executado. Assim que o armazenamento é adicionado a um cluster, os discos mostram um status Reservado na interface de Gerenciamento de Disco e nunca ficam em um estado desprotegido.
Outra alteração tem a ver com os comandos SCSI. No Windows Server 2003, os comandos SCSI-2 Reserve\Release eram usados com o driver de disco de cluster gravando em setores no próprio disco. No Windows Server 2008, os comandos SCSI-3 PR (Reserva Persistente) são necessários. Os nós de cluster devem ser registrados antes de poder colocar uma reserva no armazenamento, e os nós de cluster periodicamente defendem suas reservas usando o Protocolo de Registro e Defesa.
Um dos testes de armazenamento no processo de validação verifica essa funcionalidade. Se a solução de armazenamento não oferecer suporte aos comandos SCSI-3 (PR) é porque não possui suporte em um Cluster de Failover.
Muitas organizações usam software de múltiplos caminhos para redundância ao se conectar ao armazenamento. É uma solução com suporte e até mesmo divulgada como prática recomendada. Entretanto, as soluções de software de múltiplos caminhos de terceiros, ou módulos específicos de dispositivo, devem ser reescritas usando o padrão Microsoft MultiPath I\O para obter suporte em um Cluster de Failover. Isso garante que todos os comandos SCSI-3 PR sejam enviados simultaneamente por todos caminhos até o armazenamento, quer os caminhos estejam ativos ou não. Essa funcionalidade também é verificada como parte do processo de validação.
Os aprimoramentos de armazenamento adicionais incluem um processo de disco de verificação aprimorado (chkdsk.exe), a funcionalidade interna de reparo de disco que antes fazia parte do Utilitário de Recuperação do Servidor de Cluster e discos de auto-recuperação. Nos Clusters de Failover, a assinatura do disco e o LUN ID são usados ao identificar um recurso de disco do cluster. Se um deles for alterado, a configuração de cluster será atualizada. Isso significa menos erros por causa de uma simples alteração de atributo em um recurso de disco físico resultando em ainda mais disponibilidade.

Processos de recuperação internos
O reparo de disco mencionado anteriormente, sem dúvida, é um dos recursos internos de recuperação. Outro recurso é o Reparo do Active Directory. Se o objeto de computador que representa o CNO for excluído, você não poderá mais criar os objetos de computador associados aos CAPs do cluster. Entretanto, o primeiro problema surgirá provavelmente quando os aplicativos de alta disponibilidade ou os usuários não ganharem acesso aos recursos fora do cluster porque um token de segurança não pode ser obtido.
A recuperação de um CNO excluído é um processo de duas etapas. Primeiro, você deve fazer um Administrador de Domínio recuperar o objeto de computador excluído do contêiner DeletedObjects no Active Directory. Então, depois que o objeto for restaurado e reabilitado, você deverá executar o processo Reparar Objeto do Active Directory no snap-in Gerenciamento de Cluster de Failover.
Nos Clusters de Servidores do Windows Server 2003, havia uma possibilidade de que o arquivo de configuração de cluster localizado no subdiretório %systemroot%\cluster se tornasse corrompido e tivesse de ser substituído. Nos Clusters de Failover, o recurso de auto-recuperação pode ajudar. Se o serviço de cluster for iniciado em um nó e o banco de dados de configuração for corrompido, um modelo de configuração mínima será carregado usando as informações contidas na chave de registro HKLM\System\CCS\Services\ClusSvc\Parameters. O nó tentará se unir a um cluster já formado e, se essa tentativa tiver êxito, uma cópia nova do hive do registro de cluster será enviada por push ao nó. Se um nó não puder se unir a um cluster, o serviço de cluster será encerrado.

Nova funcionalidade de backup e restauração
O Cluster de Failover vem com seu próprio gravador Serviço de Cópias de Sombra de Volume. Ele exerce uma função importante ao fazer backup e restaurar um banco de dados de clusters e os dados que residem nos recursos do disco físico. O backup da configuração de cluster é muito simples. Contanto que o estado do sistema faça parte de um backup, a configuração de cluster poderá ser restaurada. Mas observe que só será possível fazer backup de um cluster se ele tiver quorum. Isso garante que seja feito o backup da configuração de cluster mais atualizada.
Há dois tipos de restauração de cluster distintos: autoritativo e não-autoritativo. Uma restauração não-autoritativa usa o Backup do Windows Server ou um aplicativo de backup de terceiros para executar uma restauração de um backup selecionado. Uma restauração autoritativa de um nó de cluster, entretanto, só pode ser realizada usando o CLI (wbadmin.exe) de Backup do Windows Server.
Uma restauração autoritativa basicamente "volta no tempo" e usa a configuração de cluster existente quando o backup foi executado. Para realizar uma restauração autoritativa, o serviço de cluster é interrompido em todos os nós, exceto naquele no qual a restauração está sendo executada. Assim que a restauração é concluída e o serviço de cluster iniciado no nó restaurado, a configuração restaurada do cluster se torna a nova configuração de cluster definitiva. Assim, quando o serviço de cluster é reiniciado nos nós restantes do cluster, a configuração restaurada é enviada por push durante o processo de junção.
Esse procedimento pode economizar bastante tempo e dinheiro em alguns cenários. Suponha que você tem um cluster de impressão que hospeda vários recursos de spooler de impressão, cada um oferecendo suporte a 1.500 impressoras, e acidentalmente exclui um deles. Agora, um grande número de usuários não poderá imprimir. Em vez de adicionar manualmente todas as impressoras à configuração de cluster, é muito mais rápido realizar uma restauração autoritativa da configuração de cluster. Isso, é claro, se você tiver uma boa estratégia de backup e restauração.

Migrando Clusters de Servidores do Windows Server 2003
Devido a todas essas alterações de arquitetura no Cluster de Failover do Windows Server 2008, não há suporte para atualizações sem interrupção ou in-loco do Windows Server 2003. Ao atualizar clusters do Windows Server 2000 para o Windows Server 2003, muitas organizações deveriam remover sistematicamente cada nó no cluster, fazer uma instalação limpa do sistema operacional e, depois, adicionar o nó ao cluster. Essa abordagem não pode ser usada para migrar para o Windows Server 2008, pois os nós de cluster do Windows Server 2003 e do Windows Server 2008 não fazem parte do mesmo cluster.
Felizmente, para ajudar na migração, foi incluído um processo de migração baseado em assistente. Mas a migração para um Cluster de Failover do Windows Server 2008, ainda assim, exigirá um planejamento. Há três cenários de migração básicos:
  • Usando os mesmos servidores e armazenamento.
  • Usando os mesmos servidores, mas com novo armazenamento.
  • Usando novos servidores e novo armazenamento.
Qualquer um desses cenários exige que o hardware seja certificado com o programa de logotipo do Windows Server 2008 e que o processo de validação do Cluster de Failover seja executado e todos os testes aprovados. Depois de concluir essas etapas, o processo de migração pode continuar.
Nem todos os recursos em um Cluster de Servidores do Windows Server 2003 podem ser migrados. Você pode migrar nomes de rede, endereços IP, discos físicos, compartilhamentos de arquivo, raízes DFS (compartilhamento de arquivo distribuído), DHCP e WINS. Você também pode migrar, até um limite, serviços, aplicativos e recursos de script genéricos.
Enquanto isso, aplicativos como o Microsoft Exchange e o SQL Server® possuem seus próprios procedimentos para migrar para um Cluster de Failover. As impressoras podem ser migradas para o Windows Server 2008 usando o snap-in Gerenciamento de Impressão (que é instalado com a Função de Servidor de Impressão) para primeiro exportar e depois importar impressoras para um servidor de impressão altamente disponível e recentemente configurado. Nenhum tipo de recurso de terceiros é qualificado para migração.
O processo de migração não migra nenhum dado. Ele envolve a migração das definições da configuração de cluster do Windows Server 2003 para o Windows Server 2008.
Todos os recursos migrados são colocados inicialmente em um estado offline quando o processo de migração é concluído. Isso é feito porque pode haver outras etapas necessárias. Portanto, é importante revisar o relatório de pós-migração para ver quais etapas adicionais (exclusivas da migração de dados se for para um novo armazenamento) são necessárias antes de colocar o cluster em serviço. Como exemplo, se um servidor DHCP for migrado, a Função de Servidor DHCP deverá ser instalada em todos os nós no cluster. Ao migrar um Servidor WINS, o recurso Servidor WINS deverá ser instalado em todos os nós no cluster.

Chuck Timon é engenheiro de escalonamento de suporte da Microsoft e oferece suporte a tecnologias de Cluster e Configuração. É autor do curso de Cluster de Failover do Windows Server 2008 e atualmente está desenvolvendo o curso sobre Hyper-V.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.


Do editor Impressão em papel já era
Joshua Hoffman

Impressão em papel já era. Pelo menos, é o que muitos pensam. Na era da informação ilimitada — disponível em todos os formatos, a todo momento, de qualquer lugar, em uma gama fantástica de dispositivos —, qual a situação real de um maço de folhas de papel grudadas com cola? Seria coisa do passado? As revistas e os jornais estariam relegados às paredes de um museu, para que um dia possamos nos encher de nostalgia ao lembrar da sensação de carregar conosco partes comprimidas de árvore e tinta?
Muito melodramático? Sim, mas tenho certeza de que você adivinhou de qual premissa discordo totalmente (e não apenas porque estou pensando no meu emprego; há muitas coisas que poderia estar fazendo na Microsoft). Acredito firmemente na idéia de que a palavra impressa fornece uma experiência extremamente enriquecedora e profunda, apesar (ou talvez por causa) de sua simplicidade. Quando me sento para ler um longo artigo, prefiro sempre estar com uma publicação impressa na mão do que diante da tela do meu computador. Acho muito mais prazeroso. Será que sou antiquado? Talvez, mas, de acordo com a nossa última pesquisa com os leitores, 90% das pessoas pensam como eu.
Agora, não estou sugerindo que enfiemos a cabeça num buraco no chão. Sou um nerd de primeira linha e adoro tecnologia. Contudo, uma publicação como a nossa pode, e deve, ser uma experiência holística, que assume diversos formatos: online, offline e em pessoa. Obviamente, se for ler um artigo técnico, extenso e profundo de Mark Russinovich, prefiro que seja impresso, mas também quero poder assistir a uma palestra sua e vê-lo demonstrar as técnicas que ensina.
Essa idéia tornou-se um princípio orientador para a TechNet Magazine. Embora ainda nos orgulhemos da publicação que enviamos à impressora todo mês, todo o conteúdo impresso que já publicamos também está disponível em .com. E, em breve, você terá mais conteúdo que aproveita os benefícios da plataforma exclusiva disponível para nós na Internet. Por exemplo, em nossa última edição, lançamos a série Screencast com Don Jones e sua coluna do Windows PowerShell. Agora, você pode assistir ao vídeo de Don falando sobre o tópico da coluna daquele mês. Também tem a nova coluna Computação Sustentável no site que é totalmente dedicada ao impacto ambiental de TI e a tudo o que os profissionais dessa área podem fazer para se tornar cidadãos globais responsáveis.
Como sempre, sua opinião é essencial para continuarmos a transformar a TechNet Magazine em uma rica experiência de mídia. Envie um email para tnmag@microsoft.com.
– Joshua Hoffman

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Ed Banti, Avronil Bhattacharjee, Nino Bilic, Mai-lan Tomsen Bukovec, Eric Charran, Elden Christensen, Trina Gorman, Scott Landry, Michael Murgolo, Sanjeev Nair, Hugh Pyle, Amritansh Raghav, Jez Sadler e Jim Truher.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida.


Cartas Com a palavra, os leitores

Serviços de Domínio Active Directory
Gostei muito da edição de março de 2008 da TechNet Magazine. Acho que já li a revista umas 12 vezes! Gostei especialmente do artigo "Novidades no AD DS (Serviços de Domínio Active Directory)", de Gil Kirkpatrick. No artigo, Gil menciona um produto chamado Microsoft® Audit Collection Services. Esse produto já está disponível e funciona como aplicativo autônomo?
― Erasmo M.

O Microsoft ACS (Audit Collection Services) faz parte do SCOM (System Center Operations Manager), o software de gerenciamento anteriormente conhecido como MOM (Microsoft Operations Manager). Não está disponível como um produto autônomo, apenas como parte do SCOM.
— Gil Kirkpatrick, diretor de tecnologia (CTO) da NetPro e autor da TechNet Magazine

Assinaturas
No segundo parágrafo da coluna sobre o Windows PowerShell, na edição de abril de 2008 da TechNet Magazine ("Assine aqui, por favor" technet.microsoft.com/magazine/cc434702), o autor Don Jones afirma: "A palavra assinatura é o termo técnico correto para o assunto sobre o qual estou falando, embora a palavra propriamente dita não seja uma boa descrição do que está acontecendo aqui. Assinar um script não significa que você o está aprovando ou autorizando, como o faria com um contrato ou com uma guia de cartão de crédito."
Eu argumentaria que assinar um contrato ou uma guia de cartão de crédito também não significa necessariamente aprovar ou autorizar esses itens. A ação realizada só é significativa no contexto de uma visão mais ampla do ambiente. Por exemplo, quando eu era mais jovem, brinquei com guias de cartão de crédito na estação de trabalho do meu pai, e ninguém jamais tentou cobrar os "débitos" gerados por essas transações.
No contexto de uma implementação de rede do Active Directory® "configurada adequadamente", a assinatura é exatamente o que autoriza o script a operar. A presença da assinatura indica que o signatário aceita a responsabilidade pelo item assinado, e que a presença da assinatura pode disparar atividades adicionais — a cobrança pela empresa de cartão de crédito ou a aceitação do código como autêntico pela rede.
Continuem com o bom trabalho — a TechNet Magazine traz grandes benefícios.
— Jeremy P.

Agradecemos seus comentários, Jeremy. É bom saber que nossos leitores dedicam tamanha atenção e exercem seu senso crítico sobre o que a TechNet Magazine tem a dizer.

SharePoint Services
Ao executar o WSS (Windows® SharePoint® Services) — não o Microsoft Office SharePoint Server — são necessárias licenças CAL adicionais para usuários que o acessam por meio de uma interface de site da Web/URL?
— Douglas M.

Há alguns documentos disponíveis sobre o assunto. Eis alguns links úteis: msmvps.com/blogs/cgross/archive/2005/04/02/40723; microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx; e windowsserver/sharepoint/bb684457.
— Pav Cherny, autor da coluna "Explorando o SharePoint", da TechNet Magazine

Idéia para a coluna "Explorando o SharePoint"
Li recentemente a coluna sobre o SharePoint, na edição de maio de 2008 da TechNet Magazine (technet.microsoft.com/magazine/cc462809). Vocês pediram aos leitores sugestões de novos assuntos. Um artigo abrangente sobre a integração do SharePoint com o Project/Project Server seria ótimo.
— Phil H.

O Project/Project Server é uma ótima idéia! Certamente levaremos esse assunto em consideração para uma futura coluna. Agradecemos sua resposta.

Outras idéias para a coluna "Explorando o SharePoint"
A Web, como um todo, contém uma infinidade de documentos sobre a personalização de sites usando a interface do usuário padrão do SharePoint ou o SharePoint Designer, mas há muito pouco conteúdo sobre definições de site (e os artigos existentes são tão básicos que apresentam pouca utilidade diante de problemas reais). Como muitas pessoas estão começando a explorar essa área, diversos guias passo-a-passo poderiam incentivar a adoção do SharePoint. Na minha empresa, especificamente, tivemos dificuldade com os seguintes tópicos:
  1. Como configurar permissões personalizadas para listas em uma definição de site.
  2. Formulários de itens de listas personalizadas em uma definição de site.
  3. Conexões de Web Parts a partir de uma definição de site.
  4. Como uma definição de site pode ser fornecida de forma incremental.
— Adam C.

Agradecemos suas sugestões. É exatamente o tipo de comentário do leitor que levaremos em conta à medida que continuarmos a desenvolver esse conteúdo.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução total ou parcial sem permissão.


Toolbox Novos produtos para profissionais de TI
Greg Steen

Automatize as tarefas administrativas
Automise 2
automise.com/automise.aspx
As tarefas repetitivas que não exigem reflexão costumam ser tediosas, trabalhosas e sujeitas a erros. Automatizar esse tipo de tarefa é fundamental para uma administração bem-sucedida e pode aumentar a satisfação com o trabalho. Além da opção desagradável de usar arquivos em lote e VBScripts personalizados para automatizar suas tarefas, há diversos utilitários semelhantes a macros para o Windows®, e até mesmo alguns utilitários que obrigam você a aprender uma determinada linguagem de script personalizada. Mas existe uma outra opção. Com o Automise 2, da VSoft Technologies, você gera rotinas de automação com uma interface gráfica do usuário que permite a personalização com as funções de arrastar e soltar.
A interface do aplicativo é muito semelhante a um IDE simples de programação, com opções familiares. Você conta com uma caixa de ferramentas a partir da qual pode arrastar itens para a superfície de design, controles de depuração que permitem percorrer seu código, uma exibição dos seus diversos projetos, logs de execução de saída, histórico e janelas de propriedades. Mas, com o Automise, seu "código" é, na verdade, uma representação visual do fluxo de trabalho automatizado.
A caixa de ferramentas do Automise consiste em ações, cada uma das quais executa uma única etapa no processo de automação. Há 380 ações incluídas no aplicativo, que abrangem toda a gama de possíveis operações, desde a criação de arquivos .zip até a reinicialização do IIS.
Quando você projeta sua tarefa, pode estruturar essas ações de forma hierárquica para incluir vários processos administrativos executados regularmente. Além disso, é possível conectar suas ações com controles de fluxo, como blocos try/catch, levantamento de exceções, instruções if-then-else, loops, opções, atrasos e grupos de ações assíncronas.
Cada projeto de automação pode incluir outros projetos, permitindo que você separe seu fluxo mestre de controle das subtarefas. Há também ações para manipular cadeias de caracteres e dados XML; definir variáveis; aguardar processos e comandos; e muito mais. Com todas essas opções de fluxo de controle, é possível automatizar até mesmo operações complexas.
O Automise permite criar, executar, editar e excluir tarefas agendadas. Isso significa que você também pode usar o Automise para gerenciar seus processos já existentes. Não há espaço suficiente aqui para relacionar todas as ações, mas eis algumas que merecem destaque: ações para registrar uma DLL no GAC (cache de assembly global), recompilar os índices do SQL Server®, executar o chkdsk, editar o Registro, fazer backup do log de eventos, editar os usuários do Active Directory®, montar volumes, criar pontos de restauração e criar um diretório virtual. E, se as ações internas não forem capazes de fazer o que você deseja, o Automise conta com ações personalizadas de script, comando e execução ad hoc do SQL.
No fim das contas, é muito útil ter essa ferramenta à sua disposição. E, se você quiser apenas automatizar a sua estação de trabalho Windows, em vez de toda a infra-estrutura de rede, convém avaliar o Automise Lite, que não tem todos os recursos da versão completa, mas dará conta da maioria das necessidades de um usuário avançado.
Preço: licença para um usuário a partir de US$ 195 (para venda direta).
Automatize tarefas visualmente com o Automise 2 (clique na imagem para ampliá-la)

Monitore logs em tempo real
BareTailPro
baremetalsoft.com/baretailpro
Os arquivos de log estão em toda parte! Mas a verdadeira questão é como fazer para usá-los. É ótimo que seu aplicativo produza um log de transações. Mas, além de usar suas ferramentas de agregação de logs, como você pode realmente acompanhar o que ocorre em tempo real? Uma solução é o BareTailPro, produto testado e aprovado da Bare Metal Software. Embora não seja atualizado desde 2006, esse utilitário simples continua a ser um produto análogo aprimorado e para Windows do antigo comando *nix "tail -f" para consoles.
A interface gráfica do usuário simples permite observar simultaneamente vários arquivos de log de qualquer tamanho, vendo o que é gravado neles de forma transparente e em tempo real. Para alternar entre os arquivos, basta clicar na guia. E um recurso muito interessante é que cada guia exibe um ícone sinalizando o estado de cada arquivo de log, indicando se há alguma gravação sendo feita no arquivo ou se a parte final foi interrompida.
Embora a maioria dos aplicativos gere logs, a forma como fazem isso costuma variar muito. Felizmente, o BareTailPro é capaz de ler arquivos Unicode, UTF-8, ANSI e ASCII, e pode lidar até mesmo com linhas terminadas em pares CR/LF, LFs únicos e nulos. Você pode configurar facilmente a disposição das linhas e a expansão da tabulação, a fim de obter a melhor exibição para aquele tipo específico de log. Pode, ainda, melhorar a legibilidade do arquivo de log, configurando o tamanho da fonte, o tipo, o espaçamento e a altura da linha.
Outro ótimo recurso é o realce configurável do aplicativo, que você pode aplicar à exibição de um log. Você pode definir qualquer número de regras de codificação de cores de primeiro e segundo plano, com base em uma cadeia de texto. Por exemplo, é possível realçar os erros em vermelho e os avisos em amarelo, ou então optar por realçar todas as linhas com referências a um endereço de IP ou a um host específico. Você pode especificar as linhas como negrito ou itálico e escolher se deseja ignorar as letras maiúsculas e minúsculas da sua cadeia de texto.
Mesmo usando o realce de texto, um arquivo de log agressivo pode sobrecarregar sua exibição da parte final do log, dificultando a localização dos eventos que você procura. O BareTailPro oferece um outro recurso capaz de ajudá-lo. A funcionalidade de pesquisa de expressões regulares e de texto permite reduzir rapidamente a exibição do log, isolando as instâncias de linha dignas de atenção em um subconjunto gerenciável. A sintaxe de expressões regulares usada pelo BareTailPro consiste em um subconjunto da notação padrão usada por Java, Perl e PHP. Caso você não esteja familiarizado com essa utilização, o site do produto conta com um guia de referência rápida.
O utilitário mostra os resultados filtrados em um formato tabular, acrescentando algumas colunas úteis, como um carimbo de data/hora, o número da linha e os resultados de todos os grupos de captura que você tenha definido, juntamente com a linha original. Na exibição filtrada, essas colunas também podem ser classificadas.
Nunca consigo me lembrar da sintaxe da expressão regular "mágica" com a qual obtive os resultados de que precisava. Por isso, gosto muito do recurso de salvamento de padrões da ferramenta. Ele permite nomear, editar e salvar padrões para reutilização. Quando você já tiver suas linhas importantes na exibição filtrada, o BareTailPro permitirá exportar esses resultados para um arquivo ou para a área de transferência em um formato personalizado. Com isso, você poderá definir aspectos como a largura, o alinhamento, o prefixo e o sufixo de cada coluna dos resultados.
É impressionante que esse utilitário compacto esteja contido em um único e pequeno arquivo executável. Isso o torna portátil e de baixo impacto sobre o seu ambiente. Se você quiser apenas observar seus arquivos de log e não precisar da filtragem de expressões regulares, do salvamento de padrões de pesquisa e da exportação dos resultados de pesquisa e filtragem, pode ser que a versão gratuita, chamada BareTail, atenda às suas necessidades.
Preço: a partir de US$ 35 para uma licença individual.
Monitore sua rede com o BareTailPro (clique na imagem para ampliá-la)

Faça o inventário dos seus sistemas
Total Network Inventory
softinventive.com
O acesso rápido a informações detalhadas sobre os computadores que compõem o seu ambiente é fundamental para o gerenciamento bem-sucedido de sistemas. É fácil perder o controle de planilhas e listas de fornecedores contendo essas informações, além de que são difíceis de manter e tornam-se desatualizadas rapidamente.
Uma ferramenta dinâmica, capaz de apresentar as informações da forma que você precisa, coletando dados sobre o que está instalado em cada computador e qual o tipo de hardware utilizado, pode ser muito útil. Uma ferramenta assim também representa uma ótima forma de controlar possíveis extras instalados pelos usuários em seus computadores (isso, é claro, se a sua diretiva de grupo já não limitar os direitos de instalação ou fornecer um cálculo rápido de quantas licenças você deve ter, de acordo com a base de instalação de um determinado pacote de software). Uma ferramenta que corresponde a essa descrição é o Total Network Inventory, da Softinventive Lab.
Depois de instalar o Total Network Inventory, você poderá iniciar o processo de inventário usando o Assistente de Verificação, que vai orientá-lo na descoberta dos nós na rede. Você pode fazer a verificação imediatamente, usando uma faixa especificada de endereços IP ou a pesquisa de computadores em locais de rede. Pode, ainda, usar uma verificação de script de logon, que permite coletar informações à medida que os computadores fazem logon no domínio.
O Total Network Inventory conta com a WMI (Instrumentação de Gerenciamento do Windows) — IPC$\ADMIN$ ou RPC/DCOM — e com o compartilhamento clássico para realizar a verificação nas contas locais. Então, é preciso executá-lo no contexto de uma conta de Administrador.
Quando a verificação for concluída, você poderá navegar nos computadores ou procurar computadores específicos para inventariar seus ativos. O Total Network Inventory agrupas as informações de inventário coletadas em três áreas: hardware, software e outras informações. A parte de hardware inclui detalhes sobre processador, placa-mãe e chipset, memória, subsistema de vídeo, armazenamento (incluindo dispositivos físicos e lógicos), tipos de adaptadores de rede e configurações, periféricos e qualquer outro dispositivo instalado no sistema.
A seção de software fornece informações sobre o sistema operacional, incluindo chaves de produto, números de série, diretórios do sistema e service packs instalados. Há detalhes sobre hotfixes (com os números dos artigos correspondentes na Base de Dados de Conhecimento) e todos os possíveis aplicativos antivírus e de banco de dados instalados. Você obtém, ainda, uma lista dos programas instalados (juntamente com a exibição do diretório Arquivos de Programas, que permite ver aplicativos possivelmente ocultos na listagem Adicionar ou Remover Programas padrão), além de uma listagem dos aplicativos de execução automática.
Por fim, a seção com "outras informações" contém detalhes sobre o ambiente do sistema, como variáveis de usuário e de sistema, recursos compartilhados, processos em execução, serviços instalados e contas de usuários locais.
O Total Network Inventory realmente fornece as informações de que você precisa para realizar auditorias de ativos, verificações de licenças, cálculos de atualizações e avaliações de desempenho. Uma das melhores partes da ferramenta é o componente Report Builder. Esse recurso permite gerar vários relatórios organizados e detalhados para todas as finalidades, desde uma referência rápida até uma trilha de auditoria em papel. E os relatórios podem ser agregados ou para um só computador. Considero especialmente útil a guia Software and Licenses Accounting (Contabilização de Software e Licenças). Ela exibe a contagem agregada de cada tipo de software instalado no ambiente, para garantir a conformidade com os contratos dos seus fornecedores.
Preço: a partir de US$ 95 para uma licença de 25 nós.
O Assistente de Verificação guia os usuários na descoberta dos nós da rede (clique na imagem para ampliá-la)

Resenha de livro
Mastering Microsoft Exchange Server 2007
sybex.com
Quer você goste ou não, o email é um componente fundamental de uma organização com operações eficientes (mas admito que, às vezes, desejo que os usuários sejam obrigados a fazer um curso de comunicação escrita eficaz antes de receberem permissão para usar o email). E, ao longo dos anos, tornou-se mais evidente o desejo de integrar comunicação de voz, calendário, agendamento de recursos, acesso uniforme para cliente e filtragem de emails (para detectar spams, vírus e outros códigos semelhantes). É aí que entra o Microsoft® Exchange Server 2007.
A versão mais recente do Exchange faz a integração completa entre todos esses componentes em uma solução escalonável e robusta. Mas, com todos esses recursos e funções, o administrador, o arquiteto e a equipe de suporte precisam contar com bons livros de referência para ajudá-los a planejar, implantar, gerenciar e manter essa solução tão dinâmica de mensagens eletrônicas.
Na última edição da coluna Toolbox, abordei o Microsoft Exchange Server 2007 Administrator's Companion. Outro recurso digno de nota é o Mastering Microsoft Exchange Server 2007, de Barry Gerber e Jim McBee (Sybex, 2007). É um guia que descreve com clareza todo o ciclo de vida do Exchange Server.
Os três primeiros capítulos do livro, reunidos em uma seção sobre compreensão e planejamento, tratam dos componentes básicos e dos requisitos para a implementação do Exchange Server 2007. Quem estiver familiarizado com as versões anteriores do Exchange gostará da seção sobre funções que não são mais enfatizadas nem implementadas. E todos gostarão da descrição das diferentes funções de servidores e dos componentes que integram uma implantação do Exchange Server 2007. Logicamente, a implantação de um servidor tão complexo requer um certo planejamento. Por isso, preste atenção às seções sobre planejamento para crescimento, requisitos de espaço em disco e integração com o Active Directory.
A seção seguinte trata da instalação propriamente dita, abordando uma instalação limpa e uma atualização do Exchange Server 2000 ou do Exchange Server 2003 (não é possível atualizar diretamente do Exchange Server 5.5). Você encontra também mais detalhes sobre as diferentes funções que podem ser desempenhadas por cada servidor Exchange, incluindo Transporte de Borda, Acesso para Cliente, Transporte de Hub, Caixa de Correio, Unificação de Mensagens e Ferramentas de Gerenciamento.
O livro passa, então, a tratar de escalabilidade, mostrando como monitorar o desempenho, adicionar armazenamento às caixas de correio, e assim por diante. Aqui, você analisa um novo recurso muito interessante: a replicação contínua local, que permite manter um backup local atualizado do seu armazenamento de emails. Se algo acontecer ao banco de dados principal, você poderá alternar rapidamente para o backup, sem precisar restaurar algum outro backup com menor disponibilidade e menos atualizado.
A seção seguinte traz uma visão geral detalhada das diversas tarefas e ferramentas de gerenciamento incluídas na implantação do Exchange Server 2007. Isso inclui ferramentas como o Shell de Gerenciamento do Exchange (baseado no Windows PowerShell™) e a interface gráfica do usuário do Console de Gerenciamento do Exchange (que também conta com o mecanismo do Windows PowerShell). Ao longo da seção, você aprende a gerenciar caixas de correio, listas de endereços e contas de usuários. A seção trata, ainda, do gerenciamento de registros de mensagens e de como administrar as regras de classificação, registro no diário e transporte de mensagens.
A quarta seção traz informações aprofundadas sobre disponibilidade e confiabilidade. Com a atual dependência das empresas em relação às mensagens eletrônicas, convém prestar atenção a essa seção.
Aqui, você terá noções básicas sobre balanceamento de carga; redundância de servidores, armazenamento e rede; e clustering. Também são abordadas resumidamente as práticas recomendadas para manutenção agendada, execução de backups e cenários de recuperação de desastres — basicamente, o que você precisa saber para manter os sistemas de mensagens eletrônicas de sua empresa funcionando com eficiência, mesmo que ocorram problemas.
As duas seções seguintes do livro abordam o acesso para cliente, incluindo Microsoft Office Outlook® 2007, Outlook Web Access, IMAP e POP3. O livro se encerra com uma seção muito importante para os administradores do Exchange, referente a segurança e auditoria. São mostradas práticas e precauções básicas de segurança, e também as diversas ferramentas de auditoria disponíveis. De forma geral, essa referência detalhada permitirá que você coloque rapidamente sua implantação do Exchange no caminho certo.
Preço: US$ 49,99 (para venda direta).

Greg Steen é profissional de tecnologia, empresário e entusiasta. Ele está sempre em busca de novas ferramentas para facilitar as operações, o controle de qualidade e o desenvolvimento para os profissionais de TI.
© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.


Utilitário em destaque Microsoft SharedView
Greg Steen

Eu trabalho muitas vezes com colegas de equipe do outro lado do planeta e constantemente encontro situações nas quais, se todos pudessem olhar e interagir com a mesma área de trabalho, poderíamos todos ilustrar e comunicar nossas opiniões com muito mais eficácia.
Suponha que sua equipe de vendas esteja na estrada e precise rapidamente se reunir para compartilhar informações, verificar cotações e reduzir a sobreposição de esforços. Pense em como seria muito mais produtivo se todos da equipe pudessem olhar e editar a mesma planilha do Microsoft® Office Excel® ou o mesmo documento do Word quase que simultaneamente, em vez de ficarem enviando por email um "documento vivo" que rapidamente pode ficar fora de sincronia. Existe hoje em dia uma ferramenta de colaboração leve que permite exatamente esse recurso: o Microsoft SharedView 1.0.
O Microsoft SharedView permite que você se reúna com até 15 pessoas e compartilhe a área de trabalho do coordenador da reunião simultaneamente, como se vocês estivessem olhando para a mesma área de trabalho. Seu primeiro pensamento pode ser que, se 15 pessoas tivessem o controle simultâneo da mesma área de trabalho, absolutamente nada, a não ser o caos, decorreria disso, mas o que realmente acontece é que o controle da área de trabalho pode ser transmitido de um membro a outro.
Enquanto você está no controle, pode ver os movimentos do mouse dos seus colaboradores (cada um recebe um ponteiro personalizado), para que eles possam apontar itens em um documento ou aplicativo. Infelizmente, o SharedView não possui recursos de áudio integrados, mas você pode usar o cliente de áudio do Windows Live™ Messenger ou seu cliente de VoIP (voz sobre IP) favorito para fazer conferências enquanto compartilha a área de trabalho.
O Microsoft SharedView permite que você compartilhe a área de trabalho de um coordenador de reunião simultaneamente (Clique na imagem para ampliá-la)
A instalação do SharedView é simples e o cliente é intuitivo o suficiente que até mesmo usuários menos experientes tecnicamente podem colocá-lo em funcionamento rapidamente. Após entrar com sua conta do Windows Live, você pode iniciar uma sessão do SharedView com dois cliques. Entrar em uma sessão é tão fácil quanto isso; você simplesmente digita o nome da sessão (normalmente a Live ID do coordenador) à qual deseja se conectar e uma senha. Os convites são enviados por email ou colando-se o texto de convite gerado no seu cliente de mensagem instantânea.
Outras opções no SharedView incluem permitir ou não copiar e colar remoto (para que os usuários da sessão possam adicionar texto de suas estações de trabalho locais à máquina do coordenador); permitindo diretamente o controle de alterações no Word para que você possa ver como as pessoas estão alterando o documento compartilhado; e uma lista de bloqueio explícita para excluir certos Windows Live IDs de participar. O aplicativo também possui um recurso interessante de Folheto que permite disponibilizar arquivos complementares aos participantes da sessão; você pode ter até 25 arquivos ou um de 200 MB por sessão.
Além disso, você pode digitar mensagens de difusão aos participantes que aparecerão no topo da sessão em que eles estão conectados. Você pode optar por compartilhar tudo o que desejar ou, se preferir manter algumas coisas em particular enquanto a reunião avança, você pode de modo rápido e fácil iniciar e interromper o compartilhamento de janelas do seu computador host. De modo geral, se estiver procurando uma ferramenta de colaboração rápida e fácil, o Microsoft SharedView provavelmente será apropriado.
Para começar, você pode ir em frente e baixar o Microsoft SharedView na seção de downloads de código do site da TechNet Magazine em technetmagazine.com.

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

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução total ou parcial sem permissão.


Explorando o SharePoint Integrando aplicativos do Office
Pav Cherny

Conteúdo
Integração de aplicativo do Office
Estendendo a interface do usuário do SharePoint
Usando o controle OpenDocuments do Office
Comunicando-se com o SharePoint
Implementando uma solução OpenControl personalizada
Resumindo
O WSS (Microsoft Windows SharePoint Services) 3.0 e o MOSS (Microsoft Office SharePoint Server) 2007 se integram diretamente a aplicativos de área de trabalho no 2007 Microsoft Office system, o que facilita a colaboração em documentos, planilhas, calendários, informações de contato e muito mais. Na verdade, a integração é tão direta que você
pode afirmar que o 2007 Office system é uma plataforma de soluções corporativas unificada.
Isso é ótimo para organizações que se concentram na tecnologia Microsoft® Office para aumentar a produtividade do profissional da informação. No entanto, as organizações que contam com um portfólio diversificado de aplicativos do Office não podem aproveitar o mesmo nível de interoperabilidade imediato. O 2007 Office system fornece os recursos de integração necessários, e as interfaces e os componentes estão minimamente documentados, não funcionando em todas as circunstâncias. Isso dificulta a integração da tecnologia do SharePoint® por parte de fornecedores terceiros a seus aplicativos e ainda mais para que seus clientes proporcionem aos profissionais da informação uma experiência unificada.
Nesta coluna, mostrarei como os aplicativos do Office se integram e se comunicam com o SharePoint, além de como é possível, de acordo com os mesmos princípios, integrar ao SharePoint aplicativos que não sejam da Microsoft. Mas primeiro abordarei as definições de configuração do servidor, os componentes do lado do cliente e os protocolos de comunicação usados na obtenção da integração direta.
Uma vez esclarecidos esses detalhes, posso abordar a integração dos aplicativos que não vêm acompanhados de suporte interno ao SharePoint. Com essa iniciativa, irei além do nível habitual que normalmente se concentra na implementação dos componentes IFilter para estender os recursos de pesquisa e adicionar ícones personalizados em servidores do SharePoint. Estender a pesquisa e os resultados retornados com ícones apropriados não atinge a integração de aplicativo total; os usuários talvez queiram também abrir esses documentos diretamente na interface do usuário do SharePoint.
É onde as coisas se complicam. Você precisa de um componente do lado do cliente que não está prontamente disponível caso não tenha implantado o Office nas estações de trabalho. Mas mesmo que tenha implantado, você pode achar que esse componente não funciona de maneira confiável, dependendo da topologia e da configuração do site do SharePoint.
Para resolver esse problema, criei uma solução personalizada que permite integrar qualquer aplicativo como, por exemplo, Bloco de Notas, Adobe Reader ou Autodesk AutoCAD, sem que haja requisitos de implantação do Office. Essa solução personalizada também ilustra por que há falha na integração do aplicativo com base nos componentes do Office em algumas situações. É possível encontrar essa solução, bem como instruções passo a passo para implantação e configuração, no material complementar desta coluna, disponível na seção Download de Código de .com.

Integração de aplicativo do Office
Do ponto de vista do usuário, os menus do SharePoint parecem funcionar como o menu Iniciar do Windows®. Criar um novo documento em uma biblioteca é simples: clique em New, em New Document, e o Microsoft Office Word 2007 é iniciado. Editar um documento existente também é bem simples. Focalize o documento, abra o menu suspenso Edit Control Box (ECB) e clique em Edit in Word. É difícil imaginar que você iniciou o Word 2007 em uma página da Web usando JavaScript, que você está executando o aplicativo localmente enquanto o documento está bem longe, em um banco de dados do SQL Server® e que há um servidor Web no caminho do acesso aos dados, como ilustra a Figura 1.
Figura 1 Trabalhando com um documento do Word no SharePoint (Clique na imagem para ampliá-la)
Apesar dessa complexidade, a experiência do usuário em uma estação de trabalho do Windows com o 2007 Office system instalado é direta. Trabalhar com documentos em uma biblioteca do SharePoint é bem semelhante a trabalhar com arquivos locais ou arquivos em um compartilhamento de rede.
No entanto, em uma estação de trabalho com o Windows, mas sem o Office 2003 ou o 2007 Office system, a interface do usuário é diferente. Clicar em New Document ou Edit in Word só abre uma caixa de diálogo informando que um aplicativo compatível com o Windows SharePoint Services não está disponível.
Isso não chega a ser uma surpresa. Existem vários elementos que devem funcionar juntos para proporcionar a experiência unificada que os usuários do Office usufruem. O SharePoint deve reconhecer os tipos de conteúdo mantidos na biblioteca de documentos para renderizar os comandos desejados nos menus New e ECB. Em resposta a cliques do mouse nesses comandos, o código JavaScript deve ser executado para iniciar o aplicativo associado, passando o caminho para o documento. Essa parte não independe da configuração da estação de trabalho porque o código JavaScript é executado localmente. Além disso, o aplicativo associado deve se comunicar com o SharePoint para ler e possivelmente gravar arquivos. Esses são os elementos que você deve agrupar caso queira integrar os aplicativos ao SharePoint.
Por outro lado, a comunicação entre o SharePoint e o servidor de banco de dados é transparente para o aplicativo, assim como os processos de indexação no servidor Web para facilitar as pesquisas. Por esse motivo, não abordarei mais a fundo esses aspectos neste artigo, embora recomende que você consulte o Microsoft Filter Pack documentado no artigo da Base de Dados de Conhecimento Microsoft "Como registrar Microsoft Filter Pack com Windows SharePoint Services 3.0", disponível em support.microsoft.com/kb/946338. Agora voltemos nossas atenções para a adição de comandos, a implementação dos componentes do lado do cliente necessários e a facilitação da comunicação do aplicativo.

Estendendo a interface do usuário do SharePoint
Há várias opções disponíveis para estender a interface do usuário e a funcionalidade do SharePoint. É possível alterar o design dos sites, personalizar as páginas do ASP.NET, desenvolver Web Parts ou alterar o código JavaScript incluído no WSS e no MOSS para iniciar diretamente os aplicativos.
Não há nada que impeça a abertura do arquivo Ows.js em um editor de texto (o arquivo pode ser encontrado na pasta COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 dos servidores front-end do SharePoint) e a alteração da forma com que operam as funções createNewDocumentWithProgIDCore, editDocumentWithProgIDNoUI e DispDocItem. Mas existe um método melhor que não exige a alteração da base de código do WSS de forma para a qual não há suporte: usar tipos de conteúdo e mapeamentos de tipo de documento.
No meu artigo "Padronize o gerenciamento de dados com tipos de conteúdo personalizados" (consulte a TechNet Magazine, de fevereiro de 2008, technet.microsoft.com/magazine/cc194408.aspx), expliquei como criar tipos de conteúdo globais e específicos do site para gerenciar documentos e outro conteúdo nas bibliotecas de documentos e listas do SharePoint. Também é possível conferir a planilha Text Content Type.pdf no material complementar deste artigo, que ilustra como criar um novo tipo de conteúdo para arquivos .text e associar esse tipo a uma biblioteca de documentos. O resultado é que é possível selecionar o comando Text Content no menu New assim que o comando Document é selecionado para documentos do Word (consulte a Figura 2).
Figura 2 Um tipo de conteúdo personalizado na interface do usuário do SharePoint (Clique na imagem para ampliá-la)
O menu ECB é extensível da mesma forma. Você talvez estivesse esperando que o menu ECB reconhecesse o tipo de conteúdo, mas essa não é a forma como a versão do WSS atual implementa esse menu. Na verdade, você deve registrar o tipo de documento em Docicon.xml, que é possível localizar na pasta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml em todos os servidores front-end do SharePoint.
Adicionando o seguinte mapeamento do tipo de documento à seção <ByExtension> de Docicon.xml, por exemplo, você fará com que o SharePoint exiba o comando Edit in Notepad (consulte o arquivo Text Content Type.pdf para obter instruções mais detalhadas):
<Mapping Key="text" Value="ictxt.gif"
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>
O parâmetro Key identifica a extensão do nome de arquivo, o parâmetro Value define o ícone do documento a ser exibido na interface do usuário, o parâmetro EditText define a seqüência de caracteres que o SharePoint acrescenta ao comando "Edit in" e o parâmetro OpenControl especifica ProgID de um componente COM do lado do cliente. Trata-se de ProgID que as funções JavaScript do SharePoint passam para uma chamada ActiveXObject (consulte Ows.js para obter detalhes) a fim de criar uma instância do objeto COM, que pode ser o próprio aplicativo ou um controle auxiliar que inicia o aplicativo com base no tipo de arquivo associado.
Site dos Produtos e Tecnologias do SharePoint

  • Site dos Produtos e Tecnologias do SharePoint
  • TechCenter do Windows SharePoint Services
  • Windows SharePoint Services Developer Center
  • Blog da equipe de Produtos e Tecnologias do Microsoft SharePoint
Você deve observar que OpenControl nomeado SharePoint.OpenDocuments está se referindo a um controle ActiveX® que acompanha as versões recentes do Office (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Caso esse arquivo esteja nas estações de trabalho e o ícone do documento especificado (parâmetro Value) esteja na pasta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images dos servidores do SharePoint, você talvez já tenha realizado grande parte do trabalho de integração necessário.
O SDK do Windows SharePoint Services 3.0 inclui algumas informações sobre APIs do lado do cliente que acompanham o 2007 Office system, inclusive o controle OpenDocuments. Consulte a seção "Referência API do cliente" em msdn2.microsoft.com/ms440037.

Usando o controle OpenDocuments do Office
O controle OpenDocuments atende às necessidades de integração do aplicativo mais importantes, embora exija o Office 2003 ou o 2007 Office system, além dos recursos estarem, de certa forma, limitados. Os comandos do menu New talvez não funcionem sempre, e eles, às vezes, exibem o que pode ser uma notificação do usuário falsa.
Conforme ilustrado na Figura 3, o controle OpenDocuments informa ao usuário que o aplicativo obrigatório não está instalado corretamente ou que o arquivo de modelo não pode ser aberto, embora nenhum desses seja o caso. Edit também apresenta problemas, em termos de funcionalidade. A segunda mensagem de erro mostrada no primeiro plano da Figura 3 é vista com freqüência. Trata-se da minha favorita em todos os tempos porque engana até mesmo especialistas em SharePoint, mas falarei mais a respeito daqui a pouco.
Figura 3 Mensagens de erro falsas do controle OpenDocuments (Clique na imagem para ampliá-la)
No entanto, o controle OpenDocuments é útil em ambientes com versões recentes do Office instalado em todas as estações de trabalho. Dentre todas as outras coisas, é possível ocultar os tipos de documento no menu New (exibir Document Library Settings, clicar em Change New Button Order And Default Content Type e desmarcar a caixa de seleção Visible de todos os tipos de conteúdo em questão), para que os usuários não encontrem a primeira mensagem de erro. Também é possível manter a topologia do site simples para evitar problemas de comunicação do WebDAV (Web-Based Distributed Authoring and Versioning); isso elimina essa segunda mensagem de erro.

Comunicando-se com o SharePoint
Até aqui, consegui estender a interface do usuário do SharePoint e talvez iniciar um aplicativo por meio do controle OpenDocuments, mas o meu aplicativo continua precisando de uma forma para se comunicar com o SharePoint e acessar os dados. Como sempre, o SharePoint oferece suporte a vários métodos para fazer isso como, por exemplo, Microsoft Office FrontPage® Server Extensions, RPCs (chamadas de procedimento remoto) do WSS, WebDAV e Web services. Na verdade, aplicativos do Office como, por exemplo, o Word 2007 podem usar todos esses métodos de comunicação, dependendo de como você acessa um documento como por meio das pastas da Web, unidades de rede mapeadas ou a interface do usuário do SharePoint.
Os métodos de comunicação cliente/servidor do SharePoint contam com o HTTP como protocolo subjacente. Por exemplo, o FrontPage e as RPCs do WSS usam todos as solicitações HTTP POST e HTTP GET direcionadas para extensões ISAPI que residem em servidores do SharePoint na pasta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI e em todas as suas subpastas.
Uma das extensões ISAPI mais importantes é Owssvr.dll, que implementa, dentre outras coisas, a funcionalidade para trabalhar com listas e bibliotecas de documentos. A Figura 4 mostra a caixa de diálogo Save do SharePoint no Word 2007 (lado esquerdo) e em um navegador (lado direito) aberta diretamente por meio da solicitação de URL http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx. As semelhanças entre as duas capturas de tela são evidentes.
Figura 4 A caixa de diálogo Save do SharePoint no Word 2007 e no Internet Explorer (Clique na imagem para ampliá-la)
Outras extensões ISAPI importantes são Author.dll, que implementa o FrontPage e as RPCs do WSS para operações de edição do lado do cliente como, por exemplo, carregar, renomear e excluir documentos; Admin.dll para gerenciar sites e realizar várias outras tarefas administrativas e Shtml.dll para oferecer suporte a envios de formulário HTML.
Costuma ser impossível adicionar suporte a FrontPage e RPC do WSS aos aplicativos existentes como, por exemplo, o Bloco de Notas ou o Adobe Reader, sem que haja acesso ao código-fonte. Mas você poderia fornecer as instalações da comunicação necessárias por meio do recurso cliente Web incluído no Windows.
O SharePoint também oferece suporte a WebDAV por meio de Httpext.dll, que reside na pasta %WINDIR%\System32\Inetsrv\, mas fiquemos no lado do cliente. Os computadores com o Windows Server® 2008 ou o Windows Vista® em execução contam com o recurso do cliente Web instalado por padrão. É possível localizar um serviço WebClient correspondente no miniaplicativo Serviços de Ferramentas Administrativas no Painel de Controle. No Windows XP e no Windows Server 2003, você deve instalar explicitamente o cliente Web. De qualquer forma, verifique se o serviço WebClient foi iniciado e se Tipo de inicialização está definido como Automático.
A Figura 5 é uma representação da arquitetura do cliente Web. O serviço WebClient é implementado em uma DLL em modo de usuário (Webclnt.dll) carregada por Gerenciador de Controle de Serviços em um processo de host Svchost.exe. Webclnt.dll fornece a interface do provedor de rede para operações que não sejam de E/S (como, por exemplo, autenticar o usuário tendo em vista o acesso a WebDAV; montar sites do SharePoint como unidades de rede; enumerar sites do SharePoint, listas e documentar bibliotecas como recursos de rede, além de desconectar unidades montadas).
Figura 5 A arquitetura do Redirecionador do cliente WebDav (Clique na imagem para ampliá-la)
Para realizar esse trabalho, Webclnt.dll se comunica com um driver do sistema de arquivos em modo kernel que fornece a funcionalidade de redirecionamento efetiva. O driver redirecionador do cliente WebDAV (Mrxdav.sys) se baseia no RDBSS (Redirected Drive Buffering Subsystem), que se integra ao Gerenciador E/S e aos demais componentes de kernel para proporcionar os serviços de um sistema de arquivos remoto. Mrxdav.sys implementa as instalações de comunicação de WebDAV para oferecer suporte ao acesso em nível de sistema aos sites do SharePoint e às bibliotecas de documentos.
Ter acesso a sites do SharePoint e a bibliotecas de documentos por meio de um redirecionador de rede elimina a necessidade do suporte ao FrontPage e a RPCs do WSS nos aplicativos do usuário. É possível mapear unidades de rede para bibliotecas de documentos (como, por exemplo, net use x: http://wss/doclib/Shared%20Documents), e você também pode acessar os recursos do SharePoint por meio de caminhos UNC.
A URL http://wss/doclib/Shared%20Documents é mapeada para \\wss\doclib\Shared%20Documents. Dessa forma, você tem opções para abrir um documento em um aplicativo. Por exemplo, é possível abrir um documento no Bloco de Notas com o caminho HTTP http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt ou o caminho UNC \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt.
Infelizmente, o recurso cliente Web tem várias limitações. Não é possível acessar propriedades personalizadas ou aplicativos Web que usem portas TCP personalizadas. O cliente Web que acompanha o Windows Vista também apresenta falha caso o usuário não tenha acesso a um site pai na hierarquia, como ilustrado em WebDAV Access.pdf (consulte o material complementar).
O caminho http://sharepoint/HR/Administration/Shared%20Documents/ inclui um site raiz inexistente (ou seja, http://sharepoint), ainda sem acesso à raiz, o cliente Web não pode determinar os recursos do servidor Web. O servidor Web rejeita a solicitação OPTIONS do cliente Web com Código de Status 401, que informa que o acesso não é autorizado e, dessa forma, o cliente Web continua solicitando as credenciais do usuário, como mostrado na Figura 6, ainda que o usuário tenha acesso administrativo ao conjunto de sites sharepoint/HR e a todos os sites nele contidos.
Figura 6 Acesso a WebDAV malsucedido (Clique na imagem para ampliá-la)
Ao usar o controle OpenDocuments, você recebe a mensagem de erro exibida na Figura 3 caso o cliente Web falhe ao abrir um documento. O aplicativo está disponível, e o mapeamento do tipo de documento está correto. Trata-se do documento que pode ser acessado por meio do redirecionador WebDAV.

Implementando uma solução OpenControl personalizada
Geralmente, você tem duas opções para contornar as limitações do cliente Web. É possível aguardar até que a Microsoft forneça uma versão atualizada do cliente Web ou até que você possa implementar uma solução OpenControl personalizada capaz de lidar com a situação atual. Implementar um OpenControl personalizado não é uma tarefa habitual, embora elimine a necessidade do Office nas estações de trabalho, permita tratar o comando New, além do comando Edit in, de maneira significativa e possibilite resolver situações nas quais ocorre uma falha no cliente Web.
Caso algum desses problemas seja atraente na sua opinião, observe o código-fonte AppStart incluído no material complementar. Ele mostra como expor as interfaces COM OpenControl de um assembly do Microsoft .NET Framework, que o código JavaScript do SharePoint pode chamar. O código-fonte AppStart também demonstra uma forma possível de verificar a acessibilidade do arquivo e baixá-lo para o computador local por meio do http, caso não seja possível o acesso direto por meio de WebDAV. Por fim, o código-fonte AppStart responde ao comando New, baixando o modelo associado ao tipo de conteúdo para o computador local de que o usuário possa começar a trabalhar no documento. As planilhas Text Content Type.pdf e Adobe Reader Support.pdf descrevem como implantar essa solução OpenControl.
O diagrama mostrado na Figura 7 exibe a arquitetura de AppStart. O meu componente OpenControl personalizado (chamado Biblioso.dll) expõe duas interfaces COM idênticas que o JavaScript do SharePoint chama para criar novos documentos ou abrir documentos já existentes para edição (Biblioso.AppStart.2 e Biblioso.AppStart.3).
Figura 7 A arquitetura de AppStart (Clique na imagem para ampliá-la)
Caso um documento seja aberto para edição, Biblioso.dll verifica se o arquivo existe e inicia o aplicativo associado com o caminho para o documento em caso de acessibilidade direta do arquivo por meio de WebDAV. Caso o arquivo não esteja acessível, Biblioso.dll inicia um servidor COM fora de processo que, por sua vez, carrega OpenDocsUtility.dll para baixar o arquivo por meio de HTTP e iniciar o aplicativo com o caminho para o documento baixado.
O servidor COM fora de processo permite que a solução interrompa o processo do Internet Explorer®, o que restringe downloads à pasta Temporary Internet no modo protegido. Os usuários devem ser capazes de baixar arquivos sem restrições no modo protegido, e um servidor COM fora de processo que funciona como um agente do aplicativo fornece essa opção.
Como não há suporte para o desenvolvimento de servidores COM fora de processo no .NET, recorri ao C/C++ nesse executável. Implementei somente o mínimo, a caixa de diálogo Save As no C++. Para que a solução permanecesse o mais direta possível e manter a sobrecarga de desenvolvimento baixa, coloquei o código para download real em um assembly do .NET (OpenDocsUtility.dll), que acabo chamando por meio de uma outra interface COM.
Para facilitar o desenvolvimento, adicionei um projeto de instalação à solução. Dentre outras coisas, a rotina de instalação registra todos os componentes COM e grava configurações específicas do aplicativo em HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. Os parâmetros mais importantes são AllowedApps e AllowedFileTypes. A solução AppStart só funcionará com esses aplicativos e os tipos de arquivo que você deve especificar explicitamente nesses parâmetros.
A rotina de instalação também cria uma diretiva de elevação para o servidor COM fora de processo de forma que Biblioso.dll no processo do Internet Explorer possa iniciar AppBrokerEngine.exe sem disparar avisos de segurança. Caso você esteja interessado em saber mais sobre o modo protegido do Internet Explorer e sobre como lidar com ele no desenvolvimento de aplicativos, é altamente recomendável a leitura do artigo de Marc Silbey e Peter Brundrett, "Compreendendo e trabalhando no modo protegido do Internet Explorer", disponível em msdn2.microsoft.com/bb250462.
Durante o exame dos componentes de AppStart, tenha em mente que essa solução foi desenvolvida apenas para mostrar o que se pode fazer; ela ainda não está pronta para ambientes de produção. Não houve tempo suficiente para otimizar o código e testar integralmente a solução, ou documentar os recursos, além dos comentários feitos sobre o código-fonte.
Você deve usar essa solução por sua conta e risco. Caso você esteja interessado em estudar o código-fonte e criar uma solução própria, inicie AppStart.cs no projeto de código Biblioso. Esse arquivo implementa a interface COM OpenControl e os pontos de entrada das chamadas JavaScript em Ows.js.
Resumindo
O WSS 3.0 e o MOSS 2007 fornecem amplos recursos para integração de aplicativos destinados a uma experiência do usuário direta em meio ao trabalho com documentos e outros itens em bibliotecas de documentos e listas do SharePoint. Os aplicativos de área de trabalho do 2007 Office system demonstram isso de maneira muito clara, sendo possível obter o mesmo nível de integração e usabilidade também com aplicativos que não sejam do Office.
Na base da arquitetura de integração de aplicativos estão os componentes COM, usados pelas funções JavaScript do SharePoint, além do caminho do documento, para iniciar o aplicativo. O 2007 Office system fornece vários desses componentes COM, otimizados tendo em vista necessidades específicas do aplicativo do Office, ainda que também seja possível reutilizar o controle OpenDocuments do Office para integrar aplicativos que não sejam da Microsoft. O controle OpenDocuments atende às necessidades mais básicas. Tendo em vista requisitos de integração de aplicativos mais avançados, é possível implementar um controle personalizado.
Integrar totalmente um aplicativo ao SharePoint exige não apenas instalar componentes IFilter e documentar ícones para estender os recursos de pesquisa e exibição, mas também envolve criar tipos de conteúdo personalizados e mapeamentos de tipo de documento nos servidores do SharePoint para fornecer os comandos New e Edit in apropriados na interface do usuário do SharePoint. Esses comandos chamam funções JavaScript que invocam métodos expostos por meio de um componente OpenControl. O componente OpenControl também deve estar disponível na estação de trabalho.
Outra peça importante do quebra-cabeça é o cliente Web, incluído e instalado por padrão no Windows Vista. O cliente Web implementa um redirecionador WebDAV e um driver do sistema de arquivos remoto para que qualquer aplicativo possa acessar recursos em listas e bibliotecas de documentos do SharePoint, semelhantes a compartilhamentos de arquivos na rede. Muito embora tenha limitações, o cliente Web que acompanha o Windows Vista é peça fundamental na história da integração do aplicativo.
O suporte a WebDAV também preenche a lacuna entre aplicativos em execução em estações de trabalho que não sejam do Windows e o SharePoint. Como a tecnologia de controle COM e ActiveX não costuma estar disponível nesses sistemas operacionais, não é possível usar componentes OpenControl para iniciar automaticamente os aplicativos, mas a maioria dos sistemas operacionais inclui redirecionadores WebDAV para que os usuários possam pelo menos acessar documentos diretamente em bibliotecas de documentos sem que seja necessário baixar os arquivos para as estações de trabalho locais.
O WSS 3.0 e o MOSS 2007 são os fundamentos da história de sucesso do 2007 Office system, e os usuários de aplicativos de terceiros baseados no Office podem usufruir o SharePoint da mesma maneira. Os recursos de integração vão muito além do Office. Usufruindo o SharePoint por completo, é possível criar uma plataforma de soluções corporativas unificada que proporciona a mesma experiência do usuário para o Office e o software de terceiros e, dessa forma, aumenta a produtividade dos profissionais da informação.

Pav Cherny é especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada. Entre suas publicações estão white papers, manuais de produto e livros com foco nas operações de TI e na administração do sistema. Pav é presidente da Biblioso Corporation, empresa especializada em serviços de documentação gerenciada e de localização.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução total ou parcial sem permissão.


Windows PowerShell A caixa de depósito
Don Jones

Conteúdo
Seja o cmdlet
A função de filtragem
Pense em termos físicos
Aplicações práticas
Reserve algum tempo para "brincar"
Em uma das aulas de Windows PowerShell que ministrei recentemente, alguns alunos tiveram dificuldade para visualizar do que se tratava o pipeline do shell. Admito que o pipeline não é um conceito totalmente intuitivo, e pode ser um tanto difícil de entender para quem busca o aprendizado a partir da visualização. Quando cheguei ao
conceito das funções de filtragem, que funcionam diretamente no pipeline, as coisas realmente se complicaram, e percebi, pela expressão no rosto dos alunos, que estava a ponto de perder alguns deles.
Para tentar ajudá-los, no dia seguinte, eu trouxe uma caixa, algumas etiquetas adesivas com nomes e algumas bolas de pingue-pongue (quem disse que o Windows PowerShell® não podia ser divertido?). Resolvi fazer uma demonstração usando a seguinte linha de comando:
Get-Process | Where { $_.VM –gt 1000 } | Sort VM
–descending | Export-CSV C:\Procs.csv

Seja o cmdlet
Usando as etiquetas adesivas com nomes — você sabe, aqueles adesivos com "Olá, meu nome é…" que você sempre precisa usar em reuniões escolares e outros eventos desagradáveis — atribuí um nome de cmdlet a cada aluno. Expliquei que as bolas de pingue-pongue representavam os objetos de processo do Windows® (mais especificamente, os objetos do tipo System.Diagnostics.Process), e então pedi a eles que dissessem o nome do cmdlet com maior probabilidade para gerar objetos de processo.
Olhando as etiquetas uns dos outros, eles concordaram com a opção óbvia de Get-Process. Isso demonstra um dos principais motivos pelos quais realmente gosto dos nomes de cmdlets usados no Windows PowerShell: em geral, são bastante óbvios.
Então, a aluna com a etiqueta Get-Process pegou todas as bolas de pingue-pongue e depositou-as na caixa de papelão. A caixa representa o pipeline do shell, e a aluna fez algo muito parecido com o que um cmdlet faz. Um cmdlet gera um ou mais objetos e os deposita no pipeline.
Então, o próximo cmdlet no pipeline assumiu o comando. Neste exemplo, o aluno representando o cmdlet Where-Object pegou todas as bolas de pingue-pongue e examinou-as, uma de cada vez, para verificar se a propriedade MV de uma determinada bola era maior do que 1.000. No shell, "MV" significa memória virtual e, para o exercício, escrevi com um marcador as diversas quantidades de memória virtual em cada bola de pingue-pongue.
Cada bola (também conhecida como processo) com uma MV de 1.000 ou mais voltava para a caixa (também denominada pipeline), enquanto as de valor menor eram despejadas em uma lata de lixo, desaparecendo para sempre (o que não é bem verdade, pois eu as resgatei para uso em aulas futuras).
Em seguida, o aluno representando Sort-Object analisou as bolas de pingue-pongue na caixa e colocou-as em ordem, com base na propriedade MV. Tenho de admitir que essa parte do exercício não foi muito bem planejada: foi um problema impedir que as bolas rolassem por toda parte! Acho que, para a próxima aula, precisarei encontrar cubos de pingue-pongue, ou então trazer também algumas caixas de ovos.
Por fim, o aluno representando Export-CSV pegou as bolas e escreveu as informações em um arquivo CSV. Em termos físicos, isso significa que ele escreveu as propriedades dos processos em um flip chart que fingimos ser um arquivo CSV.

A função de filtragem
Com um simples pipeline fora do caminho, resolvemos nos concentrar nas funções de filtragem, um pouco mais complicadas. Propus a função de filtragem e a linha de comando mostradas na Figura 1.
Figura 1 — exemplo de função de filtragem e linha de comando
Function Do-Something {
 BEGIN { }
 PROCESS {
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty "TimeStamp" (Get-Date)
  $obj | Add-Member NoteProperty "ProcessName" ($_.Name)
  Write-Output $obj
 }
 END {}
}
Get-Process | Do-Something | Format-Table *
Primeiro, quero apresentar uma rápida revisão do que as funções de filtragem se destinam a fazer. A idéia é que a função contém três blocos de scripts chamados BEGIN, PROCESS e END.
Quando a função é usada no pipeline, o bloco de scripts BEGIN é executado primeiro. Esse script pode realizar qualquer tarefa de configuração, como abrir uma conexão com o banco de dados.
Então, o bloco de scripts PROCESS é executado uma vez para cada objeto canalizado na função. No bloco de scripts PROCESS, a variável $_ é preenchida automaticamente com o objeto de pipeline atual. Então, se dez objetos forem canalizados, o bloco de scripts PROCESS será executado dez vezes.
Por fim, depois que todos os objetos canalizados tiverem sido executados, o bloco de scripts END será executado e realizará as tarefas de limpeza necessárias, como fechar uma conexão com o banco de dados.
Em qualquer um desses blocos de scripts, todos os elementos escritos com o uso de Write-Output terminam no pipeline para o próximo cmdlet. Todos os elementos escritos sem o uso de Write-Output são descartados.
Como nosso comando começava com Get-Process, a mesma aluna de antes reuniu todas as bolas de pingue-pongue (saímos para um breve intervalo e, de alguma forma, as bolas foram espalhadas por toda a sala, imagine!) e depositou-as na caixa do pipeline. Quando ela concluiu a tarefa, o aluno representando a função de filtragem "Do-Something" assumiu o controle.
Primeiro, ele executou seu bloco de scripts BEGIN. Como estava vazio, isso não exigiu muito esforço. Em seguida, pegou todos os objetos do pipeline (as bolas de pingue-pongue) e começou a examinar um de cada vez. Isso foi um tanto engraçado, pois havia cerca de uma dúzia de bolas, e ele tentou equilibrar todas em seu colo — mas acho que você precisaria presenciar a cena.
De qualquer forma, ele pegou um objeto de processo por vez e executou seu bloco de scripts PROCESS. Esse bloco de scripts fez com que ele criasse um novo objeto personalizado (usei para isso bolas de pingue-pongue amarelas especiais, e não pense que foi fácil encontrá-las na loja de esportes local). Nessas novas bolas de pingue-pongue, ele escreveu a data e a hora atuais, além do nome do objeto de processo que estava examinando naquele momento.
Esse novo objeto personalizado foi, então, gravado no pipeline, ou seja, o aluno colocou a bola de pingue-pongue amarela na caixa, e o objeto de processo original (a bola de pingue-pongue branca) foi descartado. Ele repetiu essa operação para cada objeto de processo (bola de pingue-pongue) na caixa, totalizando cerca de uma dúzia. Quando terminou, cada bola de pingue-pongue branca havia sido substituída por um objeto personalizado (bola de pingue-pongue amarela). Por fim, ele executou seu bloco de scripts END, que estava vazio e não demorou nem um pouco.
Para concluir, a aluna Format-Table assumiu o controle. Ela pegou todo o conteúdo da caixa — agora, constituído somente por objetos "personalizados" amarelos — e começou a construir uma tabela, usando as duas propriedades escritas em cada bola. O resultado foi uma tabela, escrita em nosso flip chart, com duas colunas — TimeStamp e ProcessName — e cerca de uma dúzia de linhas.

Pense em termos físicos
O exercício tornou o pipeline e as funções de filtragem realmente claros para todos os alunos da turma. As bolas de pingue-pongue funcionaram muito bem representando objetos, algo que tende a tornar-se um pouco abstrato quando você apenas fala sobre o shell.
Todos conseguiram perceber como os cmdlets manipularam os objetos; como os resultados foram colocados no pipeline; e como o cmdlet seguinte coletou os resultados e realizou manipulações adicionais nos objetos. A seqüência de eventos em uma função de filtragem era mais evidente, assim como a técnica do bloco de scripts PROCESS, de trabalhar com um objeto de entrada por vez.
Isso demonstrou também os meios pelos quais um novo objeto personalizado pode ser criado e colocado no pipeline. O sistema ajuda, ainda, a demonstrar as vantagens de produzir objetos personalizados, em oposição ao texto simples — os novos objetos personalizados puderam ser consumidos por outros cmdlets, como Format-Table, oferecendo uma grande flexibilidade na forma como os dados poderiam ser usados e representados.

Aplicações práticas
Logicamente, os alunos perguntaram como é possível usar o pipeline e as funções de filtragem que demonstramos em aplicações práticas. Para mim, foi fácil responder, pois produzi vários exemplos para uma sessão apresentada recentemente em uma conferência (você pode baixar esses exemplos em scriptinganswers.com/essentials/index.php/2008/03/25/techmentor-2008-san-francisco-auditing-examples).
Um dos exemplos consistia na meta de listar várias propriedades da classe Win32_UserAccount na WMI (Instrumentação de Gerenciamento do Windows) de diversos computadores. Supondo que os nomes dos computadores estejam listados em C:\Computers.txt, este comando simples dará conta da tarefa:
Gwmi win32_useraccount –comp (gc c:\computers.txt)
O problema é que a classe Win32_UserAccount não inclui uma propriedade que informe de que computador veio cada instância. Então, a lista resultante será um amontoado inútil de contas de vários computadores. Eu soluciono esse problema criando um novo objeto personalizado que inclui o nome do computador de origem, assim como propriedades de classe selecionadas nas quais tenho interesse. O código desse objeto personalizado é mostrado na Figura 2.
Figura 2 — usando um objeto personalizado para coletar nomes de computadores e selecionar propriedades
function Get-UserInventory {
  PROCESS {
    # $_ is a computer name
    $users = gwmi win32_useraccount -ComputerName $_
    foreach ($user in $users) {
      $obj = New-Object
      $obj | Add-Member NoteProperty Computer $_
      $obj | Add-Member NotePropertyPasswordExpires ($user.PasswordExpires)
      $obj | Add-Member NoteProperty Disabled ($user.Disabled)
      $obj | Add-Member NotePropertyFullName ($user.FullName)
      $obj | Add-Member NoteProperty Lockout ($user.Lockout)
      $obj | Add-Member NoteProperty Name ($user.Name)
      $obj | Add-Member NotePropertyPasswordRequired ($user.PasswordRequired)
      $obj | Add-Member NotePropertyPasswordChangeable ($user.PasswordChangeable)
    }
  }
}

Get-Content c:\computers.txt |
  Get-UserInventory |
  where { $_.PasswordRequired -eq $False } |
  selectComputer,Name |
  Export-Csv c:\BasUsersBad.csv
A linha de comando final transmite todos os nomes de computadores para a função de filtragem, que produz os objetos personalizados. Em seguida, filtro todos os usuários, exceto aqueles com a propriedade PasswordRequired definida como False (a idéia é produzir um relatório de auditoria das contas problemáticas). Então, simplesmente mantenho as propriedades Computer e Name, de forma que o relatório final seja uma lista de nomes de computadores e nomes de contas que requerem atenção, por terem senhas que não perdem a validade. A função de filtragem torna possível esse relatório sobre vários computadores, pois adiciona o nome do computador de origem à saída, ao mesmo tempo em que reduz as propriedades somente àquelas que tenho interesse em ver.
Embora haja outras formas semelhantes de realizar a tarefa, esta abordagem é provavelmente a mais direta, e serve também para ilustrar conceitos e técnicas importantes.

Reserve algum tempo para "brincar"
Mesmo que você já esteja seguro em relação ao pipeline, há uma lição a ser aprendida aqui. Pensar em termos de objetos físicos pode ajudá-lo a visualizar o que está tentando fazer.
Então, da próxima vez que tiver dificuldades com algum conceito do Windows PowerShell, tente sair um pouco da frente do computador e replicar a tarefa usando objetos do cotidiano como ilustração. Sugiro que você tenha sempre à mão uma sacola com bolas de pingue-pongue (ou cubos, se conseguir encontrá-los) para essa finalidade.
Cmdlet do mês: Out-File
Quantas vezes você já direcionou a saída de um cmdlet para um arquivo usando o símbolo >? Isso significa algo do tipo Get-Process > Processes.txt. Você sabia que, na verdade, está apenas usando o cmdlet Out-File disfarçado? Eis aqui um comando que realiza exatamente a mesma função: Get-Process | Out-File Processes.txt.
Logicamente, isso exige um pouco mais de digitação, então por que ter o trabalho de digitar o cmdlet Out-File completo? Um dos motivos é que a leitura de Out-File é muito mais clara. Digamos que alguém, daqui a seis meses, observe um dos seus scripts e se pergunte o que significa > (que é, afinal de contas, uma espécie de elemento legado).
Por outro lado, Out-File torna bastante óbvio que um arquivo será criado e uma gravação será feita nele. Além disso, Out-File fornece o parâmetro -append (muito semelhante a >>), juntamente com os parâmetros -force e -noClobber, permitindo que você controle se os arquivos existentes serão substituídos. Por fim, digitar Out-File fornece também acesso ao parâmetro -whatif. Esse parâmetro é muito útil e mostra o que Out-File fará, antes que seja feito! É uma ótima forma de testar uma linha de comando complicada, com pouco ou nenhum risco.
Vídeo
Assista a Don Jones colocando esses cmdlets em ação.

Don Jones é co-autor de Windows PowerShell: TFM e dá aulas de Windows PowerShell (www.ScriptingTraining.com).

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução total ou parcial sem permissão.


Ei, Equipe de Scripts! Adrenalina pura
A Equipe de Scripts da Microsoft

Fica evidente para nós que escrever para a TechNet Magazine é o trabalho de maior prestígio – e mais gratificante – que alguém pode ter. (É claro que seria ainda mais gratificante se fôssemos pagos, mas essa já é uma outra história.) E que prestígio esse trabalho dá? Coloquemos as coisas desta forma: neste exato momento, em todas as partes do mundo, crianças que estão indo dormir olham para suas mães e dizem: "mamãe, quando crescer, quero escrever uma coluna mensal sobre scripts na TechNet Magazine".
Observação Evidentemente, no mundo todo, algumas pessoas já pensam que esta coluna é escrita por crianças. Mas essa também é uma outra história.
É bem sabido que a Equipe de Scripts gosta de ser paparicada por conta da coluna na TechNet Magazine. Chegamos, inclusive, a aprender como lidar com os fãs em busca de autógrafos e com os paparazzi. Mas a verdade é que não queremos realizar esse trabalho pela honra e pela glória; fazemos esse trabalho pela adrenalina pura de escrever scripts para a administração do sistema.
Convenhamos, não é sempre que você lê os termos "adrenalina pura" e scripts para a administração do sistema na mesma frase. (Isso, é claro, a menos que "adrenalina pura" seja precedida de "ausência total ou completa de".)
Em geral, as pessoas consideram os scripts para a administração do sistema extremamente úteis, mas é bem provável que não muito interessantes. Na verdade, elas acham os scripts meio monótonos. E eis o porquê: nenhuma delas tentou escrever scripts de dados de configuração da inicialização no Windows Vista® ou no Windows Server® 2008.
Ahá! Isso fez o seu coração palpitar, não fez? Como a maior parte dos leitores deste artigo já deve saber, no Windows Vista e no Windows Server 2008, o arquivo boot.ini antigo deu lugar a um novo armazenamento de dados de configuração da inicialização que fornece mais flexibilidade (e recursos) quando se é preciso gerenciar o processo de inicialização.
Isso é bem legal. Mas legal mesmo é: graças a um novo provedor WMI (Instrumentação de Gerenciamento do Windows®), o armazenamento BCD (Dados de Configuração da Inicialização) agora pode ser acessado facilmente – e gerenciado por completo – usando scripts.
Não se preocupe com essa estranha sensação que acabou de percorrer sua espinha. Isso é adrenalina pura. Depois de começar a trabalhar com scripts BCD, você se acostumará com eles.
Antes de prosseguirmos, devemos salientar que somos incapazes de sequer começar a abordar tudo o que se pode fazer usando o provedor BCD, pelo menos não nesta única coluna. (Enviamos um email para os editores da revista aventando a possibilidade de fazermos uma edição especial dupla dedicada inteiramente a como escrever scripts de dados de configuração da inicialização, mas ainda não tivemos nenhuma resposta.)
Caso queira obter informações mais completas, consulte a documentação do provedor WMI BCD em go.microsoft.com/fwlink/?LinkId=116953. Enquanto isso, mostraremos um código de exemplo projetado para computadores de inicialização múltipla – computadores com mais de um sistema operacional instalado.
Ah, esses scripts só funcionam no Windows Vista e no Windows Server 2008. Isso porque, como mencionamos anteriormente, esses são os únicos dois sistemas operacionais que oferecem suporte ao BCD.
Comecemos observando um script que nos informa qual sistema operacional um computador está usando no momento. É verdade, não se trata do uso mais interessante para o provedor BCD. Afinal, já podemos usar a classe WMI Win32_OperatingSystem para determinar qual é o sistema operacional usado por um computador no momento. No entanto, esse é um script relativamente simples (pelo menos em relação aos scripts BCD), além de proporcionar uma forma interessante de ilustrar as técnicas básicas necessárias ao trabalho com o BCD. (As técnicas são, no mínimo, um pouquinho… incomuns.)
Além disso, não podemos dar muita emoção a nossas colunas: a TechNet Magazine já nos avisou de que seremos responsabilizados por eventuais danos causados por fãs ensandecidos e superfervorosos da Ei, Equipe de Scripts! Considerando a balbúrdia generalizada irrompida em todo o mundo após a publicação da nossa coluna sobre expressões regulares, bem, não podemos correr o risco de voltar a fazer algo tão incrível.
Observação Você se lembra daqueles vídeos dos Beatles sendo atacados por fãs e daquelas imagens das garotas desmaiando e chorando quando viam John, Paul, George e Ringo? É mais ou menos o que acontece conosco sempre que publicamos uma nova coluna.
Está certo, bem, talvez isso seja um pouco de exagero. Mas é claro que muitas pessoas – tanto homens quanto mulheres – suspiram ao ler uma das nossas colunas.
De qualquer forma, observe o script na Figura 1, que usa o provedor BCD para determinar qual é o sistema operacional usado por um computador no momento. Antes de tentar executá-lo, você deve saber que é preciso estar em execução como administrador, ou haverá falha no script.
Figura 1 Conhecendo o sistema operacional atual
Const BcdLibraryString_Description = &h12000004
Const Current = "{fa926493-6f1c-4193-a414-58f0b2456d1e}"

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.OpenObject Current, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
Wscript.Echo "Current operating system: " & objElement.String
E não, isso não significa que basta estar conectado a uma conta com privilégios de administrador. Isso quer dizer que você precisa abrir uma janela de prompt de comando clicando com o botão direito do mouse em Prompt de Comando no menu Iniciar e selecionando Executar como administrador. Só assim é possível executar esse script no prompt de comando.
Então, como isso funciona? Sabe, estávamos receosos de que você perguntar. Mas, tudo bem, tentaremos explicar da melhor forma possível (que, não bastasse, deve esfriar as coisas, pelo menos por um tempo).
Começamos definindo duas constantes: BcdLibraryString_Description e Current. BcdLibraryString_Description se refere ao objeto que queremos recuperar; nesse caso, esse objeto contém Description (nome) do sistema operacional atual.
Aliás, essa é uma das doces peculiaridades do trabalho com o provedor BCD. Normalmente, você não apenas recupera o valor de uma propriedade, e sim usa um desses valores de constantes (além do método GetElement) para recuperar outro objeto e, em seguida, o valor de uma propriedade que pertença a esse objeto. É claro que isso é meio bobo, mas você sabe o que eles dizem: chegar lá é só metade da diversão.
Observação O tipo faz você se preocupar com aonde eles estavam indo, não é?
O mesmo acontece com a constante Current, bem, se trata de um GUID que representa o sistema operacional em uso atualmente. O valor
{fa926493-6f1c-4193-a414-58f0b-2456d1e}
é considerado um GUID "bem conhecido" (que, não bastasse, prova que as pessoas na Microsoft realmente têm senso de humor).
Apesar do fato desse GUID ser bem conhecido, fomos além e incluímos o valor mesmo assim, apenas caso algum dos leitores deste artigo não consiga se lembrar de qual destes valores está correto:
{fa926493-6f1c-4193-a414-58f0b2456d1e}
{fa926493-6f1c-4193-a414-58f0b2456d1f}
Observação Caso você esteja se perguntando, GUID pode ser pronunciado como "gwid" ou "goo-id". Poderíamos dar mais informações como o fato de que o GUID anterior deve ser V1, vendo como o terceiro grupo de dígitos começa com 4. Mas, fizemos uma promessa de tentar e manter o entusiasmo ao máximo. E cumprimos as nossas promessas.
Como talvez tenha imaginado, você precisará usar constantes, valores hexadecimais e GUIDs em todos os lugares ao trabalhar com o provedor BCD. Não podemos abordar todos esses itens na coluna deste mês, mas você pode visitar a página do BCD que mencionamos anteriormente no MSDN® (go.microsoft.com/fwlink/?LinkId=116953) para obter mais informações. E se você consegue suportar tamanho entusiasmo, aí está.
Depois de definir as nossas duas constantes, nos conectamos ao serviço WMI no computador local. É possível usar esse script para recuperar os dados de configuração da inicialização de uma máquina remota? Claro que sim.
Sinceramente, se não fosse possível, o valor desse negócio de BCD seria apenas mínimo. Para recuperar os dados de configuração da inicialização de uma máquina remota (mais uma vez, Windows Vista ou Windows Server 2008 deve estar em execução no computador remoto), basta atribuir o nome da máquina à variável strComputer:
strComputer = "atl-fs-001"
Também devemos salientar alguns itens importantes da nossa cadeia de conexão da WMI. Para começar, você talvez tenha percebido que incluímos privilégios de backup e de restauração em nossa cadeia de conexão; é isso o que a construção {(Backup,Restore)} faz. Isso é importante? Bem, caso você queira que o script funcione, isso é muito importante: dessa forma, se você não incluir explicitamente esses dois privilégios, haverá falha no script.
Segundo, observe que não nos conectamos ao namespace root\cimv2, o mais usado em scripts de administração do sistema. Na verdade, nos conectamos ao namespace root\WMI e nos associamos diretamente à classe BCDStore. É essa a função desse trecho de código:
"\root\wmi:BcdStore"
E não, essa não era a parte legal. Ela ainda está por vir.
Muito embora possa haver uma ou outra exceção uma aqui, outra ali, qualquer script BCD escrito irá, no geral, começar com as mesmas três etapas: definir as constantes, se conectar ao serviço WMI e abrir o armazenamento do BCD. Já concluímos as etapas 1 e 2. A seguinte linha de código se refere à etapa 3:
objStoreClass.OpenStore "", objStore
Como dissemos, aqui estamos abrindo o armazenamento BCD, a entidade de sistema operacional que armazena todas as informações de configuração da inicialização. Para abrir o armazenamento, basta chamarmos o método OpenStore, passando a ele dois parâmetros:
  • uma cadeia de caracteres vazia ("") Isso informa ao script que queremos abrir o armazenamento padrão.
  • objStore. Trata-se de um parâmetro "de saída" que fornecemos ao script. Damos ao método o nome de uma variável e, em sinal de gratidão, o método retorna um objeto (nesse caso, um objeto que representa o armazenamento BCD) que usa o nome da variável como uma referência de objeto.
Assim que o armazenamento é aberto, podemos usar o método OpenObject para recuperar mais um outro objeto (armazenado no parâmetro de saída objDefault):
objStore.OpenObject Current, objDefault
E que novo objeto é esse? É isso mesmo: a versão do sistema operacional atualmente em uso. Isso é algo que conhecemos porque passamos a OpenObject a constante Current, o GUID bem conhecido que representa o sistema operacional atual.
Tudo bem, então agora sabemos qual é o sistema operacional atualmente em uso no computador, certo? Bem, quase. Para obter essas informações, ainda precisamos usar GetElement para recuperar um objeto que represente a descrição desse sistema operacional:
objDefault.GetElement _
  BcdLibraryString_Description, objElement
Agora, você promete que não se entusiasmará demais e sairá em meio a uma bagunça generalizada? Muito bem. Nesse caso, podemos contar que agora é possível recuperar o valor da propriedade String e – finalmente! – determinar o sistema operacional atualmente em uso no computador:
Wscript.Echo "Current operating system: " _
  & objElement.String
Por favor, mantenha a calma. Lembre-se da sua promessa: nada de bagunça generalizada. Sim, sabemos o quanto é difícil. Apenas faça o melhor que puder. Tente respirar bem fundo. Isso sempre funciona conosco quando estamos escrevendo scripts BCD.
Como dissemos, há muitos problemas a serem enfrentados apenas para determinar qual é o sistema operacional em uso em um computador. Há formas muito mais fáceis de realizar essa tarefa. No entanto, o lado bom é que agora você compreende como funciona um script BCD, o que significa ser possível fazer coisas que os escritores de scripts jamais puderam fazer. (Calma, calma!) Por exemplo, em computador de inicialização múltipla, um sistema operacional permanece sempre marcado como sendo o "padrão". Se um computador for reiniciado e não houver nenhum outro, o computador carregará automaticamente o sistema operacional padrão. Antes do Windows Vista (e o provedor BCD), não havia como um criador de scripts determinar o sistema operacional padrão de um computador. Mas agora isso é tão fácil quanto executar um script como o mostrado na Figura 2.
Figura 2 Determinando o sistema operacional padrão
Const BcdLibraryString_Description = &h12000004
Const BootMgrId = "{9dea862c-5cdd-4e70-acc1-f32b344d4795}"
Const DefaultType = &h23000003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
    strComputer & "\root\wmi:BcdStore")
objStoreClass.OpenStore "", objStore

objStore.OpenObject BootMgrId, objBootMgr

objBootMgr.GetElement DefaultType, objDefaultOSIdentifier
objStore.OpenObject objDefaultOSIdentifier.Id, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
WScript.Echo "Default operating system: " & objElement.String
Você tem razão: isso pede um pouco de bagunça generalizada, não é? Tá, mas só um pouquinho, hein? Não explicaremos esse script detalhadamente. Supondo que não tenha ignorado os 10 ou 12 parágrafos anteriores, você deve ser capaz de acompanhar a lógica por conta própria. No entanto, você pode observar que, para identificar o sistema operacional padrão, precisamos executar uma etapa imediata: precisamos usar o método OpenObject para abrir uma instância do objeto Boot Manager. Depois de abrirmos o Gerenciador de Inicialização, podemos usar a constante DefaultType para recuperar um objeto que represente o sistema operacional padrão.
Agora, precisamos admitir que isso é bem interessante: podemos determinar o sistema operacional atual, além do sistema operacional padrão. Mas sabe o que seria bem legal mesmo? O legal seria recuperar uma lista de todos os sistemas operacionais instalados em um computador. Isso sim seria legal! Aperte os cintos e observe a Figura 3.
O que estamos fazendo aqui? Bem, para começar, estamos definindo duas constantes novas: WindowsImages, que permite recuperar instâncias de todos os sistemas operacionais que oferecem suporte ao BCD (ou seja, Windows Vista e Windows Server 2008), e LegacyImages, que permite recuperar instâncias de todos os sistemas operacionais "herdados" no computador. Depois de nos conectarmos ao armazenamento BCD, usamos o método EnumerateObjects para recuperar todas as instâncias dos sistemas operacionais compatíveis com o BCD instalados no computador:
objStore.EnumerateObjects _
  WindowsImages, colObjects
Figura 3 Localizando todos os sistemas operacionais em um computador
Const BcdLibraryString_Description = &h12000004
Const WindowsImages = &h10200003
Const LegacyImages = &h10300006

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore

objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wscript.Echo

objStore.EnumerateObjects LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Depois de EnumerateObjects realizar seu trabalho, configuraremos um loop For Each a ser executado em todos os sistemas operacionais nessa coleção. Nesse loop, usamos estas duas linhas de código para recuperar e exibir a descrição do sistema operacional:
objObject.GetElement _
  BcdLibraryString_Description, objElement
Wscript.Echo objElement.String
E, em seguida, repetimos o processo com todos os sistemas operacionais herdados instalados na máquina.
objStore.EnumerateObjects _
  LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement _
  BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Observação Compreendemos a emoção envolvida, mas, por favor, execute os scripts BCD com moderação. É provável que haja um limite até o qual o corpo humano pode agüentar a adrenalina. Grávidas, mulheres que podem engravidar, as que não podem, as que já engravidaram, ou mesmo quem não seja mulher, e sim homem, não devem executar scripts BCD sem antes consultar um médico.
Tudo bem, você não precisa consultar o médico primeiro. Mas seria interessante ouvir o que um médico diria se fosse questionado quanto à execução de scripts BCD, não seria?
Agora vamos tentar algo realmente doido: vejamos se conseguimos alterar o sistema operacional padrão. Por exemplo, vamos supor que tivéssemos um computador de inicialização dupla com o Windows Vista e o Windows Server 2008 em execução. E vamos supor que queiramos definir o Windows Vista como sendo o sistema operacional padrão. Como faremos isso? Bem, observe a Figura 4. Ela mostra uma forma de realizar essa tarefa.
Figura 4 Alterando o sistema operacional padrão
Const BootMgrId = "{9dea862c-5cdd-4e70-accl-f32b344d4795}"
Const BcdLibraryString_Description = &h12000004
Const DefaultType = &h23000003
Const WindowsImages = &h10200003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 If Instr(objElement.String, "Vista") Then
  objStore.OpenObject BootMgrId, objBootMgr
  objBootMgr.SetObjectElement DefaultType, objObject.ID
 End If
Next
Com esse script, estamos novamente abrindo o armazenamento BCD e, em seguida, usaremos EnumerateObjects para recuperar uma coleção de todos os sistemas operacionais que reconhecem o BCD instalados no computador. Daí em diante, configuramos um loop For Each a ser executado em todos os itens da coleção, usando a seguinte linha de código (agora já bem familiar) para recuperar a descrição de cada sistema operacional:
objObject.GetElement _
  BcdLibraryString_Description, objElement
Assim que contarmos com a descrição de um determinado sistema operacional, usamos a função InStr para ver se a palavra Vista é exibida em algum lugar desse valor:
If Instr(objElement.String, "Vista") Then
E você tem razão: isso parece um pouco ultrapassado, não parece? A forma mais legal seria usar o GUID do Windows Vista e abrir diretamente esse sistema operacional, sem que fosse necessário enumerar e percorrer todos os sistemas operacionais no computador.
Infelizmente, essa forma exigiria que soubéssemos o GUID do Windows Vista. Na verdade, desse jeito não precisamos saber nada (sempre um bônus para a Equipe de Scripts). Tudo o que precisamos fazer é continuar pesquisando até localizar um sistema operacional com a palavra Vista no título.
Observação E se você tiver várias instâncias do Windows Vista instaladas no computador? Bem, nesse caso, você talvez tenha que procurar uma cadeia de caracteres como Vista Ultimate ou Vista Enterprise.
Assim que localizamos o Windows Vista, usamos estas duas linhas de código para abrir o Gerenciador de Inicialização do Windows e definimos o sistema operacional padrão como, bem, Windows Vista:
objStore.OpenObject BootMgrId, objBootMgr
objBootMgr.SetObjectElement _
  DefaultType, objObject.ID
Acabou o espaço que tínhamos para a coluna deste mês. Afinal, até mesmo a Equipe de Scripts não consegue lidar com esse entusiasmo sem fim 24 horas por dia, 7 dias por semana. Mas não se preocupe, pois estaremos de volta no mês que vem com outra edição de Ei, Equipe de Scripts! Até lá, com um pouco de sorte, você já estará recuperado.
O desafio de script do Dr. Scripto
O desafio mensal que testa não apenas sua habilidade de resolver quebra-cabeça, mas também de criar scripts.

Julho de 2008: quadrados do VBScript
Está certo, é mais provável que eles sejam retângulos, e não quadrados, mas isso não está em questão. Para resolver esse quebra-cabeças, encaixe cada quadrado à direita em um espaço vazio à esquerda para formar os nomes das funções do VBScript. Cada quadrado será usado uma vez. Por exemplo:
Para resolver corretamente este exemplo, você precisa mover o quadrado OU (retângulo) até o espaço em branco na primeira palavra, e MS e OX até os quadrados em branco na segunda palavra. Isso resulta nas funções do VBScript UBound e MsgBox, como mostrado aqui:
Agora é sua vez de tentar:

RESPOSTA:
O desafio de script do Dr. Scripto
Resposta: quadrados do VBScript, julho de 2008

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

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução total ou parcial sem permissão.


Os arquivos da área de trabalho Inicializando o Windows em rede
Wes Miller

Conteúdo
Como o PXE funciona
Por dentro do RIS
WDS — o início
Outras partes envolvidas
Conclusão
Nos próximos meses, pretendo abordar o WDS (Windows Deployment Services), disponível para o Windows Server 2003 e incorporado ao Windows Server 2008. O WDS pode ser um componente muito importante na sua infra-estrutura de implantação. Por isso, quero garantir que você tenha uma boa base para o debate. Esta
primeira coluna traz detalhes sobre a arquitetura do PXE (Pre-boot eXecution Environment; pronunciado como pixie); a história do RIS (Serviços de Instalação Remota); e também outras tecnologias relacionadas ao PXE usadas na Microsoft.
Quando passei a integrar o grupo principal de sistema operacional do Windows, em 2001, o RIS foi uma das tecnologias que herdei (e fiquei um pouco intimidado em assumi-lo, devido à complexidade e à dependência em relação às implementações do BIOS e ao hardware). Mas foi, juntamente com o Windows® PE, uma das tecnologias que mais apreciei na minha função de gerente de programa.
Lembro-me da primeira vez que instalei o Windows 3.0 — usando um conjunto de disquetes de 3,5". Com o passar do tempo, a instalação tornou-se mais fácil, graças aos CDs inicializáveis (incluídos em algumas versões do Windows 98). Mesmo assim, a instalação sempre exigia algum tipo de mídia local, além de um disco rígido local.
Ao longo dos anos, a capacidade de inicializar o Windows em rede — ou seja, inicializá-lo totalmente via rede, sem precisar de um disco rígido — tem sido uma solicitação constante dos clientes. Embora algumas versões anteriores do Windows tivessem essa capacidade, o Windows NT® nunca teve. E, embora as versões atuais do Windows Server® 2003 e do Windows Server 2008 possam ser inicializadas por meio de um iniciador iSCSI, o processo é muito diferente, por não ser realmente local — requer uma dependência contínua de uma unidade remota, usada como unidade de inicialização.
Pré-configuração de clientes
  • Avaliação do processo de pré-configuração do cliente RIS
  • Planejamento do aprimoramento da segurança de rede com o uso de clientes pré-configurados
  • Computadores clientes pré-configurados
  • Instalação remota de sistema operacional
A partir do Windows 2000, a Microsoft começou a desenvolver a tecnologia que, por fim, viria a ser chamada de RIS, e que permitiria a instalação baseada em rede. A meta do RIS era relativamente simples: colocar uma imagem do sistema operacional no disco local do computador de destino usando o PXE.

Como o PXE funciona
A Figura 1 mostra a seqüência de inicialização PXE. O PXE é um protocolo relativamente simples, desenvolvido pela Intel e por outros fornecedores como parte da iniciativa Wired for Management. O PXE é derivado do protocolo DHCP, que deriva, por sua vez, do BootP, sendo tipicamente implementado na NIC (placa de interface de rede). Simplesmente, eis aqui o que acontece:
Figura 1. Seqüência de inicialização PXE (clique na imagem para ampliá-la)
Etapa 1. O BIOS do sistema é inicializado e determina a ordem de inicialização.
Etapa 2. Se a ordem de inicialização colocar o PXE à frente dos discos rígidos, unidades flash ou CD-ROMs, ou então se nenhum desses dispositivos estiver presente, a UNDI (interface de driver de rede universal) será carregada a partir da NIC. A NIC conta com um driver de dispositivo de rede muito pequeno e com uma implementação do protocolo TFTP (algumas implementações do BIOS exigem que os usuários finais pressionem a tecla F12 para fazer a inicialização PXE. Esse comportamento não é padrão e prefiro ter a possibilidade de desativá-lo).
Etapa 3. O sistema começa a fazer uma difusão simples no protocolo UDP, em busca de um servidor DHCP. Essa é, na verdade, a primeira etapa da seqüência de inicialização PXE, denominada Descoberta. Observe que o protocolo usado é o UDP — ou seja, se você ainda não fez isso, precisará dedicar algum tempo a seus roteadores e comutadores, para garantir que todas as comunicações do PXE cheguem ao destino.
Etapa 4. Se um servidor DHCP receber a difusão, responderá de forma adequada, com um endereço IP. Essa etapa é chamada de Oferta. Neste momento, é importante lembrar-se de que o PXE não tem monitoração de estado, e a quantidade de informações de estado exclusivas do sistema que o cliente tem a oferecer neste ponto é muito limitada (o endereço MAC e, se disponível, o GUID do BIOS de gerenciamento de sistema, também conhecido como GUID SMBIOS).
Etapa 5. O cliente, depois de receber o pacote com o endereço IP, declara que precisa de mais informações — especificamente, o endereço do servidor PXE. Ocorre outra difusão, incluindo as informações do servidor DHCP que havia respondido. Neste ponto, é como se o cliente dissesse ao servidor DHCP: "Preciso de mais informações — especificamente, a localização de um NBP (programa de inicialização de rede)." Essa etapa é chamada de Solicitação.
Etapa 6. O servidor PXE responde com o endereço do servidor PXE e a localização do NBP, um executável de inicialização muito pequeno, que precisa ter menos de 32 KB. Essa etapa é chamada de Confirmação. Se você está acompanhando a seqüência, repare que as etapas formam o acrônimo DORA (Discover, Offer, Request, Acknowledge, ou seja, Descoberta, Oferta, Solicitação, Confirmação), o que pode ajudá-lo a memorizá-la.
Se você instalou o Microsoft DHCP e o WDS (ou usou tecnologias de outro fornecedor), a etapa de solicitação não ocorrerá. Na verdade, o pacote original de Oferta do servidor DHCP já inclui a localização do servidor PXE e do programa NBP (isso elimina duas etapas, reduzindo também o tempo necessário).
Etapa 7. O cliente, que tem a pequena pilha de protocolos TFTP mencionada anteriormente, baixa o NBP da localização na rede especificada pelo servidor PXE. O TFTP é um protocolo datado, muito pequeno e sem monitoração de estado. Não foi escolhido por conta da segurança nem do desempenho; por isso, muitos administradores de roteadores o desabilitam por padrão. Ele deve ser habilitado para que o PXE funcione.
Muitas implementações do PXE (inclusive o RIS) incluem a capacidade de solicitar ao usuário que pressione F12 para continuar, neste ponto, mas geralmente isso pode ser desabilitado pelo administrador do servidor PXE. No mês que vem, quando entrar em mais detalhes sobre o WDS, explicarei alguns aprimoramentos que a Microsoft acrescentou ao TFTPD (TFTP Daemon) no WDS para Windows Server 2008, a fim de obter melhor desempenho.
Etapa 8. O NBP é inicializado. No caso do RIS, isso aciona um carregador de inicialização do Windows, que dá início ao processo para levar a implantação adiante. O PXE (pelo menos o atual protocolo em nível de inicialização) não é mais um componente do processo.
É importante lembrar-se de que o PXE (seja com RIS, WDS ou qualquer outra infra-estrutura) não funciona bem em links lentos (pois pode transferir volumes consideráveis de dados) nem em links de alta latência, como satélites (o desempenho da comunicação simplesmente não é suficiente, e talvez nem consiga se manter).
Observe que, no processo de inicialização PXE, quando o cliente envia a solicitação, nenhum elemento pergunta especificamente: "Você é minha mãe?" Simplesmente, não há muitas informações de estado que se possa obter sobre o servidor PXE. O que geralmente ocorre é uma condição de corrida, na qual o primeiro servidor a responder à solicitação do seu cliente sairá vencedor. Algumas coisas podem ajudar a minimizar esse problema:
  • Ajuste a velocidade de resposta de um ou outro servidor PXE. A latência da rede e a potência dos servidores afetarão a velocidade de resposta dos servidores. Na verdade, na Microsoft, os servidores usados pela TI eram tão bons que, mesmo se o servidor PXE estivesse no seu escritório, os servidores corporativos algumas vezes saíam vencedores. Nesse caso, basta ajustar o seu servidor PXE local para não ter nenhum tempo limite para os seus clientes pré-configurados.
  • Pré-configure os clientes. Isso será muito importante se você manipular seu servidor PXE para responder antes dos outros servidores de TI corporativos. Pré-configurando seus clientes, você permite que o Active Directory® informe ao WDS ou ao RIS que sim, na verdade, "eu sou sua mãe". Observe que o uso do GUID SMBIOS é a forma preferida de identificação exclusiva dos sistemas no Active Directory. No entanto, se não houver um GUID SMBIOS implementado nos sistemas (o que é mais provável em hardware relativamente antigo), você poderá (e precisará) usar um GUID baseado no endereço MAC. Para obter mais informações, consulte a barra lateral "Pré-configuração de clientes".
  • Não permita que as comunicações do PXE passem por comutadores ou roteadores; coloque um servidor PXE de cada lado. O aspecto negativo desse procedimento é o alto custo de implementação e de manutenção (cada servidor precisa ter sua imagem mantida).
Os servidores RIS (e agora os WDS), assim como os servidores Microsoft DHCP, precisam ser autenticados em relação à implementação do Active Directory à qual estão associados. O objetivo é reduzir os possíveis problemas causados por servidores PXE não autorizados (como difusões PXE em excesso), permitindo que o Active Directory tenha conhecimento de todos esses servidores.
Observe que essa proteção só se aplica a servidores dos quais o Active Directory tem conhecimento. Se você configurar seu próprio domínio ou um servidor PXE que não seja da Microsoft, não será esse o caso.
Uma vez, na Microsoft, um funcionário excessivamente dedicado configurou um servidor PXE não-RIS com uma implementação sem interação humana. Essa implementação resultou no apagamento completo do disco rígido e na geração de uma nova imagem. Não haveria problema se a implantação tivesse ocorrido em um laboratório isolado (fora da rede). Só que, infelizmente, não foi assim: acabou apagando o disco de um executivo da Microsoft que tinha o PXE antecipado em sua ordem de inicialização, à frente do disco rígido.
Isso não deveria ser um problema, pois a TI da Microsoft sempre exigiu o pressionamento de F12 para fazer a inicialização PXE, mas esse servidor PXE não tinha atraso, prompt para pressionar F12 nem qualquer tipo de notificação. Ou seja, o executivo perdeu mesmo seu computador e todos os dados não protegidos pelo perfil de usuário móvel.
Que essa história sirva para destacar a necessidade de isolar seus servidores PXE, caso você pretenda usar uma implementação sem interação humana, ou pelo menos de exigir o pressionamento de F12.

Por dentro do RIS
Eu herdei o RIS após o lançamento do Windows 2000. O tempo não havia favorecido o Windows 2000 no que se referia ao RIS — e restrições de testes, de desempenho e de outros tipos fizeram com que o RIS para Windows Server 2000 fosse usado somente na implantação do Windows 2000 Professional. Infelizmente, os produtos de servidor não podiam ser implantados via RIS. O Windows 2000 estava disponível somente para computadores x86. Então, mostrou-se um bom ambiente de teste para o RIS, por envolver um único produto em uma única arquitetura. O RIS incluía (e exigia) integração completa com o Active Directory, integrado, por sua vez, ao servidor Microsoft DHCP, e incluía seu próprio TFTPD.
O RIS usa o NBP para continuar o download do TFTP — e obter uma parte suficiente do kernel do Windows para iniciar o processo de instalação (em um certo ponto, quando o Windows já fez a alternância do TFTPD para uma conexão com o servidor baseada no protocolo SMB, o caminho de código literal, na verdade, é compartilhado com uma instalação tradicional, iniciada por disquete, do Windows 2000 ou Windows XP). Após o Windows em modo nativo ter sido inicializado, a instalação do Windows inicia o Assistente OSC (OS Chooser) do RIS.
As telas do OSC são páginas relativamente configuráveis, semelhantes ao HTML 2.0. Têm restrições rígidas e não podem conter imagens ou elementos semelhantes. Na verdade, não podem conter caracteres não-ANSI (o que tornou complicada a implantação de certas localidades do Windows).
O produto final do RIS é um arquivo txtsetup.sif que reside no servidor RIS. Quando o Assistente OSChooser é concluído, o cliente passa por uma "reinicialização suave", mas as localizações do servidor RIS e do arquivo txtsetup.sif são retidas e recarregadas após essa reinicialização. Esse arquivo txtsetup.sif é essencialmente igual a um arquivo unattend.txt, com vários campos adicionais incluídos para ajudar o RIS a concluir o processo de instalação.
O RIS também era capaz de realizar uma instalação muito parecida com a instalação autônoma tradicional (RISetup). Ele tinha uma infra-estrutura baseada em clonagem semelhante ao Sysprep (RIPrep) e, na verdade, compartilhava código com ele. Mas o RIPrep podia também carregar a própria imagem em um servidor RIS.
No entanto, o RIS tinha algumas limitações fundamentais que ganharam visibilidade. A primeira era a ausência de suporte para a implantação de servidores. Alguns vírus, como o Code Red e o Sasser, combinados às complexidades de TI enfrentadas por vários clientes importantes na recuperação da tragédia de 11 de setembro de 2001, levaram-nos a acelerar o desenvolvimento de uma solução para os servidores RIS Windows 2000 existentes, permitindo a implantação do Windows Server. Já estávamos trabalhando nisso para o Windows Server 2003, mas ainda não havia ocorrido um lançamento formal.
Mais detalhes sobre tecnologias relacionadas ao PXE
  • Descrição da interação PXE entre cliente PXE, DHCP e servidor RIS
  • Planejamento de implantações de sistema operacional iniciadas pelo PXE
  • Arquitetura do PXE
  • Serviços de Instalação Remota
  • Instalação remota de sistema operacional
  • Guia passo a passo para a instalação remota de sistema operacional
  • Provedor PXE do WDS
  • O que são os Serviços de Instalação Remota?
  • Serviços de Implantação Automatizada do Windows Server 2003
Em segundo lugar, o RIS não tinha a capacidade de automatizar completamente o Assistente OSChooser, o que foi habilitado mais tarde com o elemento <META ACTION="AUTOENTER">, no Windows Server 2003. Por fim, o OSChooser não funcionava corretamente com caracteres não-ANSI — um ponto fraco importante, destacado por vários clientes fora dos Estados Unidos.
Como resultado, era impossível concluir uma instalação do RIS com um teclado francês, por exemplo. Fazer com que caracteres não-ANSI funcionassem com segurança no nível do BIOS em PCs de todas as partes do mundo era algo extremamente complexo e de difícil realização.
Com o lançamento do Windows Server 2003, acrescentamos formalmente suporte para a arquitetura Intel Itanium e para todas as variantes de servidores do Windows 2000 e do Windows Server 2003. O Windows Server 2003 deu mais um passo adiante, com o suporte para a arquitetura x64.
O RIS tinha também um TFTPD consideravelmente reescrito para aumentar o desempenho. O Windows Server 2003 oferecia suporte à inicialização de até 75 clientes ao mesmo tempo. Tenha em mente que o limite superior é alcançado à medida que o pipe SMB é preenchido com o tráfego da rede para os clientes.

WDS — o início
Quando começamos a trabalhar no RIS para o "Longhorn" (o codinome do que viria a ser o Windows Server 2008), tornou-se claro que precisávamos dar um passo para trás. Como mencionei antes na minha coluna, já vínhamos apostando alto na instalação baseada em imagem (WIM) desde o Windows PE. Como resultado, o princípio fundamental subjacente ao WDS era a implantação baseada em imagem, a partir de uma instância do Windows PE inicializada com o PXE.
Também sabíamos que o Windows Server 2003 seria a plataforma comum para a implantação do Windows Vista®, e que precisaríamos de uma solução "fora de banda" para o nível inferior do WDS. Como resultado, o WDS podia ser executado no Windows Server 2003 SP1 e foi incorporado ao Windows Server 2003 SP2.
Por poder operar como um servidor RIS (modo herdado), um servidor híbrido (modo misto) ou um servidor somente WDS (modo nativo), o WDS permite a migração para implantações formais em estilo WDS, conforme prometido. Já ouvi clientes perguntarem se existe uma forma de instalar o RIS em um sistema Windows Server 2003 SP2. Sim, existe: basta instalar o WDS e executá-lo no modo herdado. A Figura 2 mostra os sistemas operacionais com suporte.
Figura 2. Plataformas com suporte para implantação
Sistema operacional | RIS (Windows 2000) | RIS (Windows Server 2003)** | WDS (Windows Server 2003)**** | WDS (Windows Server 2008)
Windows 2000 Pro | X | X | X | X
Windows 2000 Server | * | X | X | X
Windows XP Pro |  | X (x86 e IA64)*** | X | X
Windows Server 2003 |  | X (x86 e IA64)*** | X | X
Windows Vista |  |  | X | X
Windows Server 2008 |  |  | X | X
* support.microsoft.com/kb/308508 e support.microsoft.com/kb/313069 acrescentaram suporte para o Windows 2000 Server via RIS. ** Os modos herdado e misto do WDS oferecem suporte à mesma matriz para instalações herdadas. *** O Windows Server 2003 SP1 acrescentou suporte para sistemas baseados em x64. Os sistemas IA64 ofereciam suporte somente à instalação baseada no RISetup. **** Suporte ao modo nativo.
O WDS no Windows Server 2003 SP1 e SP2 visava iniciar o processo de migração para o WDS. Como já mencionei, os principais recursos acrescentados ao WDS no Windows Server 2008 foram um TFTPD revisado, o suporte para a inicialização do padrão EFI e, é claro, a implantação baseada em multicast.

Outras partes envolvidas
O ADS (Serviços de Implantação Automatizada) foi criado por outra equipe da Microsoft, com a meta principal de realizar o provisionamento rápido de servidores. O ADS contava com geração de imagens formal baseada em setor, agente de inicialização próprio (menor do que o Windows PE, mas sem contar com toda a sua funcionalidade), TFTPD próprio e multicast muito avançado. As funções incorporadas no ADS foram disponibilizadas, até certo ponto, no SCCM (System Center Configuration Manager), embora não haja paridade total entre os recursos.﻿
O Windows XP Embedded contava com inicialização PXE completa por meio de TFTPD próprio em um RAMDisk, mas não podia ser implantado remotamente dessa forma. A tecnologia foi projetada para dar suporte à inicialização de vários sistemas a partir da mesma imagem de disco, ao mesmo tempo, via PXE.

Conclusão
Em suma, a história é essa. Para saber mais, consulte a barra lateral "Mais detalhes sobre tecnologias relacionadas ao PXE". No mês que vem, me aprofundarei nos fundamentos do WDS. Em seguida, virão colunas sobre os recursos avançados do WDS (multicast e outros) e, por fim, como usar o WDS sem usar o WDS, ou seja, como ir além da experiência existente de WDS/instalação para criar suas próprias técnicas de implantação.

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

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.


Security Watch Senhas e cartões de crédito, Parte 1
Jesper M. Johansson

Conteúdo
Aviso de segurança não acionável
Não acionável e incorreto
Aviso incompreensível
As armadilhas da autenticação de site baseada na imagem
Recentemente, fui contatado pela Universidade de Minnesota para ser entrevistado para esta revista. Aparentemente, eles queriam mostrar alguns alunos bem-sucedidos e – como não conseguiram encontrar nenhum – acabaram me escolhendo. A entrevistadora me perguntou no que eu trabalhava, e passei alguns minutos tentando descrever um software para infra-estrutura de segurança
. Daí ela exclamou: "mas isso parece muito complicado! Para mim, segurança quer dizer senhas e cartões de crédito".
Pensei nessa reação por alguns minutos e percebi que ela estava, de certa maneira, muito certa. A segurança está, de fato, relacionada a senhas e cartões de crédito. Pelo menos, é isso o que importa para o usuário final. Nós, que trabalhamos na atividade, achamos que segurança diz respeito a algoritmos criptográficos, se Kerberos é uma opção melhor do que TLS ou NTLMv2, os méritos do WS*, se devem ser usados hashes de senha e todos os demais tópicos esotéricos que adoramos discutir. É claro que temos uma perspectiva muito diferente e aprofundada em relação aos usuários finais, mas, de modo geral, perdemos uma coisa fundamental de vista: segurança, para aqueles a quem devemos servir, está relacionada a senhas e cartões de crédito.
Tudo bem, todo aquele esoterismo que tanto amamos discutir e as novas tecnologias que adoramos inventar são justamente para proteger os dados do usuário. Ainda assim, acho que nos perdemos. Nós, a subcultura de segurança do mundo de TI, existimos para atender a uma determinada necessidade de nossos clientes: a necessidade de manter os dados em segurança. Isso, obviamente, inclui garantir a possibilidade de uso desses ativos de TI com segurança. É isso.
Nas colunas anteriores, comentei que ninguém sai por aí e compra um computador só para poder executar um software antivírus. O usuário compra um computador para usar o banco eletrônico online, executar jogos de computador, escrever emails, fazer o dever de casa ou alguma outra função importante. Da mesma forma, nenhuma empresa financiou um grupo de segurança de TI só para que pudesse implementar NTLMv2. As empresas financiam grupos de segurança de TI para que estes possam proteger os ativos da organização, o que permite a elas usar seus recursos de TI com grande segurança e atingir seus objetivos comerciais.
A nossa existência não é outra senão servir.
Sendo assim, devo perguntar se estamos, de fato, fazendo um bom trabalho "servindo" ultimamente. Ou nós, da subcultura de segurança, estamos, na verdade, mais atrapalhando do que ajudando? E os legisladores e as reguladoras estão contribuindo para que atrapalhemos? Não estou convencido de que toda essa nova tecnologia que estamos colocando em prática realmente ajude os usuários finais. Por isso, gostaria de explorar algumas áreas às quais nós, os provedores de TI do mundo, estamos fazendo mais mal do que bem.
Há dias em que a maior parte dos avisos de segurança e das muitas tecnologias de segurança que impomos a nossos usuários é não acionável, incorreta, incompreensível ou (em muitos casos) uma combinação das três. Nesta série em três partes, observarei algumas das formas com as quais confundimos os usuários ao dar avisos e implantar tecnologias, culpados por uma ou mais dessas três características negativas.

Aviso de segurança não acionável
Uma das melhores formas de confundir as pessoas é dar avisos de segurança não acionáveis. De lambuja, também é possível fazer isso de maneira incorreta. A Figura 1 ilustra um aviso totalmente inútil, teoricamente importante e bastante antigo.
Figura 1 Aviso de segurança não acionável (Clique na imagem para ampliá-la)
Está vendo onde se diz para usar uma senha diferente para cada conta online? Há trinta anos, essa recomendação fazia sentido. O número de pessoas naquilo que acabou se transformando na Internet estava próximo dos milhares e todas elas eram bem espertas para não escolher senhas lá muito boas. Infelizmente, esse aviso se manteve e continua sendo repetido sempre, não havendo esforço aparente para adaptá-lo à forma como os computadores são usados atualmente.
Quantas contas online você tem? Particularmente, tenho 115, considerando algumas que não acompanho. O aviso na Figura 1 não apenas sugere que eu deva ter 115 senhas diferentes, mas também que preciso alterar essas 115 senhas passados entre 30 e 60 dias. Em outras palavras, preciso trocar entre duas e quatro senhas diariamente. (Faça o cálculo: isso também quer dizer que teria entre 690 e 1.380 senhas por ano.)
Embora a equipe de suporte técnico de alguns sites que estejam dando o aviso possa ser capaz de suportar quatro senhas boas por dia e manter 115 senhas atuais na memória a curto prazo, é possível ter a certeza de que 99,99 por cento do público que surfa na Web não conseguirá isso.
Na verdade, o aviso para usar senhas diferentes em todos os lugares está correto e é importante, de um ponto de vista essencialmente teórico, por ser o aviso para alterar todas as senhas passados entre 30 e 60 dias. Mas esse aviso também é não acionável. Com o número de senhas que os usuários têm hoje em dia, eles simplesmente não podem segui-lo sem algum tipo de ajuda como, por exemplo, papel ou software. Vejamos o próximo exemplo.

Não acionável e incorreto
O trecho do aviso mostrado na Figura 2, retirado do site de um dos maiores bancos do mundo, é não acionável e está incorreto. As informações fornecidas sob o título "Read our password advice" ("Leia o nosso aviso quanto a senhas") vão bem até a linha "different passwords everywhere" ("senhas diferentes em todos os lugares"). Ele também recomenda que você "jamais as anote".
Figura 2 Aviso não acionável e incorreto (Clique na imagem para ampliá-la)
Então, agora tenho 115 senhas diferentes, tenho que criar quatro novas diariamente e não posso anotá-las. Por um momento me achei burro porque não conseguia me lembrar de todas as minhas senhas. Depois, descobri que todo mundo faz exatamente a mesma coisa. É simplesmente impossível para seres humanos lembrar 115 senhas. Podemos lembrar e processar aproximadamente sete partes de informações – e é exatamente assim que somos programados. Acompanhando a maioria dos avisos de senha encontrados na Internet, isso não é o suficiente para uma senha sequer (consulte "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information", de George A. Miller, disponível em musanim.com/miller1956).
O aspecto negativo é que, quando o assunto é aviso de senha, o nosso setor, com bastante regularidade, engana os usuários. Se a subcultura da segurança dirá aos usuários que devem usar senhas diferentes em todos os lugares, também precisaremos informá-los como – e isso significa registrar e armazenar essas senhas em algum lugar seguro. Anotá-las em um pedaço de papel, usar um documento protegido ou uma ferramenta especializada como, por exemplo, PasswordSafe (sourceforge.net/projects/passwordsafe). Sejamos sinceros, ou anotamos as nossas senhas, ou usamos as mesmas em todos os lugares. Na verdade, uma pesquisa recente apontou que 88 por cento dos usuários usam a mesma senha em todos os sistemas nos quais se autenticam (consulte msnbc.msn.com/id/24162478).
Certamente, o aviso que recrimina anotar a senha é um fator que contribui para essa tendência. O que precisamos fazer é ensinar os usuários a gerenciar senhas (e outros dados confidenciais) de maneira efetiva, e não ensiná-los a não gerenciar essas informações de modo algum. Dessa forma, a probabilidade de que eles comprometam suas credenciais será muito menor.

Aviso incompreensível
As duas primeiras figuras repetem um aviso antigo que funcionava bem nos idos dos anos 60, 70 e 80, muito antes dos grandes usuários permanecerem online e usarem serviços baseados na Web. Pelo menos por enquanto, ninguém fez grandes reclamações quanto a esse tipo de aviso porque são informações normalmente aceitas.
Esse tipo de aviso confunde os usuários e pode fazer com que eles se sintam culpados por precisar guardar as senhas em algum lugar. Dando esse tipo de aviso, em vez de ajudar os usuários a fazer aquilo que precisam, os profissionais da segurança causam prejuízo. Afinal, não é de responsabilidade do usuário imaginar como gerenciar a segurança. Isso cabe aos profissionais de segurança. Precisamos imaginar formas aceitáveis para que nossos usuários gerenciem suas contas online. Mas, como a maior parte das diretrizes acaba repetindo o mesmo aviso ultrapassado, os usuários recorrem a anotações adesivas e planilhas para acompanhar suas muitas senhas.
Como mecanismo de autenticação, as senhas têm muito a oferecer. Porém, o principal problema é que seres humanos são péssimos quando chega a hora de se lembrar delas. Em vez de tentar resolver um problema da natureza humana, o mundo de TI continua inventando todos os tipos de mecanismo para substituir senhas – ou, pior ainda, aumentá-las. Isso só deixa os usuários ainda mais confusos.
Imagine a minha surpresa na última vez em que acessei um determinado site de serviços financeiros e vi uma tela de logon que apresentava apenas uma caixa de texto do nome de usuário (consulte a Figura 3).
Figura 3 Onde digito a minha senha?
Inicialmente, pensei se tratar de algum site mal-intencionado. Depois, validei rapidamente o site – essa etapa foi simples porque ele apresentou um certificado – e percebi que estava, de fato, no lugar certo. O problema é que as pessoas estão acostumadas a ver dois campos, nome de usuário e senha, apresentados juntos no logon em um site. Isso se deve a anos encontrando o mesmo fluxo de trabalho comum. Assim, quando você chega a um site que, inesperadamente, pede apenas o nome de usuário, as coisas começam a se complicar. Acontece que, nesse caso, o provedor tinha implementado uma tecnologia que usava imagens para identificar o site aos usuários, em uma tentativa de impedir ataques de phishing. Assim, quando você preenche o nome de usuário, o site exibe uma tela pop-up com uma imagem identificável, como mostra a Figura 4.
Figura 4 Alguns sites agora usam imagens para autenticar o site para um usuário(Clique na imagem para ampliá-la)
A teoria é de que você conhece a imagem de cada site. Caso não seja exibida a imagem correta, é possível identificar o site como sendo falso. Isso, por si, é um conceito interessante. Supondo que o usuário saiba a imagem de cada site, essa estratégia tem algum sentido.
É claro que o leitor mais esperto perceberá a barra de endereços verde na Figura 4. Isso significa que o site usa certificados SSL e EV (validação estendida), motivo pelo qual a barra de endereços está verde. Isso também quer dizer que toda a premissa de usar a imagem para identificar o site não agrega valor algum. Na verdade, a imagem não faz muito senão criar confusão pelo menos para alguns usuários finais. O site já se identificou para o usuário – ele apresentou um certificado contendo o nome da empresa, o endereço do site e o nome do emissor confiável. E o fato da barra de endereços estar verde me diz que a empresa chegou a executar a etapa adicional de pagar três vezes mais por um certificado EV.
Assim, é claro que as imagens também podem ser falsificadas. Caso o usuário possa enviar sua própria imagem, há formas pelas quais o invasor pode imaginar que imagem está sendo usada. Como também existe uma boa chance de que o usuário use a mesma imagem em todos os sites, tudo o que o invasor terá que fazer é criar um site com o conteúdo a ser avaliado pelo usuário (deixarei você apresentar exemplos próprios) e pedir a ele uma imagem a ser usada na verificação do site. Se o usuário utilizar a mesma imagem para todos os sites, esse novo site agora terá acesso à imagem utilizada pelo usuário, por exemplo, no site do banco eletrônico.
Embora alguns sites permitam que você escolha sua própria imagem, há outros que usam uma biblioteca de fotos em estoque. O site na Figura 4, por exemplo, conta com 318 fotos em estoque a serem escolhidas. O truque anterior não funciona em sites que não permitam ao usuário enviar suas próprias fotos. No entanto, se o usuário não escolher uma imagem própria, a probabilidade de que ele se lembre de qual site é cada figura será pequena em sites não visitados com freqüência. Honestamente, não tenho idéia de qual imagem uso no site mostrado na Figura 4, embora possa garantir que não se trata da mostrada na captura de tela.
O problema dessa abordagem baseada na imagem é que um invasor pode mostrar qualquer uma das 318 imagens ou apenas escolher uma foto aleatória do Flickr, e muitos usuários acabarão supondo que essa seja a imagem correta. Se a maioria das pessoas conseguisse se lembrar de coisas como a figura de cada site, não teríamos todos os problemas relacionados a phishing e segurança que temos atualmente.
E por que usar uma imagem para autenticar o site para o usuário quando o site já se autenticou usando o certificado? Por que não usar apenas esse certificado e ajudar os usuários a aprender como validá-los? Os certificados já provaram a identidade do site para o usuário.
O processo para obter um certificado certamente é muito mais seguro do que o processo para obter a imagem de autenticação do site de um usuário. Se o certificado for EV e você estiver usando o Internet Explorer® 7 ou o Firefox 3, o navegador chegará a realçar as informações relevantes sobre o certificado na barra de endereços. Infelizmente, o realce só funciona com os certificados EV muito caros.

As armadilhas da autenticação de site baseada na imagem
A tecnologia de autenticação da imagem tem vários problemas. Primeiro, se torna muito fácil coletar nomes de usuário em um site. Na verdade, o site mostrado na Figura 4 apresentará a caixa de diálogo exibida na Figura 5 se você digitar o nome de usuário errado. Depois de digitar um nome de usuário correto para um usuário que escolheu uma imagem secreta, você obtém a imagem secreta da pessoa. Obviamente, esse conhecimento poderia ser muito importante para um invasor que estivesse tentando coletar informações sobre um usuário.
Figura 5 Sites autenticados por imagem possibilitam uma fácil coleta do nome do usuário
O tipo de implementação mostrado aqui praticamente não tem nenhum valor em termos de segurança. O invasor pode simplesmente duplicar o fluxo de trabalho de logon em um site falso. O site falso pede e passa um nome de usuário para o site real. É possível até mesmo usar o AJAX no cliente para atualizar o formulário em tempo real para conseguir uma aparência ainda mais legal. Além disso, caso o site legítimo não tenha atenuado ataques de falsificação entre sites no formulário de logon, o código AJAX pode até mesmo enviar a solicitação para o site real diretamente, a menos que o navegador tenha atenuações para solicitações XML-HTTP entre sites.
Agora, assim que o resultado voltar, o invasor poderá analisar os dados, conseguir a imagem e exibi-la ao usuário final. Em outras palavras, qualquer invasor capaz de apresentar um site com logon falso para o usuário também pode exibir sua imagem secreta. O resultado prático é a inexistência absoluta de valor agregado com o uso da autenticação do site baseada em imagem. A imagem é exibida antes da autenticação do usuário no site e, por isso, ela permanece disponível a um invasor que tem, ou pode ter, o nome do usuário.
Supondo que o usuário jamais tenha sido instruído a procurar um certificado antes de enviar formulários – e essa é uma suposição certa, considerando que o próprio uso da autenticação de site baseada em imagem parte dessa mesma suposição –, obter um nome do usuário é simples. Além disso, como muitos esquemas de autenticação de site baseados em imagem respondem de maneira diferente a um nome de usuário válido em relação a um nome de usuário inválido, obter o nome do usuário é simples. O invasor pode fazer isso até mesmo fora de banda, antes de um ataque ser iniciado.
No final, temos usuários que acreditam estar mais seguros ou aqueles que só se confundem mais. Gastamos um grande volume do capital próprio dos acionistas implementando a autenticação de site baseada na imagem, e não dificultamos em nada para que usuários mal-intencionados convencessem os usuários finais a enviar suas credenciais para sites falsos.
Acabou o espaço que tinha para esta parte da Security Watch. Não deixe de conferir, no mês que vem, a segunda parte desta série, quando abordarei mais exemplos de práticas de segurança mal orientadas e de más implementações de autenticação.

Jesper M. Johansson é arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele possui Ph.D em MIS, tem mais de 20 anos de experiência em segurança e é MVP Microsoft em segurança corporativa. Seu livro mais recente é Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.


Anotações de campo Garanta uma eleição precisa
Josh Benaloh

Na eleição presidencial nos EUA deste ano, a opinião pública está voltada para as tecnologias de votação. À medida que analisamos as opções, a balança acaba pendendo entre a cédula contada manualmente, que é incômoda e sujeita a equívocos, urnas equipadas com alavancas, que podem ser manipuladas por pessoas com acesso e conhecimento, cartões de perfuração com seus agora famosos papéis pendurados, cédulas digitalizadas oticamente, que podem ser facilmente lidas de maneira incorreta por scanners malcalibrados, sistemas com tela sensível ao toque, que podem ser comprometidos por software mal-intencionado, além de vários híbridos, que normalmente criam mais problemas do que resolvem.
Na verdade, essa é apenas uma pequena amostra das vulnerabilidades desses sistemas. Além disso, as técnicas mais usadas em todo o mundo dependem de administradores eleitorais honestos e capacitados para manter a integridade das eleições.
Mas existe uma forma melhor: uma na qual a integridade da eleição não depende de administradores ou de equipamento. As eleições podem ser realizadas de forma que essa precisão possa ser verificada de ponta a ponta por oficiais, eleitores individuais e até mesmo observadores interessados.
Para ver isso, imagine que eleitores aptos recebam códigos que os permitam votar próximos a seus nomes em um site disponível publicamente. Os eleitores podem consultar o site para ver se os votos estão registrados corretamente, e qualquer um pode realizar uma auditoria independente para verificar se todos os eleitores são legítimos e se a contagem corresponde ao número anunciado.
Mas espere! O elemento que está faltando nessa eleição "aberta" é a privacidade. Sim, e a criptografia pode ser usada para preencher essa lacuna – daí possibilitando eleições com cédulas secretas totalmente confiáveis. Em vez de contabilizar votos brutos, os votos são criptografados com chaves públicas cujas chaves de criptografia são compartilhadas por oficiais eleitorais de forma que seja necessária sua cooperação para descriptografá-las. Uma vez encerrada a votação, os oficiais eleitorais participam de um processo cooperativo para produzir uma eleição tabulada e uma prova criptográfica de que o número corresponde precisamente ao conjunto de cédulas criptografadas.
Eleitores individuais podem verificar se as células criptografadas correspondem a suas intenções, e qualquer pessoa pode examinar a prova criptográfica para verificar se as cédulas criptografadas foram tabuladas corretamente. Dessa forma, os números da eleição podem ser verificados de ponta a ponta.
É tão simples assim? Não. Esta é uma visão geral otimista, mas há muitos detalhes que devem ser abordados com cuidado para que dê tudo certo. Por exemplo, ainda precisamos depender dos métodos tradicionais para garantir que os dispositivos de votação mantenham a privacidade adequada ao eleitor. E como os eleitores devem traduzir suas intenções em cédulas criptografadas? Eles devem ter a certeza de que os valores criptografados invioláveis contabilizados, além dos nomes, realmente correspondam ao que desejam sem que seja preciso mostrar a terceiros a correspondência (que acabam sendo suscetíveis à coerção ou à compra de votos). Além disso, devemos fazer tudo isso sem exigir que os eleitores façam algo mais complexo do que fazem atualmente nos sistemas de votação tradicionais.
Os processos eleitorais verificáveis de ponta a ponta têm sido estudados na literatura criptográfica há mais de 25 anos, e agora há formas práticas e sólidas de proporcionar a prova criptográfica da precisão dos números. Na comunidade de pesquisa, a atenção esteve recentemente voltada para o front-end apresentado ao eleitor, e foi feito muito progresso nessa área também.
A demanda comercial por tecnologia da eleição é grande, mas não é enorme. Grandes conglomerados com interesses gerais podem ser vistos com suspeição nesse mercado, porque alguns desses interesses podem beneficiar determinados resultados eleitorais. Dessa forma, esse mercado pode ser mais bem ocupado por representantes de nichos menores cujos negócios dependam da correção nas eleições. Para obter mais informações e links para métodos eleitorais que possam ser verificados, vá até research.microsoft.com/crypto/voting.

Josh Benaloh é criptógrafo sênior da Divisão de Pesquisa da Microsoft. Ele trabalhou durante oito anos no Conselho de Diretores da International Association for Cryptologic Research e dentre suas vastas publicações estão a tese de doutorado "Verifiable Secret-Ballot Elections" de 1987.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida.


Segredos do Windows A história ganhando espaço
Raymond Chen

Lembra do Microsoft Bob? Seu objetivo era ser uma interface de usuário amigável baseada no Windows® 3.1, mas, em vez disso, fracassou de forma vergonhosa (ganhando o título nada honroso como um dos piores produtos tecnológicos de todos os tempos, dado pela PC World). Nos anos que se passaram desde o fim do Bob, o produto foi relegado ao status de uma piada recorrente, sendo que a mera menção de seu nome causava risos.
Por acaso, o nome do código interno do Microsoft® Bob era "Utopia", um nome ambicioso com certeza, mas que pelo menos tinha um pouco de improvisação e ousadia. Quando soubemos que a equipe de marketing havia decidido chamar o produto de Bob, todos balançamos nossas cabeças em descrença.
Mas há mais sobre o legado do Bob do que você pode saber. Acontece que o Bob foi na verdade mais útil morto do que vivo.
Quando você pretende distribuir seu software em um CD, algo com o qual você deve se preocupar é ter certeza de que seu produto realmente cabe em um único CD. Felizmente, aconteceu que mesmo após levar em conta o espaço em disco necessário para as traduções, as ferramentas de suporte e as outras coisas que precisam entrar no CD do Windows XP, ainda havia aproximadamente 30 megabytes de capacidade de armazenamento restante. As pessoas que se preocupam com esses tipos de coisas pensaram: “Bem, já pagamos por toda essa capacidade de armazenamento do CD, então podemos muito bem usá-la, certo?”.
O nome do código interno do Microsoft Bob era "Utopia", um nome ambicioso com certeza, mas que pelo menos tinha um pouco de improvisação e ousadia. (Clique na imagem para ampliá-la)
O resultado foi uma tentativa um tanto fraca de diminuir os esforços de pessoas que gostam de fazer cópias ilegais do Windows. Alguém decidiu preencher aquela capacidade extra no CD com dados fictícios e fazer com que o programa de Instalação do Windows verificasse se os dados fictícios ainda estavam lá. Isso, a lógica concluiu, forçaria as pessoas que estavam baixando uma cópia da imagem do CD a baixar mais trinta e poucos megabytes de dados. Lembre-se, isso foi no tempo em que "banda larga" ainda não havia se tornado uma palavra doméstica e os principais usuários estavam usando conexões dial-up. Ter que transferir mais trinta megabytes de dados por um modem de 56 Kb era um obstáculo razoável para diminuir os esforços dos usuários — não que fosse diminuir muito pelos padrões de hoje.
A pessoa que foi designada a implementar essa verificação precisava de uma fonte para os dados fictícios. Bem, ele poderia simplesmente ter chamado a função CryptGenRandom para gerar 30 megabytes de bytes criptograficamente aleatórios, mas qual a diversão nisso? Em vez disso, ele pesquisou os arquivos mortos e encontrou uma cópia do Microsoft Bob. Ele pegou todas as imagens do disquete e as combinou em um grande arquivo. O conteúdo das imagens do disquete do Microsoft Bob não é particularmente aleatório, então ele decidiu misturar os dados criptografando-os. Quando chegou o momento de digitar a chave de criptografia, ele simplesmente pressionou sua mão contra o teclado aleatoriamente e daí surgiu a cópia criptografada do Microsoft Bob. Foi isso que ocupou o espaço não utilizado como dados de lastro no CD do Windows XP.
No final das contas, o Windows XP se tornou a ferramenta de implantação mais eficiente do Microsoft Bob já desenvolvida. E se você voltar ao seu armário, desenterrar sua cópia do Windows XP e puder, de alguma forma, canalizar os espíritos certos para pressionar suas mãos no teclado exatamente do mesmo modo, então, do seu programa de criptografia surgirá uma cópia do Microsoft Bob.

O site do Raymond Chen, The Old New Thing, e o livro homônimo tratam do histórico do Windows e da programação Win32. Ele se pergunta se a fusão nuclear será viável enquanto ele estiver vivo.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução total ou parcial sem permissão.