 TechNet Magazine February 2008

TechNet Magazine February 2008

SharePoint: Uma abordagem inteligente para coleta de dados na empresa

A informação é um dos ativos mais importantes em uma empresa. Mas pode ser um desafio gerenciar a montanha de dados sendo coletados por meio de emails, formulários baseados na Web, pesquisas e outros mecanismos. Vejamos como o sistema Microsoft Office pode ajudá-lo a integrar sistemas e tornar os dados mais acessíveis.

Keith Deshaies SharePoint: Criação de uma infra-estrutura de pesquisa avançada

A coleta e a análise dos dados é uma parte fundamental dos negócios, mas você precisa de ferramentas que permitirão que equipes independentes coletem os dados necessários, quando precisarem deles. Saiba como você pode usar o WSS 3.0, o MOSS 2007 e o InfoPath 2007 para criar uma solução de pesquisa completa e flexível que pode ser usada em toda a corporação.

Jim Bradley SharePoint: Padronize o gerenciamento de dados com tipos de conteúdo personalizados

O vasto número de documentos distintos e outros itens de conteúdo armazenados em grandes organizações podem dificultar o gerenciamento de documentos, seus metadados associados e seus comportamentos de uma maneira centralizada e reutilizável. Dê uma olhada em como é possível usar tipos de conteúdo no SharePoint 2007 para simplificar o gerenciamento de conteúdo na empresa.

Pav Cherny Office Communications Server: Como a presença aprimora o OCS 2007

O Office Communications Server 2007 utiliza informações sobre a disponibilidade do usuário para rotear comunicações para o local mais apropriado – quer seja o envio de uma chamada de voz, uma videoconferência, uma mensagem de email ou uma mensagem instantânea. Veja como o sistema do OCS 2007 utiliza a presença para conectar os pontos de extremidade.

Rajesh Ramanathan Office Communications Server: Planeje sua implantação de voz do OCS 2007

A integração do Office Communications Server 2007 com um sistema PBX existente pode ser uma tarefa desafiadora. Você precisa selecionar um cenário de integração, compreender o roteamento de chamadas, saber como definir as configurações de usuário, lidar com planos de números e muito mais. Mas não se preocupe. Essa visão geral mostrará a você o que é necessário saber.

Jochen Kunert and Rui Maximo Computação de alto desempenho: Uma introdução ao Windows Compute Cluster Server

Em vez de recorrer a grandes sistemas especializados, a computação de alto desempenho usa clusters de sistemas padrão menores. Disseminar a carga de trabalho dessa maneira oferece uma solução econômica para resolver problemas complexos rapidamente. Explore a funcionalidade e o suporte de cluster de computadores fornecido pelo Windows Compute Cluster Server 2003.

John Kelbley and Doug Lindsey Online Extra: Implante o 2007 Office System com os Serviços de Terminal

O sistema 2007 Microsoft Office inclui alterações de design às quais você deve estar atento antes de implantá-lo em seu farm de servidores de Serviços de Terminal. Este artigo fornece uma visão geral das alterações.

James D. Silliman Do editor: Lidando com a sobrecarga de informação

Joshua Hoffman Cartas: Com a palavra, os leitores

Caixa de ferramentas: Novos produtos para profissionais de TI

Greg Steen P+R SQL: Índices não agrupados e permissões de retenção

Saleem Hakani and Dan Carollo Utilitário em destaque: ADMX Migrator

Com o Windows Vista, o formato dos modelos de Diretiva de grupo foi alterado para uma estrutura baseada em XML. O utilitário ADMX Migrator pode converter os seus arquivos ADM herdados no novo formato ADMX, bem como ajudá-lo a criar facilmente seus próprios arquivos ADMX personalizados.

Lance Whitney The Cable Guy: Autenticação com fio IEEE 802.1X

A autenticação IEEE 802.1X fornece uma barreira de segurança adicional para acesso à sua intranet. Saiba como o Windows Vista e o Windows Server 2008 facilitam a implementação da autenticação IEEE 802.1X de sua rede com fio.

Joseph Davies Windows PowerShell: Permissões Shell

Permissões no Windows são, infelizmente, intrinsecamente complicadas. Mas o Windows PowerShell pode ajudar. Obtenha uma rápida visão geral de como funcionam as permissões no Windows e descubra como simplificar a tarefa de trabalhar com elas.

Don Jones Ei, Equipe de Scripts!: Os jogos vão começar! Ah, e algum XML também

A Equipe de Scripts da Microsoft fala sobre os Jogos de Script de 2008 e também mostra como criar, anexar e modificar documentos XML. A propósito, você ouviu falar dos Jogos de Script de 2008?

The Microsoft Scripting Guys Security Watch: Saltos de ilha: redução de dependências indesejáveis

As dependências de segurança indesejadas podem expor toda a sua rede a ataques. Saiba como as dependências de segurança funcionam para que possa analisá-las no seu ambiente e solucionar possíveis problemas.

Jesper M. Johansson Os arquivos da área de trabalho: Inicialização dupla com o Windows XP e o Windows PE 2.0

Há uma série de vantagens em realizar a inicialização do Windows PE 2.0 da mesma partição que o Windows. Aprenda como realizar a inicialização dupla do Windows XP e do Windows PE 2.0 da mesma partição e explore os problemas que isso pode resolver.

Wes Miller Anotações de campo: Doe o seu PC

Ao doar ou reutilizar hardware antigo, você mantém esse tipo de equipamento longe dos aterros sanitários. Isso ajuda a preservar o nosso ambiente. Estas dicas podem ajudá-lo a excluir de maneira efetiva dados pessoais do seu equipamento de computação antigo para que esteja pronto para reutilização.

Jim Lynch Segredos do Windows: Eliminando os recortes

Apresentamos aqui uma história sobre como alguns recursos não tão incrivelmente populares desapareceram.

Raymond Chen


 SharePoint: Uma abordagem inteligente para coleta de dados na empresa
SharePoint Keith Deshaies

Uma abordagem inteligente para coleta de dados na empresa
Visão geral:
  • Coletando e processando dados
  • Separando a lógica de apresentação da lógica de gerenciamento de informação
  • Usando as tecnologias do Microsoft Office 2007 para criar uma solução de coleta de dados
Faça download do código deste artigo: DataGathering2008_02.exe (567KB)

As empresas coletam enormes quantidades de informação usando uma variedade e métodos. Os dados chegam por email, pesquisas, formulários da Web e outros mecanismos de coleta de dados. Dados são, geralmente, algo
bom. No entanto, gerenciar a matriz de ferramentas de coleta de dados e todas as informações distintas é difícil. A integração confiável e o compartilhamento seguro de dados são desafios constantes para as organizações de TI. Padrões e arquiteturas orientadas a serviços estão evoluindo, tornando mais fácil para os profissionais de TI tornar os dados mais acessíveis de maneira mais segura. Mas enquanto você tem as ferramentas e tecnologias necessárias para criar uma arquitetura empresarial eficiente, é muito comum ficar preso em uma rede de interfaces proprietárias—e isso leva a soluções isoladas.
Tome as tecnologias disponíveis no sistema Microsoft® Office como exemplo. É possível criar de maneira rápida uma pesquisa departamental baseada no Windows® SharePoint® Services 3.0, mas se essa é uma solução padrão vai depender da sua organização. Se a sua empresa usa ASP.NET e SharePoint como plataforma para colaboração e integração de dados baseados na Web, então essa pesquisa fornece uma solução padronizada. Mas se o seu ambiente for como aquele onde trabalho, o SharePoint é somente uma plataforma entre outras.
Certo, o SharePoint fornece muitas opções para a integração com os sistemas da IBM, HP, Siebel e assim por diante. Essa é uma boa notícia para os usuários avançados que desejam criar soluções ad hoc e ter ainda o fluxo de dados resultante em uma variedade de sistemas back-end. No entanto, se você for um arquiteto de soluções, há uma maneira ainda melhor—o InfoPath® 2007.
Com o InfoPath 2007, que é parte do sistema Office 2007, é possível separar a lógica de apresentação das suas soluções da lógico de gerenciamento de informação nos seus servidores. Com a tecnologia baseada em CML do InfoPath, é possível criar soluções de coleta de dados prontas para a empresa. Na maior parte do tempo, os designer de formulário do InfoPath não necessitam de conhecimentos detalhados sobre XML, serviços Web, arquiteturas de solução, ASP.NET ou modelo de objeto do SharePoint.
Neste artigo, discutirei sobre como é possível criar soluções de coleta de dados flexíveis usando o InfoPath 2007, Office SharePoint Server 2007 e Forms Services. E mostrarei como o XML permite a você separar a lógica de apresentação da lógica de negócios em uma arquitetura empresarial de várias camadas.
Observe que ao me referir a “coleta de dados”, me referiro ao processo de coleta de informações de origens humanas. Existem, é claro, outras maneiras de coletar dados, como o rastreamento de origens de dados, mas esses métodos automáticos estão além do escopo deste artigo.

Adquirindo e manipulando dados
Os requisitos de aquisição de dados podem ser complicados, mas esses processos têm algumas coisas em comum. Ao tratar essas semelhanças em módulos centralizados enquanto manipula requisitos exclusivos em componentes descentralizados, é possível limitar esforços redundantes, sobrecarga de manutenção e o custo total de propriedade.
Por exemplo, os regulamentos de conformidade para empresas públicas resultam em requisitos de negócios que, por sua vez, são convertidos em diretivas de gerenciamento de informação para toda a empresa. Essas diretivas afetam as soluções de coleta de dados em limites departamentais e muitas vezes levam à esforços duplicados em departamentos individuais—por exemplo, regras sobre a coleta de informações de identificação pessoal coletadas por um departamento de RH (manipulando informações de funcionários) e um departamento de serviços ao cliente (manipulando informações de clientes). Mesmo processos de negócios entre departamentos individuais semelhantes porém não relacionados fornecem oportunidades para a unificação de soluções de gerenciamento de informações.
A Figura 1 mostra um exemplo de processo de negócios típico. Um funcionário que deseja negociar uma atribuição com um colega deve primeiro obter um acordo com o colega, depois a aprovação de um gerente ou coordenador da programação de atribuições e, finalmente, do supervisor. Isso pode envolver funcionários trocando turnos de trabalho, por exemplo. Embora essas trocas ocorram em departamentos diferentes e possam recorrer a formas diferentes, os fluxos de trabalho e a lógica de gerenciamento de informação podem ser compartilhadas entre as várias soluções de departamentos.
Figura 1 Processo de coleta de dados de exemplo que pode ser compartilhado entre departamentos
Figura 1 Processo de coleta de dados de exemplo que pode ser compartilhado entre departamentos
Claro, consolidar componentes redundantes é uma tarefa árdua. Orientar alterações organizacionais em uma empresa não é fácil, mas com as tecnologias do sistema Office é possível criar uma base sólida para facilitar essas alterações. O InfoPath 2007 permite aos departamentos individuais criar aplicativos de formulários que se integram a sistemas de gerenciamento de informação centralizados e padronizados. O SharePoint 2007, enquanto isso, permite aos departamentos de TI delegar o controle administrativo sobre conjuntos de sites, sites e bibliotecas de documentos a departamentos e equipes individuais. Como resultado, as equipes podem criar e implantar as suas próprias soluções com o envolvimento mínimoo de TI, enquanto os departamentos de TI permanecem controlando todos os serviços e componentes compartilhados, como fluxos de trabalho, diretivas de gerenciamento de informação e procedimentos de backup.

Centralizando os seus esforços de coleta de dados
As empresas muitas vezes oferecem às equipes servidores de aplicativos departamentais para acomodar as necessidades de gerenciamento de informação individuais. O departamento de TI é responsável somente pela manutenção do hardware e do sistema operacional em execução, enquanto os departamentos individuais cuidam de todos os aspectos de duas soluções. Há pouca coordenação entre os departamentos, e o compartilhamento de informações é difícil.
Os desafios técnicos de centralizar os esforços de coleta de dados giram principalmente em torno da segurança, desempenho, manutenção e suporte de componentes personalizados hospedados em um ambiente compartilhado. Por exemplo, os efeitos de um componente com funcionamento incorreto são isolados se as soluções individuais forem hospedadas em servidores de aplicativos departamentais. No entanto, em um ambiente compartilhado, um componente com funcionamento incorreto pode afetar processos de negócios em uma escala muito maior. É por isso que o departamento de TI deve estabelecer diretivas rigorosas em relação à implantação e manutenção de componentes personalizados em sistemas centralizados.
A hospedagem de soluções departamentais do SharePoint em um farm de servidor central exige a implantação e manutenção de todos os componentes personalizados das soluções departamentais nos servidores de aplicativos centrais. Uma solução pode recorrer a tipos de campo personalizados para estender a interface do usuário da solução com listas suspensas populadas de serviços da Web de back-end. Outra solução seria recorrer a Web Parts com o mesmo objetivo enquanto outros usam fluxos de trabalho personalizados—todos escritos em código gerenciado e implantados como assemblies do Microsoft .NET Framework.
Mover até mesmo um número relativamente pequeno de soluções do SharePoint para um farm de servidor de aplicativo central pode levar a configurações difíceis e problemas de suporte. Se os assemblies devem ser implantados no GAC (Global Assembly Cache), a segurança se torna um problema pois esses assemblies são executados em confiança total. Componentes mal programados podem abrir o sistema a injeções SQL, scripts entre sites ou ataques de negação de serviço. É necessário certificar-se de que os componentes possam sustentar a carga de trabalho típica, bem como os picos de demanda e operações de longa duração. É necessário certificar-se de que os componentes não bloqueiem outros processos, manipulando eventos de modo síncrono, e que os componentes executem validação de entrada confiável—para que os usuários não insiram declarações ou scripts SQL em colunas usadas para atualizar o banco de dados ou sistema da Web remoto.
Em resumo, a meta é enfatizar a configuração do servidor de maneira escalar e segura baseado em recursos de produto padrão. Recorrendo a soluções reutilizáveis e totalmente testadas, é possível evitar a armadilha de criar numerosos componentes personalizados. Faz sentido manter o front-end descentralizado e o back-end, centralizado. A chave é integrar os componentes de uma maneira flexível que promova a reutilização de soluções existentes

Dividindo a lógica de negócios
Então, como criar soluções de coleta de dados flexíveis que possam ser configuradas nos nossos servidores? A melhor estratégia é separar a arquitetura de solução em camadas individuais como mostrado na Figura 2: armazenamento de dados, lógica de negócios e apresentação ou interface do usuário. Atualmente, a interface do usuário é geralmente baseada no navegador enquanto a lógica de negócios reside nos servidores de aplicativos Web. Esses, por sua vez, acessam bancos de dados e repositórios de dados não relacionais.
Figura 2 Uma solução empresarial típica criada em uma arquitetura de três camadas
Figura 2 Uma solução empresarial típica criada em uma arquitetura de três camadas
A lógica de negócios muitas vezes inclui uma lógica de transação para garantir que as transações sejam aplicadas automaticamente em sistemas de gerenciamento de banco de dados. A lógica de negócios pode também integrar vários serviços de camadas intermediárias por meio de HTTP, enfileiramento de mensagens, RPCs e assim por diante. A arquitetura de solução geral, no entanto, permanece essencialmente um modelo de três camadas.
O que a Figura 2 não ilustra é q complexidade da lógica de negócios em um ambiente empresarial. Parece que o servidor de aplicativo nessa figura está concentrado simplesmente no processamento de um formulário baseado no navegador e manipulando os dados enviados; mas essa representação não leva em consideração os requisitos de fluxo de trabalho, conformidade ou gerenciamento de informação. Para tratar esses requisitos, é necessário dividir a lógica de negócios em duas—a lógica de apresentação e a lógica de gerenciamento de informação. Isso permite a você misturar e combinar os componentes de camada intermediária conforme necessário sem a recriação de componentes do zero para cada solução.
A Figura 3 mostra essa arquitetura. No centro está o conteúdo ou dados, rodeados pela lógica de gerenciamento de informação, que governa o conteúdo por todo o seu ciclo de vida. A lógica de apresentação faz a interface com a lógica de gerenciamento de informação para fornecer acesso aos dados por meio da interface do usuário.
Figura 3 Separando a lógica de apresentação da lógica de gerenciamento de informação
Figura 3 Separando a lógica de apresentação da lógica de gerenciamento de informação

Coletando e processando XML
Em ambientes de aplicativos orientados a serviços (SOA), o XML é o padrão dominante usado para definir e compartilhar dados e estruturas de dados entre componentes. E o XML é, portanto, uma boa escolha para fazer a interface entre componentes de apresentação e gerenciamento de informação.
A comunicação deve se mover em duas direções: será necessário converter o XML em um documento inteligível para o navegador, bem como um documento CML gerado pelo formulário. Até recentemente, criar aplicativos de formulário baseados em XML exigia habilidades de programação extensas. Isso era especialmente verdadeiro quando os dados XML resultantes tinham que aderir a um esquema da indústria para facilitar a troca de informações interorganizacionais.
O InfoPath 2007 torna o desenvolvimento de formulários baseados em XML muito mais fácil. Um bom entendimento dos detalhes do XML é certamente útil, mas os designers de formulários e usuários avançados não precisam ser magos do XML para criar aplicativos de formulários baseados em XML. O designer de formulários simplesmente importa um documento ou esquema XML para o InfoPath e mapeia o atributo individual e nós de elemento daquela origem de dados para os campos no formulário. Um designer de formulários pode também começar com um serviço da Web, banco de dados do SQL Server® ou de um modelo em branco e criar um formulário do zero enquanto o InfoPath cria automaticamente o esquema subjacente e as ligações de dados no segundo plano.
A padronização de formulários usando o InfoPath e esquemas XML tem várias vantagens. Se você já tem um esquema XML bem definido, os designers de formulários e desenvolvedores de fluxo de trabalho e componentes de gerenciamento de informação podem criar soluções para as mesmas estruturas de dados. Se um designer de formulários começa do zero, os desenvolvedores devem esperar até que o formulário seja concluído para ver como ele afeta as estruturas de dados subjacentes. E quando as estruturas de dados forem definidas, soluções futuras, como novos modelos de formulários, podem reutilizar fluxos de trabalho existentes e componentes de gerenciamento de informação se recorrerem às mesmas estruturas de dados. Os componentes de fluxo de trabalho e gerenciamento de informação futuros poderão trabalhar juntamente com formulários e dados existentes. Se você criar soluções de coleta de dados baseadas em esquemas estabelecidos do setor, os resultados se tornam ainda mais flexíveis. Na verdade, essas soluções serão compatíveis com soluções criadas por outras empresas que usam os mesmos esquemas.
Eu criei um esquema DirectReports simples que associa os funcionários aos gerentes. Os gerentes podem usar o formulário resultante para avaliar seus relatórios diretos. É possível encontrar o esquema, o formulário e um arquivo readme.htm com instruções para recriar o formulário na pasta Direct Reports no download que acompanha este artigo, disponível em technetmagazine.com/code08.aspx. O formulário é básico, mas ilustra o conceito geral.
Este é um ponto muito importante: eu não criei nenhuma lógica de validação no InfoPath, mas o InfoPath ainda exige que sejam inseridos os ID de usuário e endereços de email em um formato específico (domínio\conta e destinatário@domínio.tld). Caso contrário, o documento XML resultante não será válido. Isso ocorre porque o esquema XML define esses formatos. É possível salvar o formulário com dados inválidos mas você não poderá enviá-lo, como mostra a Figura 4. (Eu adicionei uma regra de envio fictícia para o formulário para que você possa testar isso sem realmente enviar dados para local nenhum). A validação do InfoPath 2007 garante automaticamente que o formulário esteja preenchido totalmente e sem esse tipo de erro.
Figura 4a Validação de erros evitam que o usuário envie um formulário
Figura 4a Validação de erros evitam que o usuário envie um formulário
Figura 4b A mensagem de erro gerada
Figura 4b A mensagem de erro gerada
O esquema XML funciona como o contrato de ligação entre a lógica de apresentação e a lógica de gerenciamento de informação. O InfoPath bloqueia o esquema para que os designers de formulários não possam alterar intencionalmente as estruturas de dados. Isso é importante pois alterar um esquema XML estabelecido pode potencialmente quebrar as soluções empresariais existentes, como módulos de fluxo de trabalho que você tenha a intenção de usar em combinação com o novo modelo de formulários.
O InfoPath fornece uma abundância de recursos para a criação de lógicas de apresentação avançadas em aplicativos de formulários. É possível consumir dados de arquivos XML, serviços da Web, bibliotecas e listas do SharePoint, bancos de dados e assim por diante para obter valores padrão significativos. É possível alterar valores de campo baseados na seleção do usuário por meio de regras, incluindo lógica de validação, adição de código gerenciado para os requisitos de personalização mais avançados e o uso do Forms Service para tornar o modelo de formulário acessível na Web. De qualquer modo, os dados do formulário eventualmente atingem a lógica de gerenciamento de informação como um documento XML compatível com uma definição de esquema.

Trabalhando com XML ou metadados
Você pode imaginar se deve aplicar a lógica de gerenciamento de informação diretamente ao documento XML enviado ou, em vez disso, usar um analisador que extraia as informações necessárias em metadados. O SharePoint oferece suporte às duas abordagens. Os desenvolvedores estão acostumados a trabalhar diretamente com documentos XML, mas os metadados oferecem mais flexibilidade.
Para demonstrar isso, criei um serviço da Web simples que analisa um documento XML passado do formulário Direct Reports mostrado na Figura 4. (O código-fonte, arquivos de configuração e um arquivo readme.htm com instruções passo a passo podem ser encontrados na pasta XMLParsingWebService no download de acompanhamento). O serviço da Web simplesmente lê o ID de usuário do gerente a partir do documento XML, divide o ID do usuário em partes de domínio e nome de usuário, cria uma mensagem baseada nessas partes e gera uma exceção genérica para retornar e exibir a informação processada na forma de uma mensagem de pseudo-erro no formulário do InfoPath. Essa é uma forma fácil de gerar uma caixa de diálogo popup no InfoPath depois que os dados forem enviados. O serviço da Web funciona bem, mas se você alterar a origem de dados subjacente (por exemplo, se você renomear o elemento OrgPerson para Manager no DirectReports.xsd e atualizar o formulário do InfoPath com o novo esquema conforme descrito no arquivo readme.htm) o serviço da Web falha. Mas isso não deve ser uma surpresa. O documento XML é agora diferente e a antiga expressão XPath para acessar o elemento user-id é inválida. Os esquemas OrgPerson e Manager são quase idênticos, os formulários do InfoPath são idênticos, e os resultados de processamento desejados são os mesmos, mas apesar das diferenças serem mínimas, ainda é necessária implantar e manter serviços da Web duplicados.
Essa não é uma boa abordagem se você deseja minimizar a superfície de código personalizado nos seus servidores de aplicativos. Em contraste, mapear os nós XML para campos de metadados e executar o processamento baseado nos metadados permite o uso dos mesmos fluxos de trabalho e lógica de gerenciamento de informação para estruturas de dados semelhantes mesmo que os esquemas XML sejam diferentes. É necessário somente certificar-se de que os elementos filhos sejam mapeados para o campo de metadados correto e que o formato de dados atenda às exigências de processamento—então você poderá reutilizar o código existente.
Mapear nós XML para campos de metadados é semelhante a ligar nós XML a controles de interface do usuário em um formulário do InfoPath, como mostrado na Figura 5. No SharePoint, campos de metadados correspondem a colunas definidas no nível do site ou lista e são referenciados nas definições de tipo de conteúdo. Tipos de conteúdo definem as características de itens de conteúdo, como campos de metadados, fluxos de trabalho e formulários. Para manter os campos de metadados de um tipo de conteúdo sincronizados com os nós correspondentes nos documentos XML associados, o SharePoint recorre a um analisador XML interno que executa promoções e rebaixamentos de propriedade. Durante a promoção de propriedades, o analisador XML extrai valores de nó de um documento XML para colunas correspondentes na biblioteca de documentos. O rebaixamento de propriedade se refere ao processo reverso no qual valores de coluna são retirados da biblioteca de documentos e gravados novamente no documento. O ponto mais importante é que o analisador XML mantém sincronizados os campos de metadados e nós XML mapeados.
Figura 5 Mapeamentos de esquema XML entre o InfoPath e o SharePoint
Figura 5 Mapeamentos de esquema XML entre o InfoPath e o SharePoint
Ao usar o modelo de objeto do SharePoint, suas Web Parts, fluxos de trabalho e lógica de gerenciamento de informação podem funcionar com campos de metadados bem como os documentos XML subjacentes. Alterar o valor de um campo de metadados mapeado altera o valor do nó no documento XML e vice-versa. Ainda assim, trabalhar diretamente com o documento XML liga rigidamente a lógica de negócios com o esquema XML. Os campos de metadados mapeados, por outro lado, aumentam a capacidade de reutilização do código. Obviamente, é necessário decidir qual abordagem é a melhor para o seu ambiente, mas em sua maior parte as soluções do SharePoint que recorrem a campos de metadados fornecem maior flexibilidade e mais oportunidades para reutilização do código.
Para ilustrar como o SharePoint associa os nós XML com campos de metadados, incluí um recurso do SharePoint no material de acompanhamento para provisionar uma biblioteca de documentos personalizada (consulte o arquivo OrgPersonContentType.xml localizado na pasta OrgPersonLib no download de acompanhamento). O tipo de conteúdo OrgPerson faz referência a quatro campos: UserID, FullName, EMail e Direct_x0020_Reports. FullName e EMail são campos internos. UserID r Direct_x0020_Reports são campos personalizados definidos em OrgPersonSiteColumns.xml.
As definições de campo são bem simples. É possível ligar campos a nós XML diretamente nas definições de campo e é possível também substituir essa informação nos tipos de conteúdo. Decidi usar a segunda técnica porque ela me permite usar os campos personalizados em tipos de conteúdo não relacionados a documentos XML bem como em tipos de conteúdo que recorrem a diferentes estruturas XML. O tipo de conteúdo OrgPerson liga os campos de metadados aos nós XML que correspondem à sua disposição no esquema OrgPerson discutido anteriormente. Há também um arquivo AdditionalContentTypes.xml que define mais tipos de conteúdo que ligam os mesmos campos de metadados a diferentes nós XML. É possível observar as diferenças se você examinar as expressões XPath nos atributos Node.
As bibliotecas de documentos do tipo OrgPersonLib podem armazenar tipos diferentes de documentos XML enquanto os valores de nó são expostos por meio das mesmas colunas de bibliotecas. Essa técnica de mapeamento simples permite também a reutilização de fluxos de trabalho e lógica de gerenciamento de informação já que os quatro tipos de conteúdo (OrgPerson, Manager, Supervisor e User) fazem referência a um conjunto comum de campos de metadados.
A Figura 6 mostra o elemento FieldRef do tipo de conteúdo OrgPerson de Direct_x0020_Reports, que mapeia o campo para os nós user-id de relatórios diretos de acordo com a expressão XPath /OrgPerson/direct-report/user-id. Como o documento XML pode incluir várias entradas de relatório direto, é importante especificar um atributo Aggregation. Isso define como o analisador XML manipulará a coleção de valores retornada. Se este atributo for omitido, o analisador XML extrai somente o primeiro valor de nó. Os valores de agregação com suporte são sum, count, average, min, max, merge, plain text, first e last.
Figura 6 Campo de metadados mapeado para uma expressão XPath
Figura 6 Campo de metadados mapeado para uma expressão XPath
Todos os tipos de conteúdo de exemplo usam a página upload.aspx padrão como DocumentTemplate para que seja possível carregar arquivos XML na biblioteca de documentos ao clicar no botão New na interface de usuário do SharePoint. Desde que você carregue arquivos com uma extensão de nome de arquivo .xml, o SharePoint invocará automaticamente o analisador XML interno (com exceção dos arquivos WordProcessingML, para os quais o SharePoint invoca um analisador WordProcessingML). O analisador XML examina o arquivo .xml carregado para determinar o tipo de conteúdo associado. É assim que ele extrai os valores de nó dos locais especificados nas definições de campo e executa a promoção de propriedade. (É possível verificar esse processo ao carregar o arquivo OrgPerson.xml incluído na pasta OrgPersonLib\XMLFiles). A estrutura desse documento XML corresponde às expressões XPath especificados na definição de tipo de conteúdo OrgPerson. Da mesma forma, o SharePoint extrai os dados do arquivo .xml, grava os dados nas colunas de biblioteca correspondentes e exibe os dados na página EditForm.aspx para que seja possível verificar e atualizar as propriedades do documento que não estão marcadas como somente leitura. A Figura 7 mostra o formulário EditForm.aspx com os dados extraídos de OrgPerson.xml.
Figura 7 Formulário EditForm.aspx com dados extraídos
Figura 7 Formulário EditForm.aspx com dados extraídos
Se você alterar os valores User ID, Full Name ou E-Mail no EditForm.aspx, o SharePoint executa o rebaixamento de propriedade para alterar os valores de nó no documento XML subjacente. Observe, no entanto, que o SharePoint não impõe restrições de Esquema XML a menos que você implemente a lógica necessária no formulário por conta própria.
O SharePoint também não executa a lógica de apresentação de um aplicativo de formulários. Por exemplo, ao alterar o User ID, o SharePoint não valida se o novo valor está de acordo com as convenções NetBIOS e não atualiza automaticamente os campos Full Name e E-Mail para corresponder à nova seleção. Portanto, você deve marcar a coluna correspondente na definição de tipo de conteúdo como somente leitura se a alteração de um campo individual causar inconsistências. Isso força o usuário a usar o aplicativo de formulários, como o InfoPath, para atualizar os dados. E o analisador XML promoverá qualquer alteração do documento XML para os campos de metadados correspondentes no SharePoint.
No exemplo OrgPersonLib, é possível carregar qualquer um dos arquivos .xml da pasta OrgPersonLib\XMLFiles. Os arquivos .xml files usam estruturas de dados muito diferentes, mas o SharePoint reconhece os tipos de conteúdo e promovem os valores de nó corretos nas colunas de site. Isso ocorre porque usei uma instrução de processamento nos arquivos XML para associar os documentos XML com seus tipos de conteúdo correspondentes. O arquivo OrgPerson.xml, no entanto, não inclui essa informação, mas isso não é um problema. Se o SharePoint não consegue associar um documento XML a um tipo de conteúdo por meio de uma instrução de processamento ou modelo de documento, ele usa o tipo de conteúdo padrão. No caso do OrgPersonLib, este é o tipo de conteúdo OrgPerson e, portanto, o documento XML é analisado corretamente.
A Figura 8 mostra como associar um documento XML explicitamente a um tipo de conteúdo. A instrução de processamento MicrosoftWindowsSharePointServices define o ContentTypeID como 0x010100668E393E4F0EFF4294DBD202D5D8321D. Isto é o ID do tipo de conteúdo User, conforme definido em AdditionalContentTypes.xml.
Figura 8 Instruções de processamento e dados XML do arquivo de exemplo User.xml
Figura 8 Instruções de processamento e dados XML do arquivo de exemplo User.xml
O analisador XML processa a instrução de processamento MicrosoftWindowsSharePointServices e grava o valor do ContentTypeID no campo de metadados ContentType. Todos os tipos de conteúdo do SharePoint compartilham esse campo de metadados, pois ele é definido no nível raiz do tipo de conteúdo System. Se você abrir o arquivo fieldswss.xml em um servidor do SharePoint (localizado na pasta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields) e pesquisar por MicrosoftWindowsSharePointServices, é possível observar como o SharePoint associa as instruções de processamento com o campo ContentType. O atributo PITarget aponta para o MicrosoftWindowsSharePointServices (essa é a instrução de processamento) e o atributo PIAttribute aponta para o ContentTypeID (que contém o ID do tipo de conteúdo User).

Associações de tipo de conteúdo no InfoPath
Os aspectos técnicos da análise XML e das associações de tipo de conteúdo são intimidadoras para muitos designers de formulários, mas o InfoPath 2007 cuida de todos os detalhes essenciais. O arquivo readme.htm que acompanha o exemplo OrgPersonLib inclui instruções para a publicação do modelo de formulário Direct Reports no SharePoint e cria um tipo de conteúdo que se liga novamente aos mesmos campos de metadados (UserID, FullName, EMail e Direct_x0020_Reports). É possível adicionar facilmente o novo tipo de conteúdo à biblioteca de documentos OrgPersonLib na interface do usuário do SharePoint. Mas o novo tipo de conteúdo também aponta para o modelo de formulário do InfoPath já que o modelo de documento invoca o aplicativo de formulários ao atualizar os documentos XML existentes. A Figure 9 listra como o Assistente de Publicação do InfoPath simplifica o mapeamento de propriedades entre valores de nó XML e colunas de site do SharePoint. E, novamente, se você associar os valores de nó com as colunas de site existentes, é possível reutilizar os componentes do SharePoint existentes.
Figura 9 Mapeamento de propriedades no InfoPath 2007
Figura 9 Mapeamento de propriedades no InfoPath 2007

Conclusão
Recursos on-line adicionais
  • Blog da equipe do InfoPath 2007
  • Especificações e Desenvolvimento do Esquema XML do W3C
  • Introdução aos Esquemas XML
  • Fluxos de trabalho no Office SharePoint Server 2007
  • InfoPath 2007 Forms Services

Com as tecnologias disponíveis no Office, os arquitetos empresariais podem criar soluções de coleta de dados que promovem prontamente a reutilização de código e a troca de informações. O InfoPath 2007 permite aos departamentos a criação de soluções que obtém informações de várias fontes e os dados podem então ser enviados a vários sistemas, como o SharePoint. O SharePoint também fornece aos desenvolvedores um conjunto abrangente de serviços da Web e interfaces para criar componentes de fluxos de trabalho e gerenciamento de informações. Ao hospedar esses componentes em servidores do SharePoint centralizados, os departamentos têm a infra-estrutura necessária para criar seus aplicativos individuais.
Enquanto isso, os departamentos individuais podem criar as suas soluções de coleta de dados de maneira mais rápida. Os regulamentos de conformidade e outros requisitos de negócios globais podem ser tratados em um nível entre departamentos e a facilidade de manutenção e confiabilidade do ambiente de TI aumentam com o uso de menos componentes personalizados ou servidores de aplicativo.

Keith Deshaies é redator técnico freelancer e analista de TI para uma grande empresa de telecomunicações. Ele é especialista em tecnologias do Microsoft Office e SharePoint e membro da STC (Sociedade de comunicação técnica).
© 2007 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..


 SharePoint: Cria&#231;&#227;o de uma infra-estrutura de pesquisa avan&#231;ada
SharePoint Jim Bradley

Criação de uma infra-estrutura de pesquisa avançada
Visão geral:
  • Planejamento e implementação de uma solução de pesquisa
  • Coleta e processamento de resultados de pesquisa em bibliotecas do SharePoint
  • Gerenciamento de problemas de desempenho e segurança

Você não pode tomar boas decisões sem informações. Desconfianças não são suficientes – não quando suas decisões irão ter um impacto nos seus negócios. Isso é verdadeiro quer você esteja decidindo onde realizar uma festa
da equipe ou se estiver considerando a realocação de 50% dos recursos de sua empresa para o lançamento de um novo produto. Mas como você pode conseguir essa informação?
As pesquisas fornecem um método eficaz – e econômico – de obter comentários sobre tudo, desde o quanto os clientes estão satisfeitos com suas ofertas de produtos a se os funcionários gostaram ou não dos sanduíches oferecidos na última reunião da equipe. As pesquisas produzem a substância necessária para futuros aprimoramentos e desenvolvimento de produtos, sistemas ou processos. A pergunta é, como você, o profissional de TI, implementará um sistema de pesquisa que possa coletar dados e armazená-los de modo que as informações possam ser usadas de formas significativas?
Você provavelmente já tem uma ou mais das ferramentas necessárias para coletar, estruturar e analisar esse tipo de dados. O 2007 Microsoft® Office system fornece essas ferramentas e facilita seu uso. Na realidade, há várias formas para se realizar uma pesquisa. O segredo é selecionar a abordagem compatível com as suas necessidades específicas. Por exemplo, pesquisas com base em emails são uma boa escolha para coleta de dados improvisada em tempo real ao lidar com um pequeno número de pesquisados e dados não críticos. Para obter mais informações, consulte a barra lateral a seguir "Uso de email para pesquisas rápidas". Por outro lado, as pesquisas orientadas por bancos de dados são uma melhor escolha para iniciativas mais complexas que incluem um grupo maior de pesquisados relativos a dados considerados essenciais. Para obter mais informações sobre esse tópico, consulte a barra lateral a seguir "Criação de uma solução de pesquisa orientada por bancos de dados”.
Neste artigo, o foco será outra solução mais abrangente e flexível. As pesquisas online baseadas no SharePoint®. Essa abordagem é adequada para pesquisas essenciais e não essenciais de qualquer nível de complexidade. Como as pesquisas do SharePoint são baseadas na Web, elas podem ser concluídas por qualquer pessoa que acessar um navegador da Web – até mesmo dispositivos móveis são compatíveis. Com uma pesquisa do SharePoint, as respostas podem ser nomeadas ou anônimas, resultados em tempo real estão disponíveis e você tem acesso até mesmo a ferramentas de análise.
Esse tipo de pesquisa é implementado usando o Windows® SharePoint Services 3.0 (WSS) com Forms Server e o InfoPath® ou Microsoft Office SharePoint Server 2007 (MOSS) com Forms Services e o InfoPath® (consulte a Figura 1 para obter uma descrição de cada uma dessas tecnologias). Como esses cenários oferecem essencialmente a mesma funcionalidade, nesta discussão me concentrarei nesta última combinação. Para obter uma comparação abrangente dos produtos do SharePoint e sua funcionalidade, consulte o Microsoft Office SharePoint Server 2007 Products Comparison Download em office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx.
Figure 1 Tecnologias Microsoft que habilitam pesquisas do SharePoint (Close Figure 1)

Tecnologia | Descrição
Microsoft Office InfoPath 2007 | O Microsoft Office InfoPath 2007 é uma ferramenta de criação de formulários e coleta de informações. Para obter mais informações, consulte office.microsoft.com/infopath.
Windows SharePoint Services 3.0 | Anteriormente denominado SharePoint Team Services, o Windows SharePoint Services 3.0 atua como a base para a criação de aplicativos do SharePoint estendidos. Para obter mais informações, consulte microsoft.com/technet/windowsserver/sharepoint/techinfo/overview.mspx.
Microsoft Office SharePoint Server 2007 | O Microsoft Office SharePoint Server 2007 (anteriormente denominado SharePoint Portal Server 2003) fornece uma infra-estrutura por parte do servidor que torna clientes Office 2007 em geradores e consumidores de conteúdo de aplicativos do SharePoint. Para obter mais informações, consulte microsoft.com/sharepoint.
InfoPath Forms Services, Microsoft Office Forms Server 2007 | O InfoPath Forms Services permite que os usuários preencham formulários do InfoPath em um navegador Web, sem precisar ter o InfoPath instalado, tornando as pesquisas compatíveis com várias plataformas e navegadores. O Forms Services requer o Windows SharePoint Services 3.0, embora a mesma funcionalidade também esteja disponível como um produto independente denominado Microsoft Office Forms Server 2007. Para obter mais informações sobre o Forms Services, consulte microsoft.com/ms540731. Para obter mais informações sobre o Forms Server, consulte office.microsoft.com/en-us/formsserver/FX100490391033.aspx.

Planejamento e implementação
Ao criar uma pesquisa, você precisa considerar vários fatores com antecedência. Isso requer certa análise anterior; portanto, reserve um período para desenvolver um plano de pesquisa bem elaborado. No estágio inicial do planejamento, você definirá o problema e o tipo de dados que deseja obter, determinará as tecnologias que precisará usar e estabelecerá os requisitos orçamentários e administrativos. Em seguida, você poderá prosseguir com a implementação. O fluxo de trabalho geral é criar um formulário de pesquisa, publicá-lo, coletar e validar respostas, agregar e analisar os dados e, em seguida, relatar os resultados.
Um fluxo de trabalho de implementação de pesquisa geralmente inclui pelo menos um designer de pesquisa, pesquisados e um analista (como mostra a Figura 2). É claro, os fluxos de trabalho de pesquisa podem variar muito em complexidade. Uma pesquisa abrangendo toda a empresa, por exemplo, provavelmente teria várias edições e aprovações de design. Ela provavelmente utilizaria lembretes automatizados para os pesquisados, ofereceria várias formas de suporte e solução de problemas, forneceria exibições em tempo real nos resultados para os gerentes e teria um processo claro para determinar e fornecer a análise final. Um fluxo de trabalho complexo desse tipo realmente exigiria um sistema baseado na Web que oferecesse suporte a recursos de fluxo de trabalho e relatórios.
Figura 2 Um fluxo de trabalho de pesquisa desde a criação de formulários até a análise de dados
Figura 2 Um fluxo de trabalho de pesquisa desde a criação de formulários até a análise de dados

O que procurar em uma solução abrangente
Há uma longa lista de requisitos importantes que você deve esperar que uma solução de pesquisa abrangente atenda. A solução deve permitir que equipes individuais ou unidades de negócio criem, distribuam e coletem resultados de pesquisa com o mínimo envolvimento do departamento de TI – e isso não deve exigir habilidades de programação. A ferramenta de criação de formulários deve oferecer uma interface WYSIWYG fácil de usar, bem como um conjunto avançado de recursos que facilite a canalização, a ramificação e a lógica condicional. E, não é preciso dizer, a ferramenta de criação de formulários de pesquisa deve acomodar todas as pesquisas, independentemente do tamanho e da complexidade.
Além disso, a pesquisa deve ser executada em um servidor Web e integrada com um banco de dados SQL Server® mantido centralmente, eliminando a necessidade de departamentos individuais para manter bancos de dados SQL dedicados. Qualquer pesquisado com acesso à Internet poderá responder à pesquisa de qualquer navegador em conformidade com os padrões.
O processo de pesquisa deve ser facilmente vinculado a fluxos de trabalho e deve atender a necessidades comerciais sem comprometer a segurança. E, para muitas organizações, a solução de pesquisa deve fornecer suporte a vários idiomas.
Quando utilizados juntos, o MOSS 2007, o WSS 3.0 e o InfoPath 2007 criam uma solução integrada que soluciona todos esses requisitos. A Figura 3 mostra como os vários componentes se encaixam na pilha do SharePoint. Mas antes de me aprofundar nessa solução de pesquisa completa, quero apresentar rapidamente o que você pode atingir apenas com o WSS. Em seguida, mostrarei a você as vantagens agregadas que você terá ao adicionar o MOSS e o InfoPath a essa combinação.
Figura 3 Componentes da pilha do SharePoint
Figura 3 Componentes da pilha do SharePoint

Como trabalhar somente com o WSS
Mesmo sem os outros componentes, você pode usar o WSS para criar e implementar uma pesquisa. Na realidade, o WSS inclui um modelo de pesquisa interno que facilita o processo. Para criar uma pesquisa, clique em Iniciar | Todos os programas | Ferramentas administrativas e selecione Administração Central do SharePoint 3.0. A partir da lista suspensa, selecione Ações de Site e, em seguida, clique em Criar. A página Criar será exibida, mostrando a você os cabeçalhos para Bibliotecas, Comunicações, Controle, Listas personalizadas e Páginas da Web. Em cada cabeçalho, há opções de modelo. Em Controle, clique em Pesquisa.
Nesse momento, o WSS o conduzirá por todas as etapas do processo de criação de pesquisa. Você pode criar perguntas abertas ou fechadas e especificar se uma pergunta pode ficar sem resposta. Você também pode criar pesquisas lógicas de ramificação, que conduzirão os pesquisados a diferentes caminhos, dependendo das suas respostas. As pesquisas podem ser anônimas ou, se necessário, identificar o pesquisado. Você também tem a opção de atribuir um fluxo de trabalho à pesquisa.
A pesquisa é baseada no navegador; portanto, nenhum software especial é necessário para criar ou responder a pesquisa. Para responder a pesquisa, os pesquisados simplesmente acessam o site do SharePoint e preenchem o formulário. As permissões de acesso são herdadas do site pai mas pode ser editadas diretamente a partir do menu de Ações do SharePoint. As respostas da pesquisa são salvas no site de pesquisa do SharePoint e os resultados podem ser visualizados no formulário da lista ou em resumos gráficos ou exportados para o Excel®.
Para reiterar, essa solução (com o processo mostrado na Figura 4) pode ser atingida com o WSS e sem software adicional. Supondo que você já tenha um site bem elaborado do SharePoint, um departamento individual deverá criar e implementar uma pesquisa com pouca ou nenhuma assistência de TI.
Figura 4 Uma pesquisa baseada no Windows SharePoint Services
Figura 4 Uma pesquisa baseada no Windows SharePoint Services
Uma limitação do processo apenas do WSS se torna aparente quando uma pesquisa requer personalização. O WSS cria listas de pesquisa usando várias páginas ASPX padrão (AllItems.aspx, DispForm.aspx, EditForm.aspx, NewForm.aspx, overview.aspx e summary.aspx). Embora a personalização de página além dos parâmetros inerentes no WSS seja possível, a maioria dos recursos são originados de Web Parts que não são prontamente personalizáveis. Além disso, a solução apenas do WSS é mais bem adequada para pesquisas que não precisam integrar fontes de dados externos, como o sistema ERP da sua empresa.
Quando você precisar expandir a solução de pesquisa para incluir uma IU personalizada ou integrá-la com fontes de dados adicionais, deverá considerar seriamente uma solução que combine o MOSS, o WSS e o InfoPath.

A solução de pesquisa completa
O MOSS inclui muitos recursos que estendem o WSS, mas por agora vou me concentrar em apenas um componente – o InfoPath Forms Services. Com o InfoPath Forms Services, somente o designer de pesquisa precisa do InfoPath instalado no computador. Outros podem acessar a pesquisa por meio de um navegador da Web.
No InfoPath, o designer seleciona a opção que permite que o formulário seja preenchido com o uso de um navegador. O InfoPath então cria um formulário que pode ser visualizado em qualquer navegador Web em conformidade com os padrões. Esse formulário baseado na Web funciona da mesma forma que o formulário do InfoPath, com a exceção de alguns recursos avançados do InfoPath (como funções de usuário, texto vertical, ações da caixa de diálogo e controles avançados). O formulário é então publicado em uma biblioteca ou lista do SharePoint. Enquanto isso, outro recurso do InfoPath, denominado Verificador de Design, garante que o formulário de pesquisa seja compatível com o InfoPath Forms Services.
Não há diferença entre a biblioteca de formulários do InfoPath e uma biblioteca de formulários habilitada por navegador. Em cada caso, um modelo de formulário é um arquivo .xsn. O InfoPath Forms Services exibe o formulário em um navegador ou o arquivo é baixado para o cliente e exibido diretamente no InfoPath. Se um designer de pesquisa tiver pelo menos permissões de Colaborador para um site do SharePoint, poderá usar as bibliotecas de documento do SharePoint para publicar modelos de formulário.
Um pesquisado com um navegador em conformidade com os padrões poderá preencher a pesquisa do InfoPath Forms Services e as respostas serão então perfeitamente retornadas ao servidor do SharePoint. No SharePoint, os dados podem ser armazenados, analisados, compartilhados e analisados com segurança (usando o Excel, o SQL ou outras ferramentas disponíveis na rede). Tudo isso pode ser realizado com a mínima assistência de administração de TI.

Problemas de desempenho e postbacks
No entanto, há possíveis problemas de desempenho. Por exemplo, os formulários habilitados por navegador são executados no contexto de uma conta do sistema do servidor SharePoint, que significa que, se um formulário incluir conexões de dados ou código (como mostra a Figura 5), as conexões de dados ou código serão executados no servidor, não no cliente. Além disso, os formulários podem exigir com freqüência postbacks de dados no servidor, o que aumenta a carga de trabalho no servidor.
Figura 5 A solução de pesquisa baseada no InfoPath Forms Services com conexões de dados adicionais
Figura 5 A solução de pesquisa baseada no InfoPath Forms Services com conexões de dados adicionais
Quanto mais postback uma pesquisa usar, maior será a carga nos servidores Web de front-end. No entanto, haverá momentos em que o postback será inevitável, como ao implementar a ramificação de resposta. Para minimizar possíveis efeitos adversos no sistema, os designers de pesquisa devem estar cientes dos problemas de postback e compreender qual a melhor forma de implementar pesquisas quando não for possível evitar postback. Por exemplo, os designers devem usar pesquisas do tipo assistentes que façam o postback de dados para o servidor quando o usuário clicar no botão Próximo. Isso ajuda a reduzir o número de postbacks.
O InfoPath Forms Services deve manter o estado de cada formulário atualmente ativo no servidor. O tempo limite de sessão padrão é de 60 minutos, o que significa que se uma pesquisa complexa demorar mais de 60 minutos para ser preenchida e não houver postbacks durante esse período, a sessão será encerrada no servidor. Os dados que forem inseridos mas não enviados serão perdidos e o pesquisado deverá iniciar novamente.
Tais problemas são ampliados quando um número maior de pesquisados estiver trabalhando simultaneamente em um formulário de pesquisa e quando as pesquisas tiverem fontes de dados maiores ou incluírem anexos de arquivo. Para obter mais informações, consulte "Aprimorando o desempenho do InfoPath 2007 Forms" em msdn2.microsoft.com/bb380251.

Considerações sobre segurança
Embora uma discussão mais profunda sobre segurança esteja além do escopo deste artigo, é importante destacar algumas considerações sobre a segurança. Para iniciantes, o SharePoint e o InfoPath 2007 aderem à Iniciativa de computação confiável que a Microsoft adotou no início de 2002. Os formulários do InfoPath têm três níveis de segurança possíveis: restrito, de domínio e confiança total. E, por padrão, o InfoPath determina e aplica automaticamente um nível de segurança recomendado para o formulário.
A funcionalidade de assinatura digital pode ajudar a assegurar que um formulário seja criado ou preenchido por um usuário específico e não seja alterado. Além disso, o IRM (Information Rights Management, Gerenciamento de Direitos de Informação) pode restringir o acesso a modelos e formulários preenchidos. Para impedir que usuários maliciosos carreguem formulários que têm código nocivo ou usem a plataforma SharePoint para iniciar ataques contra outros sistemas por meio de conexões de dados, o InfoPath diferencia entre formulários implantados pelo usuário e pelo administrador. Os usuários podem carregar formulários, desde que os formulários não tenham qualquer código personalizado e possam usar somente o nível de segurança de domínio, o que limita as conexões de dados entre os domínios. Esses parâmetros são suficientes para a maioria das soluções de pesquisa.
Quando um design de pesquisa exigir o nível de segurança Confiança total, a fim de permitir o acesso irrestrito aos recursos, a publicação de formulário exigirá a aprovação da administração de TI. Por padrão, a aprovação da administração de TI é necessária quando um formulário tiver código gerenciado, quando conexões de dados entre domínios forem definidas no modelo de formulário, quando o formulário utilizar conexões de dados definidas na biblioteca de conexão de dados gerenciada centralmente e quando a opção de oferecer suporte a processamento em dispositivos móveis estiver habilitada.
Para o nível de segurança Confiança total, o designer de pesquisa criará um formulário do InfoPath e salvará um modelo de formulário. O modelo ou o arquivo .xsn será enviado para o administrador do SharePoint como um anexo de email ou será enviado por meio de um compartilhamento de rede. O administrador de TI então verifica os recursos de pesquisa e qualquer código que ela tenha antes de disponibilizá-la no sistema de produção. O administrador de TI concluirá a implantação ao carregar o modelo de pesquisa em um conjunto de sites e ativá-lo. Ambos os procedimentos são concluídos na página Gerenciamento de Aplicativos do console de Administração Central do WSS. O resultado final é que um administrador de TI pode delegar a publicação de formulários a departamentos individuais e ainda manter a supervisão do processo de publicação se os formulários ultrapassarem as atividades básicas de coleta de dados.
A supervisão do administrador de TI é necessária em determinados cenários comuns: quando os formulários precisarem ser preenchidos com dados padrão e quando os resultados de pesquisa forem enviados a várias fontes de dados. Por padrão, os modelos de formulário de confiança por domínio não podem estabelecer conexões de dados entre os domínios, mas há algumas ações que você pode tomar para resolver essa limitação, incluindo:
  • Concessão de permissões de confiança total ao formulário
  • Criação de confiança por domínio usando conexões de dados a partir da biblioteca de conexão de dados.
  • Uso da confiança por domínio com a biblioteca de conexão gerenciada centralmente.
As opções de Confiança total e biblioteca de conexão gerenciada centralmente exigem a aprovação do administrador durante a publicação de formulários. No entanto, a DCL (data connection library, biblioteca de conexão de dados), permite que os formulários publicados pelo usuário ultrapassem os limites do domínio usando a DCL mantida no nível de conjunto de sites. Essa DCL pode estar sob o controle de um departamento específico. No entanto, é importante compreender que permitir que departamentos específicos definam suas próprias conexões de dados com base em servidor pode ser um problema de segurança.
A opção mais segura é definir as conexões de dados na biblioteca de conexão gerenciada centralmente e, em seguida, o administrador de TI deverá implantar formulários avançados de pesquisa que utilizem essas conexões de dados. A biblioteca de conexão gerenciada centralmente é vantajosa, pois está disponível em todos os conjuntos de sites e em todo o farm de servidor. Isso permite que um administrador defina configurações de autenticação central para acesso a fontes de dados que não estejam no servidor local do SharePoint. Para obter mais informações, leia o artigo online intitulado "Sobre conexões de dados, autenticação e mapeamento de acesso alternativo" em msdn2.microsoft.com/ms771995.

Conclusão
As pesquisas fornecem um modo excelente de coletar informações consideradas críticas (e nem tão críticas) para cada empresa, em todos os níveis. No entanto, a criação de uma pesquisa eficaz requer as ferramentas corretas, um plano sonoro e uma combinação equilibrada de arte e ciência. Um planejamento elaborado com antecedência ajudará você a criar uma solução que permite que cada departamento na sua organização crie, envie, receba, armazene e analise dados de pesquisa.
As pesquisas mais eficazes são aquelas que fornecem informações relevantes e em tempo hábil. Para coletar informações quando for necessário, a sua solução deve facilitar a criação e o gerenciamento de pesquisas no nível de departamento – sem comprometer a segurança. O InfoPath capacita os operadores de informações a criarem pesquisas de qualidade superior ao fornecer uma interface intuitiva que pode ser usada com pouco treinamento. Além disso, o InfoPath permite que você colete dados com pesquisas de qualidade superior sem exigir muito da administração de TI.
O InfoPath 2007 funciona perfeitamente com o WSS e o MOSS para facilitar soluções de pesquisa avançadas e complexas que são compatíveis com várias plataformas e navegadores. Isso permite também que sua empresa explore um de seus ativos mais importantes: a informação.
Uso de email para pesquisas rápidas
As pesquisas improvisadas são uma ferramenta essencial para coletar rapidamente dados de um pequeno grupo de pesquisados. As pesquisas baseadas em email são perfeitas para esse tipo de pesquisa em tempo real – elas podem ser criadas rapidamente e não exigem servidores dedicados nem assistência de TI. Uma das abordagens mais simples, os botões de voto incorporados em uma mensagem do Microsoft® Outlook®, permite que você envie, receba e organize uma pesquisa unidimensional.
Depois de iniciar uma pesquisa com botões de voto, os seus destinatários receberão uma mensagem de email com um faixa de voto, que exibirá uma lista suspensa de opções. O destinatário responderá clicando em uma das opções. Uma janela pop-up então exibirá uma mensagem "Você escolheu responder: <sua escolha>" e oferece a escolha para Enviar ou Editar a resposta.
O designer de pesquisa, ou um representante atribuído, receberá as respostas individuais em um email e organizará manualmente os resultados. Se a pesquisa incluir um grande número de destinatários, você deverá criar uma regra no Outlook (usando o assistente de regras) que roteará automaticamente as respostas a uma pasta dedicada, como demonstrado na Figura A.
Figura A As respostas da pesquisa serão automaticamente roteadas para uma pasta dedicada
Figura A As respostas da pesquisa serão automaticamente roteadas para uma pasta dedicada
No entanto, os botões de voto são um tanto limitados. Os formulários de pesquisa inseridos em mensagens de email podem coletar muito mais dados, mas a recuperação e a organização manual desses dados podem se tornar impossíveis de gerenciar. No lado mais complexo de pesquisas baseadas em email está o uso de VBScript para personalizar pesquisas do Outlook. Os formulários personalizados podem facilitar a coleta e a análise de grandes quantidades de dados mais complexos. Para acessar a funcionalidade do desenvolvedor no Outlook 2007, você deve primeiro exibir a guia do desenvolvedor, mostrada na Figura B.
Figura B Guia do desenvolvedor no Outlook 2007
Figura B Guia do desenvolvedor no Outlook 2007
A criação de formulários personalizados do Outlook está além do conhecimento do usuário característico do Outlook. Mas o InfoPath® 2007 fornece novos recursos que facilitam a implementação de formulários personalizados. Sem conhecimento especial, os designers de pesquisa podem criar formulários do InfoPath e modelos de três maneiras:
  • Ao importar documentos do Microsoft Word ou planilhas do Excel® existentes.
  • Ao fazer o download de modelos pré-desenvolvidos do InfoPath e modificá-los para atender a necessidades específicas.
  • Ao criar modelos a partir do zero usando a funcionalidade de criação de formulários do InfoPath.
Em todos os três casos, os modelos podem ser publicados no Outlook e distribuídos por email. Com o InfoPath 2007 e o Outlook 2007, algumas horas e pouca ou nenhuma assistência de TI, um operador de informações poderá criar uma pesquisa com vinte perguntas, enviá-la por email para um grupo, receber os resultados no Outlook e analisá-los em uma planilha do Excel.
O único requisito real nesse cenário é que todos os participantes tenham o InfoPath e o Outlook instalados em seus computadores. Além disso, como o InfoPath 2007 na verdade estende a funcionalidade do Outlook 2007, os destinatários podem responder à pesquisa diretamente na interface do Outlook.
Mas o InfoPath oferece muito mais suporte do que apenas pesquisas baseadas em email. Você pode criar modelos que consultem e enviem dados a serviços Web e bancos de dados SQL Server® ou usar um documento XML ou esquema XML existente como a fonte de dados. Em outras palavras, com o mínimo treinamento e pouco ou nenhum código adicionado, um usuário será capaz de explorar a potência e a flexibilidade do XML.
O email como uma solução de pesquisa tem desvantagens notáveis. Por exemplo, essas pesquisas não são anônimas, pois o endereço de email dos pesquisados está disponível. Isso pode reduzir a sinceridade e desviar os resultados. Há também preocupações com a segurança, como ataques de phishing, pois há um limite para o tipo e a profundidade de informações que você pode coletar usando pesquisas baseadas em email.

Criação de uma solução de pesquisa orientada por bancos de dados
As pesquisas baseadas em email não são adequadas para estudos mais complexos que envolvam números elevados de pesquisados – usar uma pasta no Outlook® não é suficiente para gerenciar e analisar todos os dados. Uma solução mais robusta é direcionar as respostas da pesquisa para um banco de dados. Os recursos avançados de armazenamento, indexação, processamento e relatórios que você obtém com um banco de dados podem ser muito úteis. O Microsoft® SQL Server® 2005, por exemplo, inclui o SQL Server Reporting Services, que pode ser usado para processar automaticamente os resultados da pesquisa.
Para criar um modelo de formulário do InfoPath que enviará respostas a um banco de dados, você deverá primeiro criar um banco de dados do Access® ou SQL Server na sua rede. Então, no InfoPath®, você poderá iniciar o processo de criação de modelos usando o assistente de criação de modelos de formulário. Isso abrirá o assistente de conexão de dados, que o guia no processo de vinculação do seu formulário ao banco de dados. O InfoPath usa as informações no seu banco de dados para criar os campos de dados e consulta de fonte de dados.
A maioria dos operadores terá conhecimento suficiente para concluir e enviar a pesquisa com pouco treinamento ou suporte. No entanto, nesse cenário (no qual os dados são passados diretamente para o banco de dados), os pesquisados devem ter o InfoPath e o Outlook instalados e eles devem estar por trás do firewall corporativo ou ter acesso de VPN à rede corporativa.
O assistente de conexão de dados do InfoPath tem uma interface somente com bancos de dados Microsoft SQL Server 2000 ou posterior e Access que estiverem usando nativamente ADOXML. O envio direto ao banco de dados não é compatível com outros bancos de dados. Outras limitações são que o InfoPath não permite que controles de rich text sejam vinculados aos campos do banco de dados e tipos de dados binários elevados não são compatíveis.
Como a topologia de rede se torna cada vez maior e mais complexa, ela se torna cada vez mais vantajosa para o envio de dados a um serviço Web intermediário para, em seguida, passar esses dados para um banco de dados. O desacoplamento do front-end do formulário de pesquisa do back-end do banco de dados, por meio de um serviço Web, também facilita a implementação da lógica comercial no servidor Web. E, como o serviço Web é realizado em conexões HTTP ou HTTPS, os participantes podem enviar dados por meio de firewalls, como mostra a Figura C. Observe, no entanto, que os pesquisados ainda devem ter o InfoPath 2003 ou o 2007 instalado.
A desvantagem desse cenário é que a implementação requer a participação de TI. Descrever esse processo em detalhes está além do escopo deste artigo, mas desejo alertá-lo que a criação de uma solução de banco de dados a partir do zero é uma realização significativa. Ela requer planejamento com antecedência, bom design de pesquisa, programação do serviço Web e design do back-end do banco de dados. O InfoPath 2007 simplifica o aspecto de design dos formulários do processo, mas a solução completa requer programação sólida e habilidades de design de banco de dados. Além disso, o acréscimo de funcionalidade avançada, como suporte a vários idiomas e fluxo de trabalho, aumenta rapidamente o custo da implementação.
Figura C Fluxo de dados do InfoPath por meio de um serviço Web
Figura C Fluxo de dados do InfoPath por meio de um serviço Web

Jim Bradley é o proprietário da CoyoteTech LLC, uma empresa de comunicações técnicas especializada em documentação de assistência a usuários de produtos de servidor Microsoft. Os projetos de documentação incluem "Transporte de Borda do Microsoft Exchange Server 2007 e proteção das mensagens", "Adotando os 64 bits com o Exchange Server 2007" e "Guia de Referência Técnica do Microsoft Exchange 2003".


 SharePoint: Padronize o gerenciamento de dados com tipos de conte&#250;do personalizados
SharePoint Pav Cherny

Padronize o gerenciamento de dados com tipos de conteúdo personalizados
Visão geral:
  • Gerenciamento do ciclo de vida do conteúdo com o SharePoint
  • Criando painéis de informações de documentos
  • Editando documentos do Office e SharePoint por meio do InfoPath
Faça download do código deste artigo: ContentTypes2008_02.exe (779KB)

O grande número de documentos e outros itens de conteúdo geralmente encontrados em u ambiente empresarial representam desafios comerciais e técnicos para o gerenciamento de documentos, seus
metadados e seus comportamentos em uma maneira centralizada e reutilizável. O Microsoft® Office SharePoint® Server 2007 promove a colaboração em toda a empresa permitindo às equipes distintas dentro de uma organização compartilhar espaços de trabalho em sites, bibliotecas de documentos e listas.
O SharePoint 2007 possibilita a padronização de muitos aspectos das características de conteúdo e ciclo de vida por meio de tipos de conteúdo. Tipos de conteúdo de sites são definições de metadados que podem ser estabelecidos independentemente de qualquer conjunto de sites, sites, listas ou bibliotecas de documentos específicos. Isso permite o estabelecimento de propriedades, fluxos de trabalho, diretivas de gerenciamento de informações e outros elementos em toda a empresa de maneira consistente enquanto permite também aos departamentos individuais e proprietários de sites personalizar os tipos de conteúdo para objetivos específicos.
Netse artigo mostrarei como usar o novo modelo de conteúdo do SharePoint apresentado com o Windows® SharePoint Services (WSS) 3.0 e o Microsoft Office SharePoint Server (MOSS) 2007 para criar hierarquias para conteúdos empresariais baseados em características gerais. Essas hierarquias de conteúdo habilitam a aplicação uniforme de metadados, fluxos de trabalho e diretivas de gerenciamento de informações em um nível global enquanto fornecem também a flexibilidade de acomodar necessidades de gerenciamento de conteúdo exclusivas no nível de conjuntos de sites, sites, bibliotecas de documentos e listas.
Para ilustrar alguns dos aspectos de nível baixo dos tipos de conteúdo do SharePoint, incluí uma série de ferramentas personalizadas no material de acompanhamento e também o código-fonte, caso você deseje estender essas ferramentas conforme suas necessidades específicas. Lembre-se de que essas ferramentas não foram totalmente testadas e não devem ser usadas em sistemas de produção. É possível baixar o código na TechNet Magazine em technetmagazine.com/code08.aspx.

Definições de ciclo de vida de conteúdo e tipo de conteúdo
Recursos do SharePoint
  • Blog da equipe do InfoPath
  • Fluxos de trabalho no Office SharePoint Server 2007
  • TechNet Webcast: Instalação e configuração de pesquisa no SharePoint Server 2007
  • InfoPath Forms Services

Há muitos detalhes a considerar ao gerenciar documentos e outros conteúdos em uma organização. Entre outras coisas, é necessário definir quais pessoas ou processos devem realizar quais ações quando o conteúdo é criado, publicado, arquivado e descartado. Muitas vezes é necessário para uma organização desenvolver modelos específicos para criação de conteúdo, definir funções para atribuir responsabilidades e privilégios de acesso a usuários, fornecer controle de versão, monitorar a conformidade, armazenar e arquivar, definir metadados e assim por diante.
Por mais complexo que um ciclo de vida de conteúdo específico possa ser, o modelo de conteúdo do SharePoint reconhece que há características gerais e fases típicas que determinam como os itens de conteúdo individual devem ser manipulados. Por exemplo, é possível estruturar a criação de conteúdo por meio de modelos e formulários de entrada, e a exibição de conteúdo e pesquisas por meio de metadados. É possível usar edição, aprovação ou outros requisitos de fluxo de trabalho, requisitos de arquivamento, períodos de tempo de expiração e diretivas de gerenciamento de informação aplicáveis para distinguir as partes de conteúdo individual. Algum conteúdo pode não necessitar de modelos especiais ou nunca ser arquivado, mas mesmo essas são características de ciclo de vida que se distinguem esses itens de outros.
O modelo de conteúdo do SharePoint permite a definição de tipos de conteúdo individuais e o estabelecimento de relações hierárquicas. Em uma relação hierárquica, os filhos herdam características gerais dos tipos de conteúdo pais, adicionando características específicas conforme necessário.
A melhor forma de ilustrar isso é examinando os tipos de conteúdo internos do SharePoint. O WSS 3.0 e o MOSS 2007 incluem uma série de tipos de conteúdo para itens típicos que podem ser armazenados em uma biblioteca de documentos ou lista, incluindo documentos e tarefas. É possível encontrar as definições desses tipos de conteúdo padrão em um servidor SharePoint na pasta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes. Lá você encontrará um arquivo de manifesto chamado feature.xml. Examinando esse arquivo, é possível observar que o SharePoint implementa as definições de tipo de conteúdo padrão como um recurso oculto (Hidden="TRUE") com um escopo de conjunto de sites (Scope="Site") e que o arquivo de manifesto Element contendo os elementos de tipo de conteúdo reais é ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />).
Se você estiver interessado em aprender mais sobre os recursos do SharePoint, recomendo a leitura da coluna Espaço do Office de Ted Pattison na MSDN® Magazine entitulada "Recursos do SharePoint", disponível em msdnmagazine.com/issues/07/05/OfficeSpace.
Agora, vamos abrir o arquivo ctypeswss.xml no Notepad para examinar os tipos de conteúdo padrão independentemente de sua visibilidade na interface do usuário do SharePoint. Você não deve modificar o ctypeswss.xml. Se você pensar em editar o ctypeswss.xml para adicionar novos campos aos tipos de conteúdo padrão ou tornar visíveis os tipos de conteúdo ocultos para que os usuários do SharePoint possam usá-los para derivar novos tipos, observe que isso não é geralmente necessário. Além disso, isso leva a configurações sem suporte e a instalação posterior de service packs pode substituir as suas personalizações e desfazer as suas soluções de gerenciamento de conteúdo.
Uma abordagem melhor é copiar o que for necessário em um novo arquivo de manifesto, adicionar as suas personalizações conforme necessário e implantar os seus tipos de conteúdo personalizados como um novo recurso com um escopo de conjunto de sites para que possam estar disponíveis para todos os sites dentro do conjunto de sites.
A definição baseada na Collaborative Application Markup Language (CAML) do tipo de conteúdo System como especificada no ctypeswss.xml é revelada a seguir:
<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>
Os atributos Group e Sealed mostram que o tipo de conteúdo System é oculto e selado para que não possa ser alterado na interface de usuário do SharePoint. O tipo de conteúdo System tem somente um elemento FieldRef que faz referência a uma coluna de site interno chamado ContentType. Esse é o maior nível de abstração. Todos os outros tipos de conteúdo do SharePoint herdam essa propriedade do tipo de conteúdo System. Desse modo, o SharePoint certifica que todos os itens de conteúdo armazenados em qualquer biblioteca de documentos ou lista tenha essa propriedade em comum.
A Figura 1 mostra uma Web Part ContentTypeHierarchy incluída no material de acompanhamento deste artigo, que ilustra as hierarquias mais intuitivamente. O System está na raiz de todos os outros tipos de conteúdo, seguido de Item e assim por diante. O tipo de conteúdo Item, por exemple, estabelece o nível de detalhe posterior. Se você verificar o ctypeswss.xml, é possível observar que o Item define um único campo de metadados que faz referência a uma coluna de site chamada Title. Desse modo, todos os tipos de conteúdo internos em níveis mais baixos têm uma propriedade Title.
Figura 1 Hierarquia de tipo de conteúdo interna do WSS 3.0
Figura 1 Hierarquia de tipo de conteúdo interna do WSS 3.0
É possível também remover um campo herdade, como demonstra a definição do tipo de conteúdo Document no ctypeswss.xml. O tipo de conteúdo Document inclui vários elementos RemoveFieldRef correspondentes, mas talvez você deseje manter o campo Title no local nos seus tipos de conteúdo personalizados porque a coluna Title fornece acesso ao menu suspenso Edit Control Box (ECB) nas exibições de biblioteca de documentos e lista do SharePoint.
Um bom exemplo para ilustrar como renomear campos herdados é o tipo de conteúdo Far East Contact no ctypeswss.xml. Pesquise por 0x0116, que é o ID de tipo de conteúdo correspondente e marque o elemento FieldRef com o atributo Name="Title" para observar como é possível usar o atributo DisplayName para renomear um campo na interface do usuário. Nesse exemplo específico, o atributo DisplayName altera o nome do campo Title na interface do usuário para um valor de dados localizado referenciado por "$Resources:core,Last_Name;".
Se você analisar melhor a Figura 1, é possível observar o atributo ID do elemento ContentType identificando de maneira exclusiva o tipo de conteúdo e estabelecendo a relação hierárquica. Todos os IDs começam com o ID do tipo de conteúdo pai anexado com valores hexadecimais adicionais. Os tipos de conteúdo padrão têm dois valores hexadecimais adicionais anexados para criar um novo ID exclusivo para o tipo de conteúdo filho. Outra técnica é anexar um “00” e um GUID hexadecimal. É assim que os tipos de conteúdo Office Data Connection File e Universal Data Connection File derivam do tipo de conteúdo Document, por exemplo.
Um ponto importante a ser lembrado pelos usuários é que o atributo ID do elemento ContentType não pode ter mais de 1,024 caracteres. Isso pode se tornar um problema em relações hierárquicas grandes se todos os tipos de conteúdo usarem a técnica de solução de GUID hexadecimal. No entanto, não é uma boa idéia começar com a técnica menor porque esses IDs podem não ser exclusivos.
Para garantir a exclusividade, use a técnica GUID para estabelecer um namespace global para os tipos de conteúdo da sua empresa e alternar para a técnica menor dentro desse namespace. Para obter informações detalhadas sobre o atributo ID e outros elementos de definição de tipo de conteúdo, consulte o tópico "Content Type Definition Schema" no WSS 3.0 SDK.

Dependências de tipo de conteúdo
Agora vamos examinar a questão de como usar os tipos de conteúdo do SharePoint 2007 para estruturar o gerenciamento de itens de conteúdo. É necessário levar em consideração várias dependências, como as interdependências entre bibliotecas de documentos e listas, tipos de conteúdo, colunas de site e tipos de campo. As bibliotecas e listas fazem referência a tipos de conteúdo, que fazem referência a colunas de site, que por sua vez fazem referência a tipos de campo (como os tipos de campo do WSS padrão texto, nota, escolha, número, moeda e assim por diante), que por sua vez reside nos assemblies do Microsoft .NET Framework, como o principal assembly WSS Microsoft.SharePoint.dll.
Por exemplo, retornemos ao tipo de conteúdo System conforme ilustrado anteriormente na definição CAML da entrada de arquivo de manifesto de tipo de conteúdo System. Como você viu, esse tipo de conteúdo contém um elemento FieldRef que faz referência a uma coluna de site chamada ContentType. Observe que a definição de tipo de conteúdo não define a coluna de site ContentType real. O ContentType é um campo Text, definido no manifesto Elementos fieldswss.xml, localizado na pasta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields. O tipo de campo Text, novamente, é definido em fldtypes.xml, que pode ser encontrado em %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML. Um ponto importante a se observar nessa árvore de dependência é que é necessário garantir que todos os recursos estejam disponíveis nos seus servidores SharePoint.
Os tipos de conteúdo que você desejar usar devem ser criados no nível do site das suas bibliotecas de documentos e listas ou em posição superior na hierarquia do site. De maneira semelhante, os campos de metadados dos seus tipos de conteúdo devem fazer referência às colunas de site existentes. É possível adicionar colunas de site padrão ou personalizadas baseadas nos tipos de campo padrão ou personalizados para seus tipos de conteúdo, mas você deve certificar-se de que as colunas de site existam no site local. Além disso, se você desejar usar tipos de campo personalizados, será necessário também certificar-se de que os assemblies .NET subjacentes sejam implantados nos seus servidores SharePoint.
Existem dependências similares para tipos de conteúdo que fazem referência a modelos de documentos, receptores de eventos personalizados, fluxos de trabalho e outros componentes. Por exemplo, a definição de tipo de conteúdo pode conter um elemento DocumentTemplate que aponta para o modelo de documento associado com o tipo de conteúdo. A definição de tipo de conteúdo pode também conter um elemento XmlDocument com um ou mais elementos filho XmlDocument que definem características adicionais do tipo de conteúdo, como definições de namespace, definições de painel de informações de documento ou qualquer informação personalizada.

Estabelecendo tipos de conteúdo global
Os usuários com permissões de autoria podem criar novos tipos de conteúdo e colunas de site diretamente na interface de usuário do SharePoint, mas os tipos de conteúdo estão disponíveis então somente no site local e em posição inferior na hierarquia do site. As colunas de site personalizadas estão disponíveis apenas no site local. Isso não é suficiente se você desejar estabelecer tipos de conteúdo globais. É necessário certificar-se de que os tipos de conteúdo globais estejam disponíveis em todos os conjuntos de sites no seu ambiente. É aqui que os recursos do SharePoint se mostram realmente úteis. É simples instalar e ativar os recursos do SharePoint em vários conjuntos de sites para aplicar a coluna de site e definições de tipo de conteúdo correspondentes de maneira consistente em todos os locais.
O material de acompanhamento deste artigo inclui um recurso de exemplo chamado AdventureWorks que demonstra como estabelecer um tipo de conteúdo global. O recurso define um tipo de conteúdo geral chamado Customer Documentation que pode ser usado para criar qualquer tipo de materiais de cliente, como propostas e cartas de venda. É razoável pressupor que todos esses tipos de documentos devam estar associados com informações de cliente como nome da empresa, detalhes de contato e endereço. Eu criei especificamente um campo personalizado chamado Customer Name para o seu tipo de conteúdo e adicionei campos internos como Department e Primary Phone. É possível alterar o tipo de conteúdo e campos editando o arquivo ContentTypes.xml e as referências de campo editando o arquivo SiteColumns.xml no exemplo de acompanhamento.
Se você implantar o recurso conforme descrito no arquivo readme.htm, é possível ativá-lo consistentemente em vários conjuntos de sites. O tipo de conteúdo Customer Documentation estará, então, disponível globalmente. Com isso, os departamentos individuais podem criar documentação do cliente específica por meio de tipos de conteúdo derivados associados com modelos de documento Por exemplo, a definição de tipo de conteúdo pode conter um elemento DocumentTemplate que aponta para o modelo de documento associado com o tipo de conteúdo de destino. O material de acompanhamento inclui modelos de documento de exemplo que podem ser usados em vendas e consultoria. A Figura 2 mostra os tipos de conteúdo resultantes.
Figura 2 Tipos de conteúdo pais e filhos para documentação do cliente
Figura 2 Tipos de conteúdo pais e filhos para documentação do cliente
Há várias opções de escolha para criar recursos para colunas de site personalizados e tipos de conteúdo no WSS 3.0 e MOSS 2007. É possível estudar o WSS 3.0 SDK e escrever arquivos XML do zero. É possível também escolher usar o SharePoint Designer para exportar uma lista para um pacote da Web pessoal, renomear o arquivo .fwp resultante para um arquivo .cab, extrair o arquivo manifest.xml do arquivo .cab e pesquisar pelas definições ContentType no arquivo manifest.xml. Infelizmente as duas abordagens são inconvenientes e propensas a erro.
Em contraste, é consideravelmente fácil criar colunas de site e tipos de conteúdo personalizadas na interface do usuário do SharePoint. Ainda assim, a interface não fornece uma opção para editar os arquivos XML de um recurso. Os recursos são uma forma eficiente de provisionar recursos SharePoint, mas uma vez provisionados os recursos existem somente no banco de dados de conteúdo. Talvez uma versão futura do WSS inclua a capacidade de exportar colunas de site e tipos de conteúdo em arquivos XML por meio da interface do usuário do SharePoint, de maneira semelhante à exportação de Web Parts. Por enquanto, é necessário trabalhar com o que você tem.
O material de acompanhamento inclui uma Web Part chamada ContentTypeSchema que pode ser usado como ponto de partida. Ele usa o modelo de objeto do SharePoint para extrair a propriedade SchemaXML do tipo de conteúdo selecionado. Por meio de transformações baseadas em eXtensible Stylesheet Language Transformation (XSLT), a Web Part deriva definições Field ou definições ContentType dependendo da opção selecionada na interface do usuário antes de clicar no botão Display.
A Figura 3 mostra essa Web Part em ação. Ela exibe o tipo de conteúdo Active Directory® Documentation, que baseei no tipo de conteúdo Customer Documentation. O tipo de conteúdo Active Directory Documentation é associado a um modelo do Microsoft Word personalizado (Active Directory Template.dot). Observe que esse tipo de conteúdo não tem campos adicionais. Todos os campos são herdados do tipo de conteúdo pai.
Se você planeja usar a Web Part ContentTypeSchema no seu próprio ambiente, lembre-se de que essa Web Part não foi totalmente testada. Minha Web Part usa transformações XSL relativamente complexas para criar um delta entre a propriedade SchemaXML do tipo de conteúdo selecionado e seu tipo de conteúdo pai. Ainda assim, XSLT 1.0 não é realmente desenvolvido para conversões de documentos XML avançadas. Não há recursos internos para comparar nós XML. Além disso, namespaces XML, bem como seções CDATA, representam dificuldades que o XSLT 1.0 não consegue manipular de maneira eficiente.
O SharePoint armazena a definição de colunas de site e tipos de conteúdo de site criados usando a interface do usuário do SharePoint ou modelo de objeto do SharePoint no banco de dados de conteúdo em uma tabela chamada ContentTypes. Na Figura 3, observe o ID do meu tipo de conteúdo personalizado. Da mesma forma, a declaração T-SQL a seguir fornece resultados exatos: SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>.
Figura 3 Definição de tipo de conteúdo personalizado no ContentTypeSchema Web Part
Figura 3 Definição de tipo de conteúdo personalizado no ContentTypeSchema Web Part
Seja qual for a abordagem que você decida usar, criar recursos para tipos de conteúdo para toda a empresa é muito simples depois que você obtém as definições da coluna do site e tipo de conteúdo. Recomendo que você use um recurso único para todas as colunas de site e tipos de conteúdo globais do seu departamento ou empresa. Desse modo, fica claro onde adicionar novas definições de coluna de site e tipo de conteúdo.

Pesquisas em toda a empresa por metadados personalizados
Uma vantagem imediata das hierarquias de tipo de conteúdo é que todos os tipos de conteúdo filhos herdam os campos de metadados do tipo de conteúdo pai. Como todos os tipos de conteúdo têm campos de metadados em comum, é realmente fácil para os usuários criarem exibições e filtros personalizados nas bibliotecas de documentos.
O recurso de exemplo AdventureWorks demonstra isso de maneira intuitiva. Independentemente do conteúdo que um consultor ou vendedor cria, salvar o documento do Word 2007 resultante na biblioteca de documentos exige a especificação de um Customer Name, pois o tipo de conteúdo pai Customer Documentation define esse campo de metadados como obrigatório. Por meio do agrupamento ou filtragem dos itens em uma exibição da biblioteca de documentos de acordo com o Customer Name, os consultores e os membros da equipe de vendas podem localizar toda a documentação existente de um cliente de maneira rápida e conveniente, como mostrado na Figura 4.
Figura 4 Agrupando vários documentos em uma biblioteca baseada em metadados comuns
Figura 4 Agrupando vários documentos em uma biblioteca baseada em metadados comuns
Metadados comuns também tornam fácil localizar conteúdo em várias bibliotecas de documentos e sites usando as capacidades de pesquisa do WSS 3.0 e MOSS 2007. O WSS oferece suporte de pesquisa em bibliotecas, listas e sites dentro de um único conjunto de sites. O MOSS 2007 vai além dessas capacidades básicas permitindo a implementação de um Centro de Pesquisa em toda a empresa e o gerenciamento de metadados personalizados na interface do usuário da Administração Central do SharePoint 3.0. Por esse motivo, as explicações seguintes se concentram no MOSS 2007.
Ao configurar um Shared Service Provider (SSP) no MOSS 2007 e rastrear os seus sites do SharePoint, o MOSS 2007 pode descobrir automaticamente os campos de metadados personalizados usados nas fontes de conteúdo. Da mesma forma, é possível encontrar os campos de metadados personalizados na lista de propriedades rastreadas.
Os campos de metadados definidos nos recursos do SharePoint geralmente se encaixam na categoria SharePoint. Para encontrar o seu local na Administração Central do SharePoint, no menu Inicialização Rápida em Shared Services Administration, clique no link para o seu SSP, nas configurações de Pesquisa, em mapeamentos de propriedade de Metadados, em Propriedades Rastreadas no menu Inicialização Rápida e abra a categoria SharePoint.
Mostrarei um exemplo desta ação. O campo de metadados nomeado Customer Name acaba como uma propriedade rastreada chamada ows_Customer_x0020_Name. O SharePoint coloca um prefixo nas propriedades rastreadas com "ows_" e "_x0020_" é a versão codificada de um espaço único. Se você exibir os detalhes dessa propriedade rastreada, é possível encontrá-la incluída no índice de pesquisa por padrão para que os usuários possam empregar os valores dessa propriedade rastreada para realizar pesquisas de conteúdo. No entanto, para aumentar a precisão da pesquisa, talvez você não deseje mapear a propriedade rastreada para uma propriedade gerenciada para que os usuários possam pesquisar explicitamente pelo conteúdo por nome do cliente.
Há duas opções ao mapear propriedades rastreadas para propriedades gerenciadas. É possível gerar automaticamente uma nova propriedade gerenciada para cada propriedade rastreada ou mapear propriedades rastreadas manualmente para propriedades gerenciadas. A primeira opção está disponível quando são exibidas as configurações da categoria de propriedade rastreada desejada (ao exibir as propriedades rastreadas em uma categoria, como a categoria SharePoint, clique na opção Editar Categoria no link Inicialização Rápida). Em Configurações de Propriedades Rastreadas em Massa, seria necessário selecionar a caixa de seleção “Gerar automaticamente uma nova propriedade gerenciada para cada propriedade rastreada descoberta nesta categoria”. No entanto, o SharePoint coloca um em propriedades gerenciadas criadas automaticamente com "ows" e escapa espaços com "_x0020_". A propriedade gerenciada da propriedade rastreada ows_Customer_x0020_Name seria owsCustomerx0020Name. No entanto, esse não é um nome de propriedade muito amigável.
Talvez uma estratégia melhor seja mapear as propriedades rastreadas para propriedades gerenciadas manualmente depois de implantar os seus tipos de conteúdo em toda a empresa. É possível mapear uma propriedade rastreada para uma ou mais propriedades gerenciadas. Para criar novas propriedades gerenciadas, na Administração Central do SharePoint, no menu Inicialização Rápida Shared Services Administration, clique no link para o seu SSP, nas configurações de Pesquisa, em mapeamentos de propriedade de Metadados e em Nova Propriedade Gerenciada para especificar as informações necessárias e associar a nova propriedade gerenciada com a propriedade rastreada desejada.
Os usuários podem então localizar itens de conteúdo relevantes usando as propriedades gerenciadas tanto em property: syntax ou usando a pesquisa avançada. Por exemplo, se você mapear a propriedade rastreada ows_Customer_x0020_Name para uma propriedade gerenciada nomeada Customer, os usuários poderão pesquisar por todos os documentos de um cliente simplesmente especificando Customer: <Nome do cliente> na caixa de pesquisa padrão, como Customer: Contoso.
É também uma boa idéia incluir propriedades gerenciadas para os campos de metadados mais importantes dos seus tipos de conteúdo na lista de propriedades na página Pesquisa Avançada. Para tanto, exiba a página Pesquisa avançada, clique em Ações do Site e selecione o comando Editar Página. Agora é possível clicar em Editar na Caixa de Seleção Avançada para selecionar a opção Modify Shared Web Part. Ao expandir a categoria Properties e colocar o cursor no campo de texto correspondente, é possível clicar no botão para editar o documento XML Properties. É necessário adicionar uma definição de propriedade ao elemento <PropertyDefs>, como <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/> e é necessário também adicionar uma referência a essa definição de propriedade em um elemento ResultType (por exemplo, o elemento <ResultType DisplayName="All Results" Name="default">), como <PropertyRef Name="Customer" />. A Figura 5a exibe a interface do usuário Pesquisa Avançada resultante. A Figura 5b exibe os resultados da pesquisa.
Figura 5a Pesquisa por documentação de infra-estrutura de TI baseado no nome do cliente
Figura 5a Pesquisa por documentação de infra-estrutura de TI baseado no nome do cliente
Figura 5b Os resultados da pesquisa de nome de cliente
Figura 5b Os resultados da pesquisa de nome de cliente

Garantindo a consistência da informação
Nesse ponto, padronizei com êxito os campos de metadados e tipos de conteúdo mais importantes e estendi as capacidades de pesquisa em conjuntos de site na minha empresa baseado no MOSS 2007. Agora é importante garantir que os usuários insiram informações precisas nos campos de metadados.
Há duas maneiras de fazer isso. Primeiro, é possível substituir o painel de informações de documento padrão nos seus modelos de documentos com um formulário do InfoPath® personalizado que fornece aos seus usuários uma seleção predefinida de opções de entrada, como você tem em uma caixa de listagem. Em segundo lugar, é possível ligar um receptor de eventos ao tipo de conteúdo e verificar a precisão dos metadados e outras informações sempre que os usuários criarem, modificarem ou excluírem itens de conteúdo correspondentes.
As duas opções complementam uma à outra. Um formulário do InfoPath fornece principalmente uma maneira conveniente de editar as propriedades de um tipo de conteúdo do SharePoint, enquanto um receptor de eventos pode garantir metadados válidos mesmo que os usuários editem as propriedades do tipo de conteúdo fora do formulário do InfoPath. É possível ligar manipuladores de eventos a tipos de conteúdo específicos, o que permite a você especificar eventos e suas respostas para todos os documentos associados com um tipo de conteúdo individual em todos os conjuntos de sites, independentemente da biblioteca de documentos. É possível encontrar mais informações sobre como desenvolver e implantar manipuladores de eventos em msdn2.microsoft.com/ms453149.
Talvez o método mais fácil para associar um tipo de conteúdo com um painel de informações de documento personalizado seja exibir as configurações do Painel de Informações de Documento do tipo de conteúdo na interface do usuário do SharePoint em um computador com o InfoPath 2007 instalado. É possível então clicar no link Criar um Novo Modelo Personalizado em Modelo de Painel de Informações de Documento para iniciar o InfoPath 2007 no modo de design. No entanto, se o seu tipo de conteúdo de site inclui colunas de site sem um atributo SourceID explícito, talvez você encontre uma situação na qual o InfoPath não possa criar um esquema XSD válido para o formulário Painel de Informações de Documento. Por exemplo, o tipo de conteúdo Customer Documentation apresentado anteriormente inclui várias colunas específicas de contato como Department, Office e e-mail que podem causar esse problema, conforme ilustrado na Figura 6.
Figura 6 Incompatibilidades com o esquema XSD no InfoPath 2007
Figura 6 Incompatibilidades com o esquema XSD no InfoPath 2007
Nesse ponto, há duas opções caso você encontre esse problema. É possível remover as referências a colunas de site sem um atributo SourceID explícito da definição de tipo de conteúdo ou substituir as colunas de site internas que causam o problema com colunas de site personalizadas que sejam compatíveis com o InfoPath 2007. Lembre-se de que não é possível alterar as referências de campo de um tipo de conteúdo baseado em CAML depois de ter sido provisionado no banco de dados de conteúdo, especialmente se você já tiver criado tipos de conteúdo filhos. Não é mais possível simplesmente atualizar o arquivo de definição de tipo de conteúdo baseado em CAML ou empurrar alterações nos tipos de conteúdo filhos porque o Windows SharePoint Services não controla alterações realizadas em definições de tipo de conteúdo pai.
Para empurrar as alterações, é necessário alterar o tipo de conteúdo pai por meio da interface do usuário ou do modelo de objeto do SharePoint, ou definir um novo tipo de conteúdo que seja derivado do existente. A segunda técnica permite a você remover os campos críticos e adicionar novas colunas. Os seus usuários podem então derivar tipos de conteúdo futuros do novo tipo de conteúdo. Para evitar que os usuários escolham o tipo de conteúdo errado, adicione o tipo de conteúdo anterior ao grupo de tipo de conteúdo _Hidden.
Como eu disse antes, não é possível atualizar tipos de conteúdo baseados em CAML depois de implantá-los e ativá-los. Desse modo, é muito importante testar os tipos de conteúdo globais antes da implantação. Para obter mais informações, consulte o artigo da MSDN “Atualizando tipos de Conteúdo” em msdn2.microsoft.com/aa543504.
Depois de criar um tipo de conteúdo com as referências de campo apropriadas, é possível criar um painel de informações de documento personalizado no InfoPath 2007. A melhor estratégia é deixar que os proprietários de sites criem painéis de informações de documento personalizado para os seus tipos de conteúdo filhos. O InfoPath 2007 fornece a opção de publicar os painéis de informações de documento personalizados diretamente nos tipos de conteúdo selecionados, facilitando o cenário de implantação. Ainda assim, é possível também publicar o formulário do InfoPath em um local central, como uma biblioteca de documentos, e incluir uma referência ao painel de informações de documento no tipo de conteúdo. Essa é a melhor opção se você planeja fornecer um painel de informações de documento personalizado juntamente com os seus tipos de conteúdo CAML. A Figura 7 ilustra a arquitetura de implementação.
Figura 7 Implementação de arquivo XSN em um local central no MOSS 2007
Figura 7 Implementação de arquivo XSN em um local central no MOSS 2007
O download de acompanhamento deste artigo inclui um recurso chamado AdventureWorks_Update que estende o recurso AdventureWorks anterior adicionando colunas de site adicionais que funcionam com o InfoPath 2007. O recurso AdventureWorks_Update marca o tipo de conteúdo Customer Documentation original como oculto e deriva um novo tipo de conteúdo chamado Customer Docs, que substitui os campos internos herdades com a nova coluna de site e associa o novo tipo de conteúdo a um painel de informações de documento personalizado.
A nova definição de tipo de conteúdo Customer Docs inclui um elemento XmlDocument que fornece informações sobre o painel de informações de documento. O elemento xsnLocation aponta especificamente para o formulário do InfoPath http://companyresources/DIPs/customerDIP.xsn, que implementa o painel de informações de documento. Para obter instruções detalhadas sobre como aplicar o recurso AdventureWorks_Update, consulte o arquivo readme.htm na pasta AdventureWorks_Update.

Conclusão
É possível usar os tipos de conteúdo do SharePoint para criar diretivas de metadados e usá-las de maneira consistente na empresa para o gerenciamento de conteúdo. A hierarquia de tipos de conteúdo permite padronizar características relevantes à todo o ambiente empresarial e sua aplicação uniforme em todos os sites por meio de herança.
Entre outras coisas, é possível estender as capacidades de pesquisa internas do MOSS 2007 para que os usuários possam localizar conteúdo específico de maneira mais rápida e conveniente. É possível também impor a consistência das informações relacionadas a metadados e estabelecer diretivas de gerenciamento de informações centralizadas. A melhor estratégia é padronizar os tipos de conteúdo globais nas características de metadados mais abstratas para minimizar a necessidade de alterações posteriores. Baseado em um modelo de conteúdo cuidadosamente desenvolvido, os tipos de conteúdo do SharePoint forneces novas capacidades de padronização de gerenciamento de ciclo de vida de conteúdo na empresa.

Pav Cherny é presidente da Biblioso Corporation, especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada. Seus trabalhos publicados se concentram em operações de TI e administração de sistemas.


 Office Communications Server: Como a presen&#231;a aprimora o OCS 2007
Office Communications Server Rajesh Ramanathan

Como a presença aprimora o OCS 2007
Visão geral:
  • Serviços de autorização e diretório
  • Opções de mensagem no OCS 2007
  • Roteamento de comunicações com presença

O Microsoft Office Communication Server (OCS) 2007 baseia-se nos pontos fortes da versão de 2005 do Live Communication Server (LCS). O LCS 2005 fornece mensagens instantâneas
(IM) e presença de classe corporativa. Ele também introduziu a integração de telefonia com as instalações PBX existentes por meio de RCC (Controle de Chamada Remota).
O OCS 2007 aprimora ainda mais a presença e os recursos de mensagem instantânea do LCS 2005 e adiciona recursos de telefone e mídia avançados ao Office Communicator 2007, tornando-se um "softphone" completo. A Microsoft também desenvolveu servidores de conferência e servidores de borda para mídia que permitem que você atenda a todas as necessidades de comunicação de sua organização junto com um PBX existente ou independentemente como uma solução completa por si só.
O Office Communicator 2007 fornece recursos de "softphone" que permitem que os seus usuários escolham os dispositivos USB que preferem, bem como fornece uma experiência avançada para o usuário, a fim de tornar todos os recursos comuns de controle de chamada, como reter e transferir, detectáveis e fáceis de usar. Os usuários não precisam mais gravar números de telefone ou usar um teclado de discagem. Em vez disso, eles podem fazer uma chamada facilmente com um clique em um aplicativo de desktop ou criar uma chamada de conferência ao arrastar e soltar listas de pessoas ou de distribuição em uma conversa.
Para aqueles que precisam de telefones de desktop reais, o Office Communicator Phone Edition (ou telefone Tanjay) atua como apenas outro ponto de extremidade para o usuário, usando menus de contexto habilitados por tela de seleção por toque e a presença familiar do Office Communicator.
Esses recursos do sistema de OCS são incorporados no conceito da presença de usuário. O OCS 2007 utiliza a disponibilidade de usuário, pontos de extremidade de comunicação e relações de usuário para conectar pessoas usando o meio mais apropriado a qualquer momento. Além disso, como o OCS é vinculado com voz, email, mensagens instantâneas e outros caminhos de comunicação, ele pode ajudá-lo a rotear mensagens do modo mais produtivo possível.
Neste artigo, apresentarei uma visão geral da solução OCS 2007 e explicarei como várias partes se encaixam. Também abordarei como a presença é utilizada como um importante ingrediente na receita de comunicação unificada e como ela pode ser utilizada para rotear chamadas de voz com mais eficiência.

Serviços de autorização e diretório
Um sistema de voz corporativo deve ser capaz de verificar as identidades das pessoas que têm permissão para fazer chamadas. Ele também deve ser aplicar restrições ou diretivas em uma base por chamada. Em um sistema VoIP (Voice over IP), os clientes precisam realizar autenticação no servidor para iniciar as chamadas. Isso é semelhante a um sistema PBX tradicional no qual o acesso à linha física foi suficiente para aplicar a identidade.
O sistema do OCS 2007, mostrado na Figura 1, usa o Active Directory® para a autenticação e o armazenamento de diretivas de acesso, e o OCS autoriza chamadas ao validá-las em relação às diretivas para um usuário no Active Directory. Como o OCS usa as mesmas informações do Active Directory utilizadas por outros aplicativos Microsoft, como Exchange Server ou Microsoft® Outlook®, você pode simplesmente adicionar recursos de voz a usuários existentes no Active Directory ao ampliar as propriedades e diretivas de um usuário (por meio das extensões de esquema do Active Directory) e fornecer um diretório unificado que pode ser usado para aplicativos em tempo real, como voz ou mensagem instantânea.
Figura 1 Componentes da comunicação unificada do OCS
Figura 1 Componentes da comunicação unificada do OCS
No Active Directory, a propriedade mais importante relacionada à comunicação unificada é o endereço de protocolo SIP (também conhecido como URI de SIP), que é muito semelhante ao endereço de email do usuário. Por exemplo, um usuário no Active Directory com o endereço de email someone@contoso.com receberia um endereço SIP sip:someone@contoso.com. Como o endereço SIP está vinculado ao objeto do usuário, você poderá fornecer uma única identidade, onde as mesmas credenciais que o usuário utiliza para logon no computador desktop ou servidor Exchange podem ser usadas para acesso ao servidor OCS.
Outra propriedade importante é o número de telefone do usuário. O servidor OCS redireciona internamente as chamadas enviadas para números de telefone para o URI de SIP do usuário, de forma que a chamada seja roteada.
O OCS 2007 fornece uma interface de Serviço de Catálogo de Endereços que está disponível para pesquisa de diretório em uma organização. Como uma versão offline do catálogo de endereços, ele permite pontos de extremidade do cliente para evitar o acesso ao Active Directory sempre que uma operação de pesquisa for realizada por parte do cliente.
Além disso, o OCS 2007 torna as listas de distribuição mais úteis ao fornecer um serviço de DLX (Distribution List Expansion, expansão da lista de distribuição) que permite que os usuários visualizem a mesma lista de distribuição no Office Communicator que verão no Outlook e expandam a lista de distribuição também no Communicator. Os usuários podem configurar chamadas de conferência com membros dessas listas de distribuição diretamente a partir do Office Communicator ou iniciar um bate-papo de mensagem instantânea em grupo.

Serviços de voz e mensagens
Recursos adicionais do OCS
Para obter mais informações, consulte os seguintes recursos:
  • Eventos de comunicação unificada e Webcasts
  • Office Communications Server TechCenter
  • Laboratório virtual da TechNet: Como permitir usuários e instalar o Office Communicator 2007

Uma solução de voz corporativa deve fornecer os recursos de controle de chamada com os quais os usuários tenham maior familiaridade. Levando isso em conta, o OCS 2007 fornece recursos populares, como retenção de chamadas, transferência de chamadas e transferência consultiva, encaminhamento e toque simultâneo, além de modos sem voz, como mensagens instantâneas.
O OCS 2007 é a parte central do roteamento de chamada de voz, fornecendo funções de roteamento de chamada de entrada e de saída. O roteamento de chamada de saída envolve conversão de números, aplicação de diretivas (como restrição de chamadas internacionais) relacionadas a um usuário, bem como roteamento da chamada para os pontos de extremidade apropriados ou para a PSTN (Rede telefônica pública comutada). As funções de roteamento de chamada de entrada são responsáveis pelo encaminhamento da chamada selecionada do usuário ou preferências de hora do dia/presença e roteamento adequado da chamada de entrada.
O OCS não encerra as chamadas de entrada. Na linguagem do SIP, ele atua como um registrador de SIP e um proxy de SIP. A sinalização e a mídia são fornecidas totalmente ponto a ponto pelos pontos de extremidade do cliente no sistema. Os pontos de extremidade no sistema, como Office Communicator 2007, fornecem um codec de áudio de largura de banda (denominado RTAudio) que é adaptável e flexível a condições de rede.
O OCS 2007 fornece conferência Web no local usando as funções de Servidor de conferência para todos os modos de comunicação: áudio, vídeo, mensagem instantânea e dados. Os servidores de conferência com base em OCS permitem que os pontos de extremidade do cliente forneçam transição harmoniosa de comunicação de ponto a ponto para vários participantes e com vários tipos de mídia com recursos como desativar áudio, ejetar participante e bloquear. Ele pode ser dimensionado para centenas de participantes para conferências programadas e até uma centena de discussões ad hoc. Você pode programar conferências por meio dos suplementos do Outlook ou fazer um escalonamento na chamada para uma conferência. A solução de conferência também fornece ferramentas como compartilhamento de arquivos, quadro de comunicações e gravação.
É claro, você deve ser capaz de fornecer conectividade para números de telefone e redes PSTN externos, bem como a corporações federadas ou instalações PBX existentes na organização. O OCS 2007 integra-se com gateways SIP para PSTN oferecidos por provedores de gateways comuns que permitem conexão com PSTN ou com um PBX existente. Um servidor de mediação pode ser configurado para conversão de sinalização e codec. Os servidores de mediação são ideais e estão configurados para gateways não compatíveis com os codecs Microsoft.
O Exchange Server 2007 Unified Messaging é a solução de correio de voz do OCS 2007. O Exchange Unified Messaging fornece resposta a chamadas para chamadas de voz e fax de entrada e enviará a mensagem recebida na caixa de entrada do Exchange do usuário. Além disso, o Exchange Unified Messaging fornece atendedores automáticos corporativos para chamadores externos que desejam entrar em contato com uma pessoa ou departamento específico.
O OCS fornece mensagens instantâneas em tempo real como uma alternativa ao uso de voz, além de permitir que os usuários participem de conversas com vários tipos de mídia, que envolvem voz, vídeo e mensagens instantâneas ao mesmo tempo. Além disso, o Office Communicator 2007 permite rich text e formatação nas mensagens instantâneas. E mais, é possível adicionar áudio e vídeo a qualquer momento à sessão de mensagens instantâneas, escalonando perfeitamente a conversa de mensagens instantâneas a uma conversa de áudio.
Contabilidade, registro e solução de problemas são componentes adicionais. A contabilidade é fornecida usando a funcionalidade do servidor de gravação de detalhes da chamada do OCS 2007. Para cada chamada feita no sistema, é criado um registro da hora em que a chamada foi recebida, o destino que atendeu à chamada e vários outros parâmetros, como se a chamada foi transferida. O OCS também fornece servidores de arquivamento que registram as conversas de mensagens instantâneas para atender aos requisitos de conformidade. O servidor de monitoramento de QoE (Quality of Experience, qualidade da experiência) armazena informações sobre a qualidade das chamadas que foram feitas e pode ser usado para solucionar problemas de qualidade de voz na rede.

Registro e inicialização
Cada ponto de extremidade do cliente no sistema do OCS precisa efetuar registro ou logon no OCS como a primeira etapa na inicialização do cliente. O registro é o processo de conexão com o servidor do OCS e essa etapa anuncia a existência do cliente. O processo de registro envolve a autenticação da identidade do usuário pelo servidor; isso também cria uma associação de segurança entre a instância do cliente e o servidor. Essa associação de segurança é usada para chamadas subseqüentes que o cliente faça por meio do servidor e é atualizada periodicamente pelo cliente através de novo registro. A duração do novo registro varia dependendo da topologia do servidor. Por exemplo, os pontos de extremidade do cliente registrados fora da corporação por meio de um servidor de borda Microsoft AccessTM atualizam seu registro com mais freqüência do que clientes dentro do firewall corporativo.
Observe que somente esses pontos de extremidade do cliente que precisam de um canal autenticado persistente com o OCS para receber notificações de entrada, como chamadas de voz, ou notificações de alteração de presença precisam de registro. O Live Meeting é um ponto de extremidade do cliente que precisa de uma conexão com o OCS somente para o ingresso em uma reunião e, portanto, não precisa de registro com o OCS.
Para compreender melhor os detalhes da interação do cliente no OCS 2007, vejamos mais detalhadamente o Office Communicator como um ponto de extremidade do cliente. (A maioria dos fluxos de sinalização relacionados ao Office Communicator são idênticos aos utilizados para outros pontos de extremidade do cliente, como o Office Communicator Phone Edition ou o Office Communicator Mobile.) Assim que o registro for concluído, o Office Communicator recupera as informações de configuração que são fundamentais para a operação do ponto de extremidade do cliente. Essas informações incluem:
  • Informações próprias, como cartão de visita, endereço de email, URIs de SIP, nome de exibição e número de telefone
  • Recursos que são habilitados no cliente e diretivas
  • Endereços de servidor, como endereço SIP do servidor de borda AV e endereço do servidor de correio de voz
  • Lista de contatos armazenados no servidor
  • Regras de formatação de número do local do cliente
Esse mecanismo de recuperação de todas as informações de provisionamento, usando o canal SPI existente para o servidor, é denominado provisionamento inband. Isso permite que os pontos de extremidade do cliente sejam configurados automaticamente e atualizem suas configurações sempre que os clientes efetuarem logon, inclusive de fora da rede ou do firewall.
A seqüência de registro prosseguirá com o registro no servidor para a inicialização, obtendo e definindo a presença e, finalmente, entrando em um estado estável (veja a Figura 2). Observe que o OCS permite que vários pontos de extremidade do cliente sejam registrados para o mesmo usuário ou URI de SIP. Durante o registro, o servidor retorna um endereço SIP exclusivo para o cliente, de modo que qualquer sinal de entrada possa ser direcionado para o cliente específico. Esse endereço também é conhecido como GRUU (Globally Routable User URI). Cada um dos pontos de extremidade do cliente que são registrados com o OCS recebem um endereço GRUU separado pelo servidor do OCS, identificando exclusivamente o ponto de extremidade do cliente.
Figura 2 Procedimento de registro
Figura 2 Procedimento de registro
Para manter o registro sob controle, há um limite de oito registros ativos permitidos pelo servidor para qualquer usuário. Quando vários clientes forem registrados para o mesmo usuário, a configuração é conhecida como tendo vários pontos de presença (MPOP, Multiple Points of Presence). Quando somente um cliente é registrado, isso é referido como SPOP (Single Point of Presence).
O conceito de MPOP é a parte central do sistema do OCS. Ele permite que o usuário receba chamadas de entrada ou notificações de mensagens instantâneas de qualquer ponto de extremidade, permitindo essencialmente que o usuário tenha vários pontos de extremidade de mensagens instantâneas ou telefones. Ele introduz dinâmicas interessantes de resposta a mensagens instantâneas ou mesmo para o detalhamento da presença exata de um usuário.
Por exemplo, um usuário remoto deve efetuar logon em um Communicator Phone Edition IP Phone (um ponto de extremidade SPOP) que não pode receber mensagens instantâneas. Esse recurso do ponto de extremidade é publicado pelo telefone IP junto com as informações de presença. O status de presença do usuário no telefone é online. Outro usuário poderá visualizar o status de presença online e tentar enviar uma mensagem instantânea usando o Communicator. No entanto, como a presença já publicou a capacidade do dispositivo, uma notificação mostrará que o usuário remoto não está em um dispositivo com capacidade de mensagens instantâneas e, portanto, não poderá receber a mensagem.
Outro exemplo são as mensagens instantâneas de auto-aceitação. Sempre que uma conversa de mensagem instantânea for iniciada, a mensagem será aceita de modo automático e imediato se o usuário remoto estiver em uma instância única do Communicator (novamente, um ponto de extremidade SPOP). Mas se o usuário remoto efetuar logon em duas instâncias do Communicator (digamos em um laptop e em um desktop), então um atraso de 10 segundos será fornecido para permitir que o usuário aceite a mensagem instantânea a partir de um dispositivo. Quando não houver resposta, a mensagem instantânea será aceita automaticamente na instância mais ativa do Communicator.

Presença
A presença tem uma importante função nas comunicações unificadas. Ela permite que um usuário saiba com antecedência sobre a disponibilidade do usuário remoto de se comunicar por meio de um determinado modo. Portanto, os estados do OCS, como “ocupado – em chamada", são associados a um estado ocupado do usuário em vez de um dispositivo ou linha estar ocupado. Além disso, o OCS 2007 fornece uma infra-estrutura de presença aprimorada que permite que o usuário compartilhe informações, como local, horário de trabalho e horário de reunião.
Além disso, o OCS permite que o usuário especifique permissões, de modo que diferentes grupos de pessoas possam ter acesso a diferentes conjuntos de informações de presença com base no nível de acesso. O OCS também emprega um estado de presença do usuário, como "Não incomodar", bem como as horas de trabalho de calendário e o nível de permissão fornecido ao chamador, a fim de tomar decisões sobre o roteamento – se a chamada deverá ser encaminhada para o usuário ou se deverá ser enviada para o correio de voz.
Os números de telefone exibidos em “clique para chamar” no Office Communicator são originados de três locais – dois são baseados em diretório (contatos da Lista global de endereços/Servidor do catálogo de endereços e contatos do Outlook) e o terceiro é por meio da presença. Usando a presença, os usuários têm a flexibilidade de publicar os números de telefone que desejam que outras pessoas vejam.
A presença também exerce uma parte fundamental nos vários cenários de roteamento de voz. Por exemplo, se a presença de um usuário remoto indicar Ocupado e mostrar o texto Em reunião, então a probabilidade de que o usuário atenda à chamada de voz é baixa. Nesse caso, o chamador pode preferir usar a mensagem instantânea ou email. Da mesma forma, quando a presença de um usuário remoto for Não incomodar, isso indica que são preferidos meios alternativos de comunicação.
A presença também fornece informações sobre o local de calendário e o título atual reunião do usuário e esses detalhes são publicados para usuários no recipiente da equipe. A presença oferece informações sobre o ponto de extremidade preferido para determinado recurso e é usada para eleger um ponto de extremidade que realizará uma ação padrão. Por exemplo, a publicação de dados do calendário (que é essencialmente o mesmo para todos os pontos de extremidade) será feita somente por um ponto de extremidade preferido do recurso de calendário. O OCS tem a lógica de eleger o ponto de extremidade preferido.
A Figura 3 destaca os vários recursos que a presença oferece ao sistema do OCS. A presença, como mencionado anteriormente, é uma combinação da disponibilidade e da disposição de se comunicar. O estado Online representa o estado em que o usuário está mais disposto a se comunicar e Não incomodar é o estado de presença no qual o usuário está menos disposto a se comunicar. Exceto para Não incomodar, que precisa ser definido manualmente, todos os outros estados são automaticamente capturados pelo Communicator com base nas várias condições, como se o usuário está em uma reunião (ocupado) ou está ausente do computador (inativo, então ausente), como mostra a Figura 4.
Figure 3 Como as informações de presença são definidas (Close Figure 3)

Recursos | Origem
Disponibilidade e disposição (Online, Offline, Ausente, Ocupado, Não incomodar) | Automático. Com base no status de reunião, status de telefone e assim por diante. Também pode ser definido manualmente.
Estado de calendário (Em reunião, Local da reunião) | Automático. Com base na preferência do usuário.
Recursos do dispositivo (permissão para mensagens instantâneas) | Automático. Com base no dispositivo MPOP.
Números de telefone | Automático. Com base na preferência do usuário.
Ponto de extremidade mais ativo | Automático. Com base na atividade do usuário.
Observação | Manual. Substituído pela Notificação de ausência temporária.
Notificação de ausência temporária | Automático. Com base no calendário.
Horário de trabalho | Automático. Com base nos dados de tempo livre/ocupado.
Local | Manual. Com base na seleção do usuário.
Figura 4 A presença é uma combinação da disponibilidade e da disposição
Figura 4 A presença é uma combinação da disponibilidade e da disposição
Observe que a disponibilidade pode ser acionada por vários dispositivos diferentes aos quais o usuário está atualmente conectado. Como há vários dispositivos para o mesmo usuário e cada dispositivo publica informações de presença e dados do usuário do dispositivo, há necessidade de uma lógica de agregação que apresente uma exibição para os observadores. O OCS tem essa lógica de agregação, que computa a presença com base em vários parâmetros, dispositivos e entradas que são recebidos pelo sistema de presença.
Antes de nos aprofundarmos na agregação, é válido saber como as informações agregadas são publicadas para os usuários. O OCS 2007 introduziu o conceito de recipientes, que de alguma forma é análogo aos níveis de acesso associados aos círculos sociais. Cada recipiente fornece uma quantidade diferente de informações e as pessoas que são adicionadas a um recipiente específico têm acesso somente a informações disponibilizadas a esse recipiente. Cada pessoa na lista de contatos do usuário precisa estar presente em um dos recipientes disponíveis. O Office Communicator permite que o usuário atribua pessoas a recipientes ou os mova para diferentes recipientes com base no nível de relacionamento. O Office Communicator usa um método heurístico inteligente para a seleção do recipiente padrão (relacionado na Figura 5) automaticamente.
Figure 5 Recipientes de presença (Close Figure 5)

Recipiente | Objetivo
Bloqueado | Bloqueia as informações de presença. Não são permitidas chamadas de usuários bloqueados. No entanto, os usuários bloqueados podem ver as informações de nome e endereço de email.
Público | Fornece nome, cargo, empresa, endereço de email e disponibilidade limitada.
Empresa | Fornece as informações de contato comercial, programação básica e disponibilidade.
Equipe | Fornece números de telefone comercial e celular, programação, disponibilidade e podem interromper o usuário quando ele estiver no estado Não incomodar.
Pessoal | Permite a visualização de todas as informações de contato publicadas, incluindo números de telefone residencial e celular.
A agregação de presença no OCS determina a presença correta do usuário com base em vários estados de presença que os dispositivos relatam ao servidor. A Figura 6 ilustra como a presença é agregada a partir de uma variedade de fontes. Observe que algumas informações, como o estado de presença e a atividade do usuário, são enviadas por meio do mecanismo de agregação de presença do OCS antes que as informações sejam disponibilizadas nos recipientes e, outras informações, como detalhes de contato, são adicionadas pelos pontos de extremidades do cliente aos respectivos recipientes. O recipiente bloqueado está faltando porque não há outras informações além das informações sobre a associação publicadas nesse recipiente.
Figura 6 Agregação de presença e publicação
Figura 6 Agregação de presença e publicação
No sistema do OCS, é estabelecido um relacionamento de presença quando um usuário adiciona outro usuário à lista de contatos (lista de amigos). Mas o sistema do OCS também permite que você veja a presença de outros usuários no diretório corporativo sem precisar adicioná-los individualmente aos seus contatos.
A forma mais simples de obter a presença de alguém é pesquisar por alguém no Office Communicator. Isso gera uma consulta simples no servidor e não efetua inscrição nas notificações do servidor sobre as alterações de status de presença dos usuários remotos. No entanto, quando um usuário adiciona outro usuário em sua lista de amigos, ele se inscreve para notificações sobre as alterações de status de presença, de forma que o OCS envie alertas automaticamente sempre que houver uma alteração.

Mensagens instantâneas e áudio
As mensagens instantâneas aproveitam os recursos de registro e presença. No sistema do OCS, as mensagens percorrem ponto a ponto e o servidor do OCS é executado como um proxy que faz os traslados das mensagens entre os clientes do Office Communicator.
A primeira mensagem que um usuário iniciar para outro usuário será importante. Ela estabelece a sessão, na linguagem do SIP. Parte do estabelecimento da sessão é localizar o cliente MPOP correto a partir dos clientes registrados e é aí que o OCS exerce uma importante função como proxy. Assim que o usuário aceitar a sessão de mensagem instantânea de entrada ou se um dos pontos de extremidade MPOP do usuário for automaticamente aceito, então as mensagens subseqüentes percorreram perfeitamente de extremidade a extremidade sem requerer que o OCS localize um cliente apropriado.
Os usuários podem deixar suas janelas de conversa de mensagem instantânea abertas em seus desktops e o Office Communicator 2007 encerrará a sessão de SIP se não houver atividade em um intervalo de 10 minutos (embora a janela de mensagem instantânea permaneça aberta). Qualquer uma das partes também poderá encerrar a sessão de mensagem instantânea. Sempre que uma sessão de mensagem instantânea for encerrada, o Office Communicator 2007 criará automaticamente um item de histórico para a conversa, que registrará toda a conversa na pasta de histórico de conversas do Outlook. Essa é uma pasta especial criada no Outlook pelo Office Communicator. Esse recurso de registro por parte do cliente é opcional e, por padrão, está desativado. O histórico de conversas é usado pelo Office Communicator ao reiniciar uma conversa com o mesmo usuário; portanto, os usuários que ativarem esse recurso terão uma melhor experiência para continuar a conversa de mensagem instantânea depois que a janela de mensagem instantânea for encerrada.
Observe que as construções de mensagem instantânea apresentadas aqui para bifurcação e MPOP aplicam-se muito mais ao cenário de voz. Em vez de um convite contendo uma descrição da sessão de mensagem instantânea, ele deveria ter uma descrição da sessão de voz indicando os recursos de áudio. O OCS deveria aplicar a bifurcação à chamada de voz a todos os pontos de extremidade, da mesma forma que se aplica à mensagem instantânea.
A sinalização de voz é derivada em grande parte dos conceitos de mensagem instantânea, mas introduz a necessidade de gerenciamento de mídia. Pretendo abordar isso em mais detalhes em um artigo futuro.

Rajesh Ramanathan ele trabalhou por 14 anos na área de comunicações e atualmente trabalha como gerente-chefe de programa na equipe do Office Communicator. Entre em contato com ele pelo email rajeshra@microsoft.com.


 Office Communications Server: Planeje sua implanta&#231;&#227;o de voz do OCS 2007
Office Communications Server Jochen Kunert and Rui Maximo

Planeje sua implantação de voz do OCS 2007
Visão geral:
  • Cenários de integração de telefonia
  • Configuração do Office Communications Server
  • Usuários, planos de numeração e rotas

O Microsoft Office Communications Server (OCS) 2007 é um produto empresarial que integra a mídia de comunicação em tempo real com o reconhecimento de presença de usuário, incluindo conferência Web
(compartilhando dados, áudio e vídeo), mensagens instantâneas e conversas de áudio/vídeo. A integração do OCS 2007 com um sistema PBX existente pode ser um desafio. O Office Communications Server 2007 não foi desenvolvido para ser um PBX porque os operadores de informações de hoje em dia utilizam uma variedade de comunicações de mídia – email, mensagens instantâneas, telefone e correio de voz – no seu fluxo de trabalho diário, enquanto os sistemas PBX fornecem somente chamadas telefônicas.
Para fornecer a flexibilidade que os administradores precisam para criar a estratégia de integração de telefonia de empresa ou individual ideal, o Office Communications Server 2007 fornece três cenários de configuração para a integração com ambientes de telefonia existentes. Esses cenários são: Controle de Chamada Remota, Enterprise Voice e Enterprise Voice com integração PBX.
Este artigo tem foco nas considerações de planejamento para uma implantação de telefonia do OCS 2007, que pode precisar ser integrada com um sistema de telefonia existente. Essas informações serão especialmente interessantes para arquitetos de sistemas e administradores de TI e telefonia. Além disso, forneceremos uma visão geral de outros cenários, mas o nosso foco será o Office Communications Server 2007 Enterprise Voice.

RCC
Recursos adicionais do OCS
  • Pro LCS: Administração do Live Communications Server
  • Integrando a Telefonia ao Office Communications Server 2007
  • Guia de implantação e planejamento do Enterprise Voice

Em um cenário de Controle de Chamada Remota (RCC), os usuários precisam de um telefone de mesa PBX, IP-PBX ou TDM (Time-Division Multiplexing, Multiplexação de divisão do tempo). A partir de seu cliente Office Communicator 2007, eles podem fazer e responder chamadas no telefone de mesa sem precisar discar no teclado do telefone ou tirar o fone do gancho. Embora os usuários possam controlar seu telefone de mesa usando o Office Communicator 2007, o áudio ainda é gerenciado pelo sistema PBX e não será convertido em uma chamada VoIP (Voice-over-IP). Mesmo que o Office Communicator 2007 possa controlar o telefone de mesa, as chamadas ainda podem ser feitas e respondidas através do telefone PBX, independentemente se o Office Communicator 2007 está ou não em execução.
Para habilitar o RCC no Office Communicator 2007 e no OCS 2007, você deve implantar um gateway de protocolo SIP/CSTA (Computer Supported Telephony Application), além de habilitar o seu ambiente Office Communications Server 2007 para RCC. O gateway de SIP/CSTA deve interoperar com o tipo de sistema PBX que você usa e deve ser compatível com o OCS 2007, pois ele liga os dois sistemas. Para controlar o telefone PBX, o Office Communicator 2007 utiliza o protocolo CSTA. Esse protocolo define um Esquema XML para fazer a interface com os comutadores do telefone (PBX), conforme descrito no padrão 269 da ECMA (European Computer Manufacturers Association), que você pode acessar em www.ecma-international.org/publications/standards/Ecma-269.htm.
O Office Communicator 2007 envia comandos CSTA para controlar o telefone PBX como cargas SIP que são roteadas pelo Office Communications Server 2007 para o gateway de SIP/CSTA. O Office Communications Server 2007 não precisa compreender o CSTA. Ele apenas precisa saber como roteá-lo. O gateway de SIP/CSTA então converte os comandos no protocolo nativo usado pelo PBX. O processo é ilustrado na Figura 1.
Figura 1 Cenário de integração de RCC
Figura 1 Cenário de integração de RCC
Habilitar o RCC requer cinco etapas. A primeira etapa é configurar o gateway de SIP/CSTA para que se comunique com o seu PBX. Em seguida, configure o OCS 2007 para rotear solicitações de CSTA para o gateway de SIP/CSTA. A terceira etapa é configurar os usuários para RCC. A quarta etapa é configurar o Office Communicator 2007. A quinta etapa é definir as regras de normalização do OCS 2007, que também são utilizadas para a normalização de número telefônico do Catálogo de endereços e são diferentes das regras de normalização de número telefônico que estão sendo usadas em combinação com o Enterprise Voice.

Enterprise Voice
Quando um usuário é habilitado para o Enterprise Voice, o Office Communicator 2007 ou o Office Communicator Phone Edition se torna seu principal telefone, em vez de seu telefone PBX. O Office Communicator 2007 terá um único número de telefone atribuído a ele. (Para fins de teste, o telefone PBX existente pode ser encaminhado para uma nova extensão fornecida ao Office Communicator 2007.) O Office Communicator 2007, em combinação com um dispositivo de áudio USB recomendado, administrará o controle de chamada (ou sinalização) e a mídia (áudio e vídeo).
Nesse cenário, o Office Communications Server 2007 roteia chamadas entre os pontos de extremidade do Office Communicator 2007 na rede IP (chamadas IP-IP) e roteia chamadas para a Rede telefônica pública comutada (PSTN)/PBX (chamadas IP-PSTN). O OCS 2007 impõe restrições de discagem em chamadas roteadas para PSTN.
Para conectar o seu ambiente Office Communications Server 2007 a um PBX ou PSTN, você deve implantar um gateway de mídia, também conhecido como um gateway de SIP/PSTN ou IP/PSTN. O gateway de mídia deve ser emparelhado com um servidor de mediação (uma função de servidor do OCS 2007) para que se conecte ao seu ambiente Office Communications Server 2007, como mostrado na Figura 2. O servidor de mediação e o gateway de mídia associado devem ser instalados no mesmo local físico.
Figura 2 Cenário de integração do Enterprise Voice com PSTN ou um PBX existente
Figura 2 Cenário de integração do Enterprise Voice com PSTN ou um PBX existente
O servidor de mediação torna possível a conexão de gateways de mídia que são compatíveis com implementações padrão e até mesmo não protegidas de SIP com o Office Communications Server 2007, pois o OCS 2007 permite somente comunicação autenticada e criptografada. Outra tarefa do servidor de mediação é gerenciar conversões de codec entre os codecs padrão (G.711, G.723 e assim por diante) e o codec de áudio em tempo real da Microsoft. Para obter uma lista de gateways de mídia compatíveis com o Office Communications Server 2007, consulte as parcerias estratégicas de hardware em technet.microsoft.com/bb735838.
É possível conectar os gateways de mídia diretamente à PSTN ou a uma conexão de tronco de PRI (Primary Rate Interface, interface de taxa primária) de um PBX existente. A Figure 2 mostra possíveis cenários de integração para o cenário do Enterprise Voice com PSTN e PBX existente. Um Diretor (geralmente um Servidor Standard Edition do Office Communications Server) não será necessário para uma implantação do Enterprise Voice. Entretanto, isso é recomendado.
Habilitar o Enterprise Voice requer quatro etapas. A primeira etapa é implantar e configurar os gateways de mídia. Como esse é um produto parceiro da Microsoft, você deve consultar a documentação do fornecedor, pois cada gateway de mídia tem diferentes etapas de implantação.
Em seguida, implante um servidor de mediação para cada gateway de mídia. Nessa etapa, você deve configurar um placa de rede do servidor de mediação para enviar e receber tráfego do gateway de mídia e configurar a outra placa de rede do servidor de mediação para enviar e receber tráfego de um Office Communications Server 2007 (geralmente, um Diretor em uma implantação Enterprise Edition). A menos que o seu gateway de mídia seja um gateway avançado, ele ainda precisará de assistência de uma função de servidor de mediação do OCS 2007, a fim de interoperar com a sua infra-estrutura do OCS 2007 Enterprise Voice.
A terceira etapa é definir um plano de numeração. Isso envolve definir diretivas de voz, rotas de telefone e perfis de local.
Depois disso, configure os usuários do Enterprise Voice. Além disso, os usuários devem estar habilitados para o Enterprise Voice para que possam fazer e receber chamadas a partir de PBX ou PSTN. Isso requer a atribuição de números de telefone exclusivos para cada usuário.

Enterprise Voice com integração PBX
Essa configuração é uma extensão da configuração do Enterprise Voice. A diferença é que o telefone PBX do usuário é sincronizado com o cliente Office Communicator do usuário. A configuração é semelhante ao cenário do Enterprise Voice conectando-se à PSTN via um PBX, como mostra a Figura 2. No entanto, nesse caso, em vez de substituir o telefone PBX do usuário por um cliente Office Communicator 2007, o Office Communicator 2007 e o telefone PBX existente utilizarão o mesmo número de telefone.
Se um chamador discar a extensão do usuário de outro telefone PBX ou de um telefone PSTN, o sistema PBX bifurcará a chamada para o telefone PBX do usuário e para o cliente Office Communicator 2007 do usuário por meio do Office Communications Server 2007. O cliente Office Communicator 2007 do usuário e o telefone PBX chamarão simultaneamente quando for recebida uma chamada. Inversamente, o Office Communications Server bifurcará chamadas iniciadas do OCS 2007 para o PBX por meio do gateway de mídia. Esse cenário não é possível ao usar o Office Communicator Phone Edition. Essa configuração requer que esse correio de voz seja gerenciado pelo sistema de correio de voz de PBX. O Exchange Server 2007 Unified Messaging não pode ser usado como uma solução de correio de voz para tais usuários.
Habilitar o Enterprise Voice com integração PBX envolve as mesmas etapas da implantação do Enterprise Voice mas com três etapas adicionais. Na primeira etapa adicional, o gateway de mídia deve ser conectado diretamente ao PBX. Em seguida, o PBX deve ser configurado para compatibilidade com esse cenário. (Isso pode exigir uma atualização de software do PBX, dependendo do seu fornecedor.) Finalmente, os usuários devem ser habilitados para integração com PBX.
A Microsoft está trabalhando para fornecer suporte à conexão com o servidor de mediação diretamente ao IP PBX sem a intermediação de um gateway de mídia. Visite technet.microsoft.com/bb735838 para obter as informações mais recentes sobre esse tópico.

Configuração do Office Communications Server
A funcionalidade do Enterprise Voice é administrada por serviços em execução no Office Communications Server 2007 Enterprise Edition e no Office Communications Server 2007 Standard Edition. A Figura 3 descreve os serviços que fornecem a funcionalidade do Enterprise Voice para rotear chamadas recebidas e feitas.
Figure 3 Serviços do Enterprise Voice (Close Figure 3)

Serviço | Descrição
Serviço de conversão | Aplica regras de normalização com base no perfil local ou contexto do telefone.
Serviços de usuário | Executa a pesquisa por número reverso no número de telefone de destino.
Componente de roteamento de entrada | Aplica as preferências de chamada do usuário de destino.
Unificação de Mensagens do Exchange | Encaminha a solicitação para o correio de voz, conforme necessário.
Componente de roteamento de saída | Determina a rota ideal com base na diretiva de usuário e URI.
A Figura 4 ilustra como cada um desses componentes opera em chamadas recebidas à medida que elas são roteadas pelo OCS 2007 para uma chamada PC para PC. As chamadas recebidas podem se originar de um ponto de extremidade conectado, como Office Communicator 2007 ou Office Communicator Phone Edition, ou de um servidor de mediação oriundo de PSTN/PBX (chamada PSTN-SIP). As chamadas feitas com origem de um dos pontos de extremidade do cliente Office Communications Server 2007 do chamador, como o Office Communicator 2007, são enviadas para o Servidor Standard Edition ou pool Enterprise no qual o usuário está hospedado. Isso é conhecido como o pool inicial de usuário.
Figura 4 Interação de serviços relacionados do Enterprise Voice no OCS servidores front-end
Figura 4 Interação de serviços relacionados do Enterprise Voice no OCS servidores front-end
Nesse ponto, o Office Communications Server 2007 processa a chamada para definir para onde roteá-la. Esse próximo salto pode ser o pool inicial da parte chamada, um servidor de mediação, ou o Microsoft® Exchange Server 2007 Unified Messaging (consulte a Figura 5). Se a chamada for roteada para outro pool inicial, o OCS 2007 envia a chamada para todos os pontos de extremidade ativos da parte chamada. O Office Communicator 2007 ou o Office Communicator Phone Edition da parte chamada tocará e uma notificação de janela pop-up será exibida no dispositivo.
Figura 5 Roteamento de chamada
Figura 5 Roteamento de chamada
Se a chamada for roteada para um servidor de mediação, o servidor será configurado para rotear para um gateway de mídia específico. Se o gateway de mídia for conectado diretamente a um PBX, a chamada será então roteada pelo PBX para um telefone de mesa ou para a PSTN. No entanto, se o gateway de mídia for conectado diretamente a uma PSTN, a chamada irá para a PSTN.
Se o próximo salto for para o Exchange Server 2007 Unified Messaging, o chamador poderá deixar uma mensagem. O correio de voz está disponível independentemente de se a parte chamada estiver conectada no Office Communications Server 2007.
Quando a parte chamada responder, o áudio será enviado diretamente a partir do Office Communicator 2007 ou do Office Communicator Phone Edition da parte chamando para o Office Communicator 2007 ou o Office Communicator Phone Edition da parte chamada em uma chamada IP para IP. Se a parte chamando estiver usando um telefone PBX ou PSTN, o servidor de mediação enviará o tráfego de áudio diretamente para o Office Communicator 2007 ou para o Office Communicator Phone Edition da parte chamada em uma chamada IP para PSTN. O OCS 2007 administrará somente a sinalização da chamada, que é o motivo pelo qual o áudio e o vídeo vão diretamente entre os pontos de extremidade e não são roteados pelo OCS 2007.

Configuração de usuários
Os usuários habilitados para o Enterprise Voice devem recebem números telefônicos que são exclusivos na organização. Essa configuração é realizada no Active Directory®. Isso é diferente da maioria dos sistemas de telefonia nos quais é atribuído um número de telefone ao telefone. A vantagem desse design é que os usuários podem converter qualquer computador executando o Office Communicator 2007 em seu telefone comercial ao conectar-se no OCS 2007 a partir do cliente. Esse recurso de portabilidade pode ser interessante para funcionários remotos ou em campo.
O número de telefone do usuário é especificado no formato E.164 no Active Directory. Esse formato define o plano de numeração de telecomunicação pública internacional, um esquema de numeração que representa exclusivamente números de telefone de forma inequívoca. O formato E.164 especifica o número de telefone nesse formato:
+<country code><area code><phone number>
Um usuário habilitado para o Enterprise Voice tem duas representações exclusivas: URI de SIP e número de telefone E.164. Quando um número de telefone for chamado, o Office Communications Server resolve a representação E.164 do número de telefone (+14255551212) para o URI de SIP do usuário (joe@contoso.com). O Office Communications Server 2007 então roteia a chamada com base no URI do SIP da parte chamada. Se o número de telefone não puder ser resolvido para um URI de SPI, o OCS 2007 roteará a chamada para PBX/PSTN por meio de um servidor de mediação.
Quando planejar uma implantação do Enterprise Voice onde cada usuário do Office Communications Server deve receber um número de telefone exclusivo, você precisará considerar o seu sistema de telefone existente. Se você se conectar à PSTN diretamente por meio de um gateway de mídia, provavelmente terá um bloco de número inteiro com extensões de dois ou três dígitos de números DID (Direct-Inward-Dialing) que podem ser distribuídos para usuários do OCS 2007. Se você se conectar à PSTN por meio de um PBX, provavelmente terá um bloco de números DID fornecidos pelo PBX para atribuir a usuários do OCS 2007.

Planos de numeração
Mesmo que os números telefônicos com formatação E.164 forneçam uma representação exclusiva, isso não é um modo conveniente para a discagem de números. Também não é possível inserir um número nesse formato no Office Communicator Phone Edition ou em telefones PBX/PSTN padrão. Como você especifica um caractere + usando o teclado de 10 dígitos? Os usuários estão acostumados a discar extensões mais curtas, que podem ser exclusivas em um local específico mas talvez não abrangendo toda a empresa. Portanto, é necessário especificar as regras de conversão para convertê-las no formato E.164.
O administrador deve definir os perfis de local que especificam as regras de normalização para executar essas conversões de número. Depois que o número de telefone for ampliado pelo cliente (Office Communicator 2007 ou Communicator Phone Edition) ou pelo serviço de conversão do Office Communications Server 2007 em um formato E.164, os serviços de usuário podem executar uma pesquisa por número reverso e corresponder o número E.164 ao URI de SIP correspondente. As regras de normalização definidas em um perfil local usam expressões regulares para executar a conversão se uma correspondência for detectada. Por exemplo, se 1234 for discado, uma normalização que corresponde a qualquer padrão de quatro dígitos a ser convertido em +1425555{quatro dígitos} converteria 1234 em +1425551234. Assim, os perfis de local permitem que os usuários mantenham os mesmos hábitos de discagem com os quais estão acostumados.
Os administradores podem atribuir perfis de local a usuários nas seguintes três formas:
  • Definir o perfil de local a usuários usando o Office Communicator 2007 por meio da Diretiva de grupo.
  • Permitir que os usuários selecionem um perfil de local a partir do Office Communicator Phone Edition.
  • Atribuir um perfil de local ao pool inicial. Os usuários hospedados nesse pool serão automaticamente atribuídos a esse perfil de local.
A definição de um plano de numeração envolve criar diretivas de voz, rotas de telefone e perfis de local com regras de normalização. As diretivas de voz definem o tipo de acesso de chamada ao qual os usuários têm permissão. O Office Communications Server 2007 determina como rotear as chamadas para PBX/PSTN por meio de rotas de telefone. Como os números telefônicos podem ser discados de diversas formas, as regras de normalização de um perfil de local definem como converter o número de telefone discado no formato E.164, que pode então ser roteado.
Cada usuário habilitado para o Enterprise Voice é associado pelo administrador a uma diretiva de voz. Uma diretiva de voz define os privilégios de chamada atribuídos a um usuário. Os privilégios de chamada determinam quais rotas o usuário tem permissão de usar e, portanto, quais números ele pode discar. Cada usuário deve estar associado a uma única diretiva de voz. O número de diretivas disponível é criado pelo administrador.
Cada diretiva de voz contém uma configuração para permitir ou negar que os usuários habilitem a campainha simultânea e uma lista ordenada de usos do telefone. A diretiva de voz, semelhante à diretiva de reunião, é um contêiner lógico de configurações definidas como um documento XML armazenado no Active Directory. A importância desse design é que ele pode ser ampliado em versões futuras do OCS 2007 para oferecer suporte a configurações de diretiva adicionais, sem exigir uma extensão de esquema do Active Directory. Por exemplo, se uma diretiva de voz não for associada a quaisquer usos de telefone, isso terá o efeito de impedir que usuários atribuídos a essa diretiva façam quaisquer chamadas de saída para PBX/PSTN. Tais usuários poderiam fazer somente chamadas de IP para IP.

Uso do telefone e rotas
O uso do telefone define os privilégios de roteamento do telefone aos quais os usuários têm permissão. Um uso de telefone é um conjunto de rotas de telefone. Ele consiste em uma cadeia de caracteres que deve ser uma palavra-chave exclusiva, o que significa que nem outro uso de telefone poderá ter o mesmo nome. Os administradores podem criar quantos usos desejarem.
Embora uma diretiva de voz possa ser diretamente associada a uma rota ou conjunto de rotas, em vez de usos de telefone, a palavra-chave de uso do telefone é uma abstração para manter a associação entre as diretivas e as rotas. Se as diretivas forem diretamente associadas a rotas, removendo efetivamente o conceito de usos de telefone, e o administrador tiver modificado o nome de uma rota, então cada diretiva associada a essa rota precisaria ser atualizada. Ao usar um uso de telefone, que é um atributo de uma diretiva e uma rota para criar a associação entre a diretiva e a rota, a relação entre a diretiva e a rota será preservada mesmo se o nome da rota for alterado.
Uma rota contém um padrão de número telefônico e uma lista de servidores de mediação conectados aos gateways de mídia. Uma rota deve ser atribuída a pelo menos um uso de telefone. Essa associação entre o padrão e os gateways especifica como rotear os números de telefone que correspondem a esse padrão específico.
O padrão especifica um intervalo de números de telefone aos quais ele pode corresponder. Ele é definido como uma expressão regular que pode incluir e excluir números de telefone. A ferramenta Enterprise Voice Route Helper é incluída para auxiliar a criar essas expressões regulares mais facilmente. Conseqüentemente, se o número de telefone discado corresponder ao padrão da expressão regular da rota, então a chamada será roteada para um dos gateways definidos na rota.
Mais de um servidor de mediação (e, portanto, o gateway de mídia) pode ser relacionado em uma única rota. O Office Communications Server 2007 roteia a chamada para os servidores de mediação em rodízio como uma forma de equilibrar o tráfego nos gateways. Se um gateway falhar ou for retirado de serviço para manutenção, o servidor de mediação correspondente enviará de volta uma resposta para o Office Communications Server 2007, que tentará imediatamente rotear a chamada para outro servidor de mediação (e, portanto, um gateway de mídia diferente) na lista da rota.
Depois de 10 tentativas de rotear as chamadas para um gateway de mídia com falha, o Office Communications Server 2007 subseqüentemente diminuirá o tráfego para esse gateway de mídia até que ele se torne responsivo novamente. Se o gateway de mídia continuar falhando em responder depois de 10 tentativas adicionais, o Office Communications Server 2007 irá interromper o roteamento das chamadas para esse gateway de mídia até que ele se torne responsivo novamente.
A lista de gateways de mídia definida na rota do telefone é descrita pelo nome de domínio e número de porta totalmente qualificados do gateway. Se o número de telefone não corresponder ao padrão da expressão regular, então a próxima rota associada ao uso do telefone atribuído ao usuário será verificada até que seja encontrada uma correspondência. Se não for detectada correspondência, a chamada não poderá ser roteada e falhará em atingir seu destino. O usuário receberá uma notificação de que a chamada não pôde ser concluída.

Próximas etapas
O Office Communications Server 2007 fornece três níveis de integração de telefonia. Ao planejar a sua implantação de telefonia, você precisará determinar qual nível atender melhor às suas atuais e futuras necessidades comerciais de telefonia. Depois de concluir isso, você poderá planejar a sua implantação. Um aspecto importante do seu planejamento é definir um número de planejamento para a implantação do seu Office Communications Server Enterprise Voice. Isso deve ser considerado com cautela.
Consulte a barra lateral "Recursos adicionais do OCS 2007" para saber mais sobre o Office Communications Server 2007 Enterprise Voice e as tecnologias relacionadas.

Jochen Kunert tem 10 anos de experiência na indústria de telecomunicações e agora está trabalhando como gerente de programa sênior no Grupo de comunicações do Office na Microsoft. Ele é co-autor do livro que será lançado em breve, Microsoft Office Communications Server 2007 Resource Kit. Você pode contatá-lo pelo email jkunert@microsoft.com.
Rui Maximo ele é um veterano com experiência de 14 anos no setor de TI e co-autor de dois livros, Pro LCS: Live Communications Server Administration e Microsoft Office Communications Server 2007 Resource Kit. Entre em contato com ele pelo email ruim@ruimaximo.com.


 Computa&#231;&#227;o de alto desempenho: Uma introdu&#231;&#227;o ao Windows Compute Cluster Server
Computação de alto desempenho John Kelbley and Doug Lindsey

Uma introdução ao Windows Compute Cluster Server
Visão geral:
  • Usando clusters para resolver problemas complexos
  • Requisitos gerais para clusters computacionais
  • Configurando um cluster de computadores baseado no Windows
  • Executando comandos remotamente

O HPC (High Performance Computing) refere-se a uma ramificação de computação aplicada que se concentra, em sua maioria, na solução de problemas intensos de computação. Anos atrás, o HPC (na época mais comumente chamado de "supercomputação") era dominado por
sistemas especializados grandes (e caros) encontrados principalmente em centros de pesquisa. No entanto, conforme o poder computacional dos pequenos sistemas aumentava, a proporção custo/desempenho se alterou e as cargas de trabalho computacionais moveram-se para sistemas da classe de PCs.
Muitos problemas intensos de computação podem ser resolvidos completando cálculos em paralelo; o que significa que um cálculo ou processo específico pode não depender da saída de outro para ser concluído. Nesses casos, problemas grandes podem tirar proveito de vários sistemas menores (nós) agrupados em clusters computacionais. Aqui estão alguns exemplos dos tipos de aplicativos que podem tirar proveito dos clusters computacionais:
  • Modelos financeiros—um algoritmo ou fórmula é executado milhares de vezes, cada uma com entradas diferentes.
  • Engenharia—simular efeitos de partes individuais, aplicar texturas a modelos.
  • Animação computadorizada—aplicar texturas e efeitos de iluminação a cada quadro de um filme.
Os clusters computacionais fornecem uma maneira econômica de resolve problemas complexos em um pequeno período de tempo. Como você verá aqui, a Microsoft fornece funcionalidade e suporte a clusters de computadores principais com o Windows® Compute Cluster Server 2003.
É importante compreender que um cluster computacional é diferente de um cluster de disponibilidade (failover). Talvez você conheça os clusters de disponibilidade do Exchange, SQL Server® ou outros aplicativos no Windows Server® 2003. Eles geralmente aproveitam o armazenamento compartilhado para maximizar o tempo de atividade do aplicativo. A intenção dos clusters computacionais não é retomar o trabalho de outro sistema no caso de uma paralisação, mas permitir a todos os nós o funcionamento de maneira coordenada.

Requisitos gerais para um cluster computacional
Recursos HCP
  • Comunidade HPC do Windows
  • Computação de alto desempenho com o WCCS 2003
  • Visão geral da computação de 64 bits da Microsoft
  • Página inicial dos Servidores Microsoft
  • Compute Cluster Server TechCenter
  • Guia passo a passo para a instalação, configuração e ajuste da implantação de um cluster de computadores de alto desempenho

Os sistemas HPC modernos compartilham alguns elementos principais que facilitam o processamento de cargas de trabalho. Para começar, é necessário mais de um sistema. É necessário também um agendador para coordenar as atribuições de trabalho nos nós. O agendador é executado no nó encarregado (o nó principal) e identifica os recursos disponíveis, atribuindo e distribuindo tarefas e rastreando o status geral dos trabalhos. Ele é o coordenador de recursos dentro do cluster de sistemas, bem como o ponto onde os usuários e administradores enviam trabalhos para processamento.
Os clusters necessitam de meios de comunicação entre nós. Dependendo do tipo de trabalho, os nós podem necessitar de interconexões de alta velocidade e baixa latência para passar mensagens entre eles para coordenar o processamento. Cada nó de computadores e o nó principal devem estar conectados, no mínimo, a uma rede em comum.
Grandes números de sistemas interconectados trabalhando juntos para resolver problemas complexos necessitam também de uma quantidade razoável de cuidado e alimentação. Processos e ferramentas direcionados para provisionamento, monitoramento, gerenciamento e manutenção de dúzias de centenas ou milhares de sistemas devem assegurar um ambiente consistente e estável.
Por fim, e o mais importante, os aplicativos que podem explorar a capacidade de processamento paralelo de um cluster computacional devem estar disponíveis. Sem os aplicativos capazes de dividir os trabalhos para que possam ser processados em vários computadores ou ferramentas de desenvolvimento que incluem suporte a "depuração paralela", um cluster faria pouco mais do que aquecer a sua sala de computadores.

Clustering baseado em servidores do Windows
Em 2006, a Microsoft apresentou o Windows Server 2003 Compute Cluster Edition (CCE) e o Windows Compute Cluster Server 2003 (WCCS) para atender aos requisitos de uma grande variedade de aplicativos HPC. O CCE e o WCCS são baseados no mesmo Windows Server 2003 que você já conhece. O CCE é uma versão do Windows Server 2003 licenciada para uso com aplicativos HPC. O WCCS é idêntico ao CCE com a adição do Microsoft® Compute Cluster Pack (CCP). Isso significa que é possível implantar, gerenciar, monitorar e manter um cluster baseado no Windows Server usando as mesmas ferramentas que você já usa para gerenciar sistemas do Windows Server 2003 existentes.
Um ponto chave a ser observado é que o CCE e o WCCS são somente para x64—não há uma versão 32-bit (x86) desses produtos. Os requisitos de hardware para o CCE com o WCCS são idênticos àqueles do Windows Server 2003 Standard x64 Edition. Além do suporte a hardware de alto desempenho (arquitetura de 64 bits), os produtos incluem suporte a RDMA (Remote Direct Memory Access) para interconexões de alto desempenho (Gigabit Ethernet, InfiniBand, Myrinet entre outras).

Compute Cluster Pack
Conforme mencionado anteriormente, os clusters computacionais têm alguns requisitos básicos que podem ser atendidos por meio da instalação do Compute Cluster Pack. O CCP é um pacote de instalação autônomo que inclui:
  • Agendador de trabalhos integrado
  • Suporte a MPI (Messaging Passing Interface) para o padrão da indústria MPICH2
  • Gerenciamento de recursos de cluster e ferramentas de usuário
O CCP é o diferenciador principal entre o CCE e o WCCS. Você deve estar imaginando o porquê de, se os clusters computacionais necessitam desses componentes, eles estarem incluídos somente no WCCS e não no CCE. A resposta é que algumas soluções aproveitam agendadores de trabalho diferentes ou MPIs especializadas (ou não necessitam de suporte MPI) e simplesmente necessitam de uma grande plataforma para execução—nomeadamente o Windows Server 2003. Como o CCP é um pacote autônomo, é possível instalá-lo em outras versões x64 do Windows Server 2003 (CCE, Standard, Standard R2, Enterprise e Enterprise R2).

Detalhes práticos
O WCCS tira proveito dos conceitos básicos principais do Windows para simplificar o gerenciamento e operação de clusters baseados no Windows, incluindo o Active Directory® e o RIS (Remote Installation Services). O Compute Cluster Server usa o Active Director para gerenciar a segurança de maneira transparente. Com o Active Directory, um usuário pode enviar um trabalho para o nó principal—usando um conjunto único de credenciais—que pode ser executado em centenas de nós de servidor. Quando os trabalhos são executados em um ou mais nós de computadores, eles são executados no contexto das credenciais de usuário fornecidas no envio do trabalho e são armazenados em cache de maneira segura a partir de então. O WCCS recorre ao Active Directory para fornecer essa funcionalidade de “ponto único de logon”. Um benefício adicional à presença do Active Directory no ambiente é que a diretiva de servidor e configuração pode ser administrada de maneira central por meio da Diretiva de Grupo.
Se a sua organização de TI já implantou o Active Directory, é possível economizar um tempo e esforço administrativo significativo criado o seu cluster no domínio existente. Esse é o cenário recomendado.
Se você necessitar implantar um cluster de computadores em um ambiente onde o Active Directory não existe, a prática recomendada é implantar um ou mais controladores de domínio dedicados para hospedar o Active Directory para o cluster. Não é incomum tornar o nó principal um controlador de domínio do Active Directory, uma vez que todos os nós já têm conectividade de rede com o sistema, independente da topologia da rede. No entanto, tornar o nó principal o controlador de domínio não é recomendado para clusters de larga escala devido à carga aumentada no nó principal. As práticas comuns para a implantação e gerenciamento do Active Directory devem ser seguidas (instalação de controladores de domínio redundantes, backups adequados, boas práticas de segurança e assim por diante).

Serviço de Instalação Remota
O WCCS fornece um front-end integrado para a plataforma de implantação de imagem do Microsoft Remote Installation Service . O RIS é usado na implantação de imagens de sistema operacional do nó principal para cada um dos nós computacionais, o que significa que é possível usar o RIS para instalar novos nós de cluster rapidamente. Não é necessário fazê-lo desse modo—o RIS é integrado ao WCCS como uma conveniência. Outras tecnologias de implantação do Windows Server comuns podem também ser usadas, como o Windows Server 2003 ADS (Automated Deployment Services) ou uma instalação manual do Windows Server 2003.
Se você desejar usar o RIS, antes de instalar o CCP no seu nó principal, certifique-se de que você tem ao menos dois discos lógicos definidos. O RIS necessita de um disco separado do sistema operacional para o armazenamento de imagens de servidor. A sua partição RIS deve ter espaço livro suficiente para abrigar uma ou mais cópias completas de uma imagem do Windows Server.
Hardwares de servidor mais recentes, em especial engrenagens de rede e armazenamento, podem necessitar de drivers Plug and Play não contidos nas imagens do Window Server 2003 padrão. Nesse caso, será necessário adicionar esses drivers à imagem manualmente. O procedimento para isso está documentado online em support.microsoft.com/kb/254078.

Instalando o seu cluster
A primeira etapa é configurar o cérebro do seu cluster—o nó principal. Comece instalando uma das versões x64 do Windows Server 2003 comentadas anteriormente. Durante a instalação do sistema operacional, escolha se desejar adicionar o servidor a um domínio existente (recomendado) ou instalar o Active Directory no servidor (não recomendado para clusters de larga escala).
Depois de instalar o sistema operacional, certifique-se de ter baixado e instalado todas as correções recomendadas do Microsoft Update. Se você planeja usar o RIS para a geração de nós de computação, será necessário usar a ferramenta administrativa Gerenciamento do Computador | Gerenciamento de Disco para certificar-se de que você tem ao menos dois discos lógicos definidos. Por uma questão de espaço, não abordaremos a instalação baseada no RIS neste artigo.
Depois de fazer o login e a atualização do seu servidor com êxito, você executará o programa de configuração do CCP. A configuração do CCP instalará ou guiará você por meio do download e instalação dos seguintes arquivos obrigatórios e atualizações:
  • Hotfix do RIS (consulte go.microsoft.com/fwlink/?linkid=55167)
  • MMC (Microsoft Management Console) 3.0 (consulte go.microsoft.com/fwlink/?linkid=62400)
  • SQL Server Desktop Edition, instalado como parte do processo de instalação do nó principal do Compute Cluster Server 2003
  • Microsoft .NET Framework 2.0
O programa de configuração do CCP realiza um ótimo trabalho de avaliação da prontidão do seu sistema para a instalação. Ele informará a você quais componentes são necessários e instalados como parte do processo e instalá-los, conforme mostrado na Figura 1.
Figura 1 Componentes necessários para a instalação do CCP
Figura 1 Componentes necessários para a instalação do CCP

A lista de tarefas
Quando a configuração do CCP estiver concluída, ele iniciará o console do administrador, concentrado na Lista de tarefas. Como mostra a Figura 2, a Lista de tarefas contém vários painéis, cada um tratando de uma área diferente e listando as tarefas principais para concluir a configuração do cluster.
Figura 2 A Lista de tarefas mostra o que é necessário para configurar o seu cluster
Figura 2 A Lista de tarefas mostra o que é necessário para configurar o seu cluster
A Lista de tarefas permite a implementação de maneira fácil da arquitetura de cluster definida, incluindo a seleção da topologia da rede, processo de instalação de nós e modelo de gerenciamento de usuários. As tarefas de cada um desses painéis está listada no lado direito e cada tarefa inicia um assistente. Conclua cada tarefa em seqüência para um nó principal totalmente configurado que está pronto para implantar imagens RIS em um conjunto conhecido de nós de computadores e que pode ser administrado e acessado por um conjunto definido de usuários.
Topologia do sistema de rede O WCCS oferece suporte às cinco topologias de rede mais comuns usadas em HPC. Todos os nós de computadores e o nó principal devem compartilhar, no mínimo, uma rede em comum. As topologias incluem suporte a vários tipos de interconexões entre os nós e têm benefícios e custos separados.
A sua topologia de rede dependerá do desempenho, segurança e requisitos de implantação do seu cluster. Por exemplo, o seu aplicativo pode necessitar de uma interconexão de alta velocidade para a passagem de mensagens que você não deseja expor à sua rede corporativa. Talvez você deseje tirar proveito das capacidades de implantação automatizadas integradas e baseadas em RIS. Talvez o hardware escolhido possa acomodar somente uma única NIC ou, provavelmente, você deseja que o nó principal execute o ICS (Compartilhamento de Conexão com a Internet) para gerenciar a resolução e endereçamento de nome dos nós de computadores. O assistente "Configuração de topologia de rede de cluster" invocado da Lista de tarefas apresentará cinco topologias que geralmente têm suporte de implementações HPC comuns, bem como ajudará você a configurar as suas conexões de rede, incluindo as configurações do Windows Firewall no nó principal e nós de computadores. A Figura 3 mostra uma das topologias de rede com suporte.
Figura 3 Uma das topologias de rede com suporte WCCS
Figura 3 Uma das topologias de rede com suporte WCCS
Serviço de Instalação Remota Conforme observado anteriormente, o RIS permite a implantação automatizada de nós de cluster.
Gerenciamento de nós Você tem a capacidade de especificar os nomes das máquinas dos servidores que serão nós de computadores nesse cluster. Quando o CCP é executado em um nó, o nó principal do cluster ao qual o nó se juntará será especificado nesse momento.
Gerenciamento de usuários É possível especificar aqui quais contas ou grupos de usuários do Active Directory serão designados como administradores de sistema e quais serão designados como usuários do cluster.

Instalação de nó
A implantação de nós de computadores pode ser concluída automaticamente por meio do utilitário de administração do RIS ou usando outros métodos de implantação com suporte. Assim como o nó principal, o CCP deve ser instalado em um nó de computadores. Como mostra a Figura 4, as opções de configuração de instalação do CCP são muito mais simples para um nó de computação e consistem no seguinte:
Figura 4 Configuração do Compute Cluster Pack
Figura 4 Configuração do Compute Cluster Pack
  • Especificar se o servidor será um nó de computadores (e não um nó principal).
  • Especificar o nome do nó principal do cluster ao qual o servidor se juntará.
  • Especificar se deve ou não instalar as ferramentas administrativas e de usuário no nó de computadores.

Console do Administrador
Depois que os nós estiverem em comunicação com o seu nó principal, a maior parte das tarefas de gerenciamento e administração de todos os sistemas podem ser realizadas por meio do console do administrador, mostrado na Figura 5. O console fornece uma visão central do cluster inteiro incluindo uma lista de todos os nós associados, acesso às ações administrativas principais e outros detalhes. O painel à extrema esquerda fornece uma navegação de alto nível pelo console, incluindo acesso ao "Administrador de Cluster" que, ao ser destacado, fornece uma tela de resumo mostrando o status do cluster e estatísticas do trabalho. O acesso a todas as áreas de trabalho remotas e sessões de monitoramento do sistema podem ser acessadas a partir daqui também, mas a maior parte do tempo que você passar administrando o cluster será usando o "Gerenciamento de nós".
Figura 5 O console do administrador fornece uma visão do cluster inteiro
Figura 5 O console do administrador fornece uma visão do cluster inteiro
Você deve explorar o console do administrador por conta própria, pois ele fornece acesso às ferramentas e funções principais necessárias para administrar de maneira central o Windows e nós de cluster. Clicar uma vez em um nó de cluster no painel superior central populará várias das outras janelas, e será possível explorar funções específicas de nós.
As funções com suporte de menus acessados com o botão direito do mouse permitem a administração fácil dos nós de computadores de maneira central do Gerenciamento de Nós. É possível usar o Gerenciamento de Nós para pausar e retomar nós; aprovar ou remover nós para e do cluster; iniciar áreas de trabalho remotas, monitores de sistema ou visualizadores de eventos; ou fazer com que a bandeja do CD ejete (o que pode ser útil quando você estiver tentando identificar fisicamente uma única máquina em um cluster grande).

ClusRun legal
O recurso mais interessante dessa lista é o "Executar comando"—ou seja, a capacidade de executar qualquer comando arbitrário remotamente, como se estivesse em um prompt de comando na máquina de destino. O WCCS inclui uma versão de linha de comando do recurso de Executar comando chamada Clusrun.exe e "ClusRun" é usado para descreve as versões GUI e de linha de comando.
Os benefícios do utilitário do ClusRun não podem ser enfatizados demais—especialmente em um cluster grande. É uma grande economia de tempo para a execução de tarefas de linha de comando repetitivas e pode muitas vezes eliminar a necessidade de escrever scripts administrativos mais complexos.
Para usar esse recurso, destaque uma lista das máquinas nas quais você deseja executar o comando, clique com o botão direito do mouse e selecione Executar comando. A caixa de diálogo na Figura 6 é exibida. Agora basta digitar o comando desejado, clicar em Executar e esperar que a saída seja exibida na janela Result. As suas credenciais serão solicitadas na primeira vez em que você usar o ClusRun, mas você pode optar por ter essas credenciais armazenadas em cache para uso subseqüente.
Figura 6 É possível executar um comando em vários nós
Figura 6 É possível executar um comando em vários nós
Uma forma comum de corrigir clusters ou instalar programas que incluem rotinas de configuração automatizadas é colocá-las em um compartilhamento de arquivos e usar o ClusRun para forçar todos os nós de computadores a invocar o comando. A reinicialização de todos os nós de computadores no cluster inteiro pode ser realizada a partir de um único comando:
CLUSRUN SHUTDOWN –R –F –T 0

Pacote de ferramentas
Em maio de 2007, a equipe de HPC lançou o Pacote de ferramentas do Compute Cluster Pack (é possível obtê-lo online em windowshpc.net/resources/Pages/default.aspx). O pacote de ferramentas inclui suporte para o Windows PowerShellTM, uma ferramenta MPIPingPong para diagnóstico da integridade da conectividade e um monitor de cluster gráfico simples porém útil.
Como mostra a Figura 7, o Simple Cluster Monitor pode mostrar a você em uma tela cada nó no cluster, quantos núcleos cada nó tem, a utilização de cada CPU (em verde brilhante), utilização de memória (amarelo), porcentagem de tempo de disco (vermelho) e utilização de largura de banda de rede (laranja). É uma ferramenta rápida que os administradores podem executar para examinar como vai o cluster.
Figura 7 Monitorando vários nós com o Simple Cluster Monitor
Figura 7 Monitorando vários nós com o Simple Cluster Monitor
O monitor de cluster também inclui uma funcionalidade "remoteável". Você deve executar a primeira instância do monitor de cluster no nó principal. No entanto, se você executar uma instância do monitor de cluster em uma sessão do console no nó principal, terá a oportunidade de iniciar instâncias do monitor de cluster a partir de uma estação de trabalho, aponta-las para o nó principal e obter a mesma exibição.

O que você está esperando?
Você está agora armado com uma compreensão do HCO e do Windows Server 2003 Compute Cluster Server. Você sabe como instalar o CCP, examinou o ótimo console multifuncional e tem agora novas ferramentas de comando e gráficas com as quais deslumbrar os seus colegas e usuários. Você encontrará fontes para obter mais informações sobre Computação de Alto Desempenho na barra lateral “HPC Resources”.

John Kelbley é Gerente técnico de produto da Microsoft na Equipe de Tecnologia de Soluções Globais, no nordeste dos EUA. Entre em contato com ele pelo email Johnkel@microsoft.com
Doug Lindsey é Gerente de programa da Equipe do Microsoft HPC. Ele é também administrador de clusters de computadores de produção (incluindo o #116 na lista de novembro de 2007 em www.top500.org). Entre em contato com ele pelo email Dougli@microsoft.com.


 Online Extra: Implante o 2007 Office System com os Servi&#231;os de Terminal
Online Extra James D. Silliman

Implante o 2007 Office System com os Serviços de Terminal
Visão geral:
  • Implantação do 2007 Office System
  • Gerenciando as configurações de usuário
  • A nova Barra de Ferramentas de Acesso Rápido
  • Ferramenta de Personalização do 2007 Office System

O lançamento do sistema 2007 Microsoft Office trouxe alterações de design importantes sobre as quais você deve saber antes de implantá-lo ou atualizar as versões anteriores em seu farm de servidores de Serviços de Terminal. Será necessário conhecer o modelo global, a Barra de Ferramentas de Acesso Rápido,
os snap-ins do arquivo .adm para Diretivas de Grupo e a OCT (Office Customization Tool). Se você compreender todas essas ferramentas com antecedência, a sua implantação será mais tranqüila. Vamos começar nosso tour nas alterações de destaque observando o Microsoft® Word.

Implantando o Word 2007
O Word sempre utilizou um arquivo de modelo global e no 2007 Office system esse arquivo chama-se normal.dotm. Em um ambiente dos Serviços de Terminal, há três abordagens diferentes para implantar o Word e o arquivo normal.dotm. É possível deixar o arquivo em paz em todos os servidores dos Serviços de Terminal onde o Office for instalado para que os usuários recebam a exibição padrão no Word padrão. É possível abrir o arquivo em cada servidor de Terminal e modificá-lo por conta própria, adicionando personalizações, para que os usuários não recebam a exibição padrão no Word. Ou você pode renomear o arquivo totalmente para que os usuários obtenham seu próprio arquivo (modificado ao alterar uma configuração no Word e clicar em Padrão).
Independentemente da sua escolha, é melhor fazê-la com antecedência, antes da implantação. Se você não fizer alterações, os usuários não poderão salvar seus modelos globais porque o arquivo de modelo global localizado nos seus servidores de Serviços de Terminal substitui seus arquivos em seus perfis individuais. Se você não abrir o arquivo de modelo e ajustá-lo, o Word 2007 apresentará aos usuários somente suas configurações padrão.
No entanto, é possível ajustar o arquivo em cada servidor em seu farm de Serviços de Terminal, se desejar. Para fazer isso e manter as mesmas configurações do Word para cada usuário (como fonte e tamanho padrão, espaçamento de parágrafos e layout), será necessário manter esse arquivo de modelo global em seu local padrão. Em seguida, para modificar qualquer configuração que desejar implantar globalmente para os seus usuários, basta abrir esse arquivo em cada máquina dos Serviços de Terminal, fazer as alterações necessárias no layout do Word 2007 (clique em Padrão) e salvá-las, gravando suas alterações no arquivo normal.dotm padrão.
Certifique-se de fazer backup do arquivo padrão antes de fazer qualquer alteração ou talvez você se veja obrigado a reinstalar o Word 2007 para recuperar o arquivo original. Observe que se você fizer qualquer alteração à Barra de Ferramentas de Acesso Rápido enquanto estiver modificando o arquivo normal.dotm, essas alterações não serão armazenadas nesse arquivo de modelo. Tratarei sobre a Barra de Ferramentas de Acesso Rápido e seu comportamento em breve.
E se você decidir que os usuários devem poder gerenciar as suas próprias configurações globais dentro do Word? Eles podem, mas será necessário renomear o arquivo normal.dotm para algo como normal.dotm.old em todos os servidores em seu farm. Recomendo essa rota como a melhor escolha uma vez que os usuários podem receber erros de modelo ao fechar o Word se outros aplicativos estiverem conectados a ele.
Se você renomear esse arquivo, o Word 2007 reconhecerá que você deseja permitir que os usuários gerenciem suas próprias preferências em vez de ter preferências globais e, como resultado, permitirá a eles modificar e salvar suas configurações. O Word 2007 agora colocará o arquivo normal.dotm personalizar no caminho do perfil de cada usuário. Se você estiver usando perfis móveis (dependendo de como você configurou os seus caminhos), o arquivo de modelo estará armazenado neste local de pasta para cada usuário: \\domain\sharename\%username%\Application Data\Microsoft\Templates.
Uma configuração de preferência de usuário não armazenada no arquivo normal.dotm é qualquer alteração feita à Barra de Ferramentas de Acesso Rápido. Essa ferramenta é um novo recurso do 2007 Office System, separada da Barra de Ferramentas da Faixa de Opções (que também é nova). A Barra de Ferramentas de Acesso Rápido é a pequena barra de ferramentas localizada, por padrão, no canto superior esquerdo da tela no 2007 Office System. Essa barra de ferramentas existe nos aplicativos dentro do 2007 Office System, como mostrado na Figura 1. Consulte support.microsoft.com/kb/926805 para obter mais informações.
Figure 1 Arquivos da Barra de Ferramentas de Acesso Rápido (Close Figure 1)

Aplicativo do Office | Área do Recurso | Nome do arquivo
Access 2007 | Todas | Access.qat
Excel 2007 | Todas | Excel.qat
Outlook 2007 | Lista de Distribuição de Calendário de Contatos entrada de Diário Agência de Correio em pasta Tarefas | Olkaddritem.qat Olkapptitem.qat Olkdistitem.qat Olklogitem.qat Olkmailitem.qat Olkpostitem.qat Olktaskitem.qat
PowerPoint 2007 | Todas | PowerPoint.qat
Word 2007 | Todas | Word.qat
Como é possível observar na Figura 1, a Barra de Ferramentas de Acesso Rápido usa arquivos com a extensão .qat para armazenar configurações individualizadas. Os arquivos são mantidos nesse local no caminho de arquivo padrão em cada servidor dos Serviços de Terminal no seu Farm, e eles não são móveis: C:\Documents and Settings\username\Local Setting\Application Data\Microsoft\Office (ou C:\Users\username\AppData\Local\Microsoft\Office em uma máquina executando o Windows Vista®).
Se você examinar de perto o caminho, observará que os arquivos .qat estão localizados na subpasta Configurações Locais no perfil em cache localmente do usuário dos Serviços de Terminal. Essa subpasta não é sincronizada com um perfil móvel de usuário ao fazer logoff porque as Configurações Locais não existem na estrutura de caminhos de perfis móveis padrão. Assim, infelizmente, se você apagar os perfis armazenados em cache localmente nos seus servidores dos Serviços de Terminal ativando essa configuração GPO (Objeto de Diretiva de Grupo), você perderá os arquivos .qat personalizados do usuário (consulte o artigo na Base de Dados de Conhecimento em support.microsoft.com/kb/274152 para obter mais informações).
É um fato que a exclusão de perfis armazenados em cache localmente é amplamente praticada entre administradores de Serviços de Terminal para a limpeza de perfis locais quando um usuário faz logoff, portanto essa alteração no 2007 Office System é significativa pois é relativa a perfis em cache e a Barra de Ferramentas de Acesso Rápido. Uma solução óbvia é certificar-se de que as configurações GPO discutidas no artigo na Base de Dados de Conhecimento que acabo de mencionar não estejam definidas. Se você não habilitar a exclusão de perfis armazenados em cache no logoff e tiver muitos usuários, estará consumindo valioso espaço no disco rígido no drive %systemroot% local de cada servidor dos Serviços de Terminal e precisará configurar alguns outros processos para ficar atento nisso porque o seu servidor pode ficar sem espaço no disco rígido. Isso não é incomum, uma vez que os perfis locais podem ficar razoavelmente grandes.
Independentemente da abordagem, você deve ao menos adicionar uma rotina ao seu script de login que faça um backup dos arquivos .qat periodicamente para que possam ser recuperados caso desapareçam ou sejam excluídos acidentalmente. Ao manter um backup desses arquivos personalizados, é possível evitar chamadas dramáticas para o seu suporte técnico local para recuperá-los.
Poucos administradores dos Serviços de Terminal fazem backup desses perfis armazenados em cache localmente; em vez disso, eles fazem backup dos perfis móveis da rede que, como mencionei, não guardam cópias dos arquivos .qat. Outra alternativa é considerar um produto de terceiros que permita a implantação de um perfil obrigatório para cada usuário e mapear as alterações das Configurações Locais de cada usuário em uma pasta separada na sua rede.

Snap-ins de Diretiva de Grupo
Há algum tempo, os arquivos .adm de Diretiva de Grupo que estiveram disponíveis para o Office 2003 permitiam maior controle administrativo sobre as diretivas do Office e a experiência do usuário. De maneira semelhante, no 2007 Office System há novos arquivos .adm que podem ser usados para realizar uma série de personalizações, incluindo desabilitar a caixa de diálogo Primeira Execução e modificar as configurações de Salvamento Automático e outras preferências.
Se você já tiver implantado diretivas de grupo do Office 2003 e decidir mudar para o 2007 Office System, será necessário primeiro remover os seus arquivos .adm do Office 2003 dos GPOs antes de adicionar os arquivos .adm do 2007 Office System. Lembre-se de fazer backup dos GPOs usando a interface do GPMC (Console de Gerenciamento de Diretiva de Grupo) para que você possa reverter novamente caso encontre erros depois de adicionar os novos snap-ins. Sei de ao menos um administrador de Serviços de Terminal que presenciou entradas de diretiva fantasmas criadas por meio da remoção de snap-ins do Office 2003 e da adição de arquivos .adm do 2007 Office System em seus GPOs.
Eu mencionei em meu artigo de maio de 2007, "Um guia para implantar Serviços de Terminal" (technetmagazine.com/issues/2007/05/TerminalServices), que os usuários dos Serviços de Terminal não devem ser solicitados a executar determinadas ações, como o Arquivamento Automático do Outlook® ou aceitar telas de diálogo de Primeira Execução. Lembre-se de que, por padrão, na primeira vez em que o Outlook 2007 é iniciado, os usuários são apresentados a duas telas de Primeira Execução: uma de Opções de Privacidade e a segunda do Desktop Search. A primeira tela, exibida na Figura 2, pode ser desabilitada de várias maneiras: modificando as configurações GPO (usando os novos arquivos .adm do Outlook 2007), usando a Ferramenta de Personalização do Office ou ajustando o registro.
Figura 2 Diálogo de opções de privacidade no Office 2007 System
Figura 2 Diálogo de opções de privacidade no Office 2007 System
A tela mostrada na Figura 3 aparece imediatamente depois da tela de Opções de Privacidade (se você não a tiver) e em todos os outros aplicativos do 2007 Office System.
Figura 3 Diálogo do recurso de Pesquisa Instantânea no Office 2007 System
Figura 3 Diálogo do recurso de Pesquisa Instantânea no Office 2007 System
Para desativar o prompt do Windows® Search por aplicativos Office, baixe os modelos ADM do 2007 Office System de go.microsoft.com/fwlink/?LinkId=78161 e carregue-os para o disco rígido no seu controlador de domínio. Na Diretiva de Grupo, você deve carregar o modelo do Office Outlook 2007 (Outlk12.adm) em Configuração do Computador ou Configuração do Usuário, Adicionar Snap-Ins. Em seguida vá até Configuração do Usuário\Modelos Administrativos\Microsoft Office Outlook 2007\Ferramentas | Opções\Preferências\Opções de Pesquisa e ative a configuração "Evitar prompts de instalação quando o componente Windows Desktop Search não estiver presente".
Há muitas configurações de Diretiva de Grupo disponíveis no 2007 Office System para controlar a experiência do usuário, mas é necessário adicionar os arquivos .adm correspondentes, como para cada Word (Word12.adm) e Excel® (Excel12.adm), aos seus GPOs. A Figura 4 mostra um exemplo da aparência do modelo ADM do Outlook 2007 (Outlook12.adm) depois de ter sido adicionado à sua Diretiva de Grupo.
Figura 4 Modelos ADM do Outlook 2007 na Diretiva de Grupo
Figura 4 Modelos ADM do Outlook 2007 na Diretiva de Grupo

Alterações adicionais
Observe que no Office 2003 é possível baixar e usar o Custom Installation Wizard para criar Transformações personalizadas. A nova OCT no 2007 Office System não necessita de um download separado. Ele é iniciado usando "Setup /admin" do comando Executar, direcionado para a mídia ou origem da instalação do 2007 Office System. Executar esse comando nos seus arquivos de origem de instalação e, em seguida, alterar as configurações individuais como você desejar cria um arquivo .msp (versus o arquivo .mst no Office 2003) e não é necessário especificar nenhuma opção de linha de comando para incluí-lo em sua implantação posterior. Basta colocar o arquivo .msp personalizado na pasta Atualizações na raiz do ponto de instalação de rede para implantá-lo automaticamente com suas configurações preferidas.
O Outlook 2007 tem outra vantagem sobre suas versões anteriores; ele localiza automaticamente seus servidores Exchange 2007, enviando uma consulta SCP (Ponto de Conexão de Serviço) diretamente para o Active Directory®, se iniciado dentro da sua LAN. Essa consulta facilita a conexão a uma infra-estrutura do Exchange 2007 implantada. Para obter mais informações, consulte go.microsoft.com/fwlink/?linkid=76177.
A Microsoft fez alterações importantes no design da forma como o 2007 Office System trabalha em um ambiente de Serviços de Terminal simplificando suas ferramentas de implantação, adicionando novos snap-ins de arquivos .adm e otimizando a interface. Ao compreender alguns conceitos importantes que discuti aqui antes de implantar ou atualizar seus aplicativos Office, você compreenderá melhor a atualização, permitindo que você tome decisões de design importantes com antecedência. Se você não planeja atualizar agora, talvez considere somente carregar o Compatibility Pack do 2007 Office System para que os usuários possam abrir anexos recebidos de usuários que já fizeram a atualização. É possível encontrar o Compatibility Pack em go.microsoft.com/fwlink?LinkID=77512.
Com essas informações em mãos, você estará pronto para uma implantação bem-sucedida do 2007 Office System. Lembre-se de fazer backup de suas diretivas e testar todas as configurações recomendadas em um ambiente de laboratório antes de implantá-las na sua comunidade de usuários.

James D. Silliman, MCSE, é tecnólogo concentrado em produtos Microsoft especializado em implantações dos Serviços de Terminal. Ele trabalha atualmente para um ASP, onde arquiteta soluções de TI para pequenas empresas. Entre em contato com ele pelo email jsilliman@gmail.com.


 Do editor: Lidando com a sobrecarga de informa&#231;&#227;o
Do editor
Lidando com a sobrecarga de informação
Joshua Hoffman

Quando penso nos nossos dois tópicos principais deste mês—SharePoint e Office Communications Server—não é muito surpreendente que tenhamos problemas em nos comunicar uns com os outros. Veja bem, enquanto escrevo essa nota (provavelmente um mês ou mais antes de você lê-la), a cidade de New York está totalmente no clima das festas de fim de ano. E para melhorar, a sede empresarial da TechNet Magazine se localiza no epicentro das festas de fim de ano em New York: Rockefeller Center. É uma área maravilhosa da cidade em vários aspectos, mas durante mais ou menos um mês todo ano ela se torna... digamos que um desafio. A população cresce (ainda mais) com visitantes de todo o país e também do mundo que vêm para fazer compras, assistir a shows ou patinar no gelo com o pano de fundo de arranha-céus majestosos. Muitos moradores de New York, no entanto, batem em retirada.
Alguns argumentam que isso ocorre pela frustração em relação aos turistas que param no meio da calçada para tirar fotos e forçam todos atrás deles a parar de repente ou bater de cara neles. Mas não é só isso (na verdade, estamos felizes que vocês estejam aqui—tirem quantas fotos quiser). Acho que é somente uma sobrecarga. Em meio a uma cidade já tumultuada e ocupada, chegamos a um ponto de desequilíbrio e aí já é demais.
Levando isso em consideração, observo a nossa indústria e vejo a mesma tendência. Nossas organizações continuam a crescer (o que é, provavelmente, o que esperamos) e, como resultado, geramos mais e mais informações a cada dia. Nossos compartilhamentos de arquivos estão cheios. Nossos bancos de dados estão cheios. Não vamos nem começar a discutir sobre nossos emails. Há não muito tempo, um gigabyte era muito armazenamento. Atualmente, terabytes são comuns—até mesmo em PCs domésticos. Muitos data centers estão sendo agora planejados levando petabytes em conta. Podemos concordar; há muita informação por aí. Mas ela é útil ou somente esmagadora? Ela é estruturada? Fácil de ser analisada? Fácil de ser compartilhada?
Novamente, com a quantidade esmagadora de informações, não me surpreende que seja difícil para nós nos conectarmos. Mas poderia ser muito mais fácil, e é isso que discutiremos este mês. Nesta edição, aprenda como explorar o poder do SharePoint para tornar a coleta de dados mais organizada na sua empresa. Aprenda a criar pesquisas de forma rápida para coletar esses dados dos seus usuários(ou clientes). Aprenda a definir tipos de conteúdo personalizados para que a informação coletada seja muito mais significativa. E finalmente, aprenda como usar o Office Communications Server para fazer essas conexões críticas. Afinal, para quê tantos dados se não houver com quem compartilhá-los? – Joshua Hoffman

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Ed Banti, Susan Bradley, Byron Hynes, Michael Murgolo, Ken Oien, Jim Truher e Kay Unkroth.


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

Disponibilidade do serviço de instalação do ActiveX
Acabo de ler o seu artigo de julho de 2007 sobre "O serviço de instalação do ActiveX no Windows Vista" (online em technetmagazine.com/issues/2007/07/AxIS). Você poderia me informar se esse serviço está disponível agora?
—Eugene Y.

Sim, o serviço de instalação do ActiveX® está disponível agora. Ele pode ser habilitado de maneira fácil por meio da opção “Ativar e desativar recursos do Windows” no painel de controle Programas e Recursos no Windows Vista®.
O serviço de instalação do ActiveX é um componente opcional somente nas versões Ultimate, Enterprise e Business do Windows Vista. A lista de sites que permitem a instalação do ActiveX com o serviço de instalação do ActiveX é controlada por meio da Diretiva de Grupo. A lista é armazenada na seção Configuração do Computador | Modelos Administrativos | Componentes do Windows | Serviço de instalação do ActiveX do Editor de Objeto de Diretiva de Grupo.

Ferramentas do Active Directory
Muito obrigado pelo artigo "11 Ferramentas essenciais para o gerenciamento do Active Directory" (setembro de 2007). Tenho tentando excluir usuários do Active Directory® com o utilitário dsrm descrito no artigo, usando a seguinte linha de comando:
          dsquery user -samid <samid> | dsrm
Recebo uma mensagem de erro sobre a entrada do "dsrm" estar em uma forma imprópria. No entanto, consigo executar o comando separadamente sem nenhum problema. Alguma idéia?
—Keith E.

Passamos a sua pergunta para a autora do artigo, Laura Hunter. Laura aponta que ao canalizar resultados dsquery no dsrm, dsrm necessita do comutador -noprompt. Assim, seria necessário usar a seguinte linha de comando:
dsquery user -samid <samid> | dsrm -noprompt
Pedimos desculpas por esta informação ter sido omitida do artigo original e publicaremos uma correção na versão online.

Possibilidades alternativas para o quebra-cabeças
Suponho que você perceba, e tenha provavelmente sido lembrado por muitos outros, que o quebra-cabeças do desafio de script do Dr. Scripto (novembro de 2007) tem, na verdade, duas soluções que funcionam. O quebra-cabeças também será resolvido corretamente se a variável de quatro caracteres que aparece na primeira e segunda linhas for nnde e se a variável de cinco caracteres que aparece nas terceira e quinta linhas for iamex. (Admito que a diferença é trivial e que os nomes na sua solução tornam o script mais legível).
Obrigado pela diversão do quebra-cabeças; eu gostei.
—Stan A.

Obrigado por compartilhar a sua solução alternativa, Stan! Ficamos contentes em saber que você gostou do novo quebra-cabeças da Equipe de Script e ficamos muito empolgados em adicioná-lo como um recurso regular da TechNet Magazine.

Persuasão da migração do Windows Vista
O artigo "Mudanças em Arquivos Offline no Windows Vista" da edição de novembro de 2007 da TechNet Magazine (visite technetmagazine.com/issues/2007/11/Offline) mostra muito bem as vantagens do Windows Vista na área de arquivos off-line. O artigo nos ajudou na decisão de migrar para o Windows Vista porque tínhamos muitos problemas com arquivos offline ao usar o Windows® XP Professional.
—Daniel Z.

Obrigado, Daniel! Ficamos contentes em saber que você achou o artigo útil para a sua organização.

Páginas não encontradas
A sua revista é agradável e informativa. No entanto, a minha cópia da edição de dezembro de 2007 veio com as páginas 49 a 64 faltando. Eu estava interessado no artigo sobre computação forense ("Um guia para a computação forense básica") de Tom Cloward e Frank Simorjay que deveria estar na página 60. Talvez a sua equipe de impressão forense possa encontrar as minhas páginas ou dados não encontrados? Se esse artigo estiver disponível online, ficarei feliz em lê-lo ali, se for possível enviar-me o URL.
—Dave S.

Infelizmente, tivemos problemas durante a impressão da edição de dezembro de 2007 e, como resultado, um pequeno número de cópias foram enviadas aos leitores sem as páginas 49 a 64. Em nome da nossa gráfica e da equipe da TechNet Magazine, pedimos desculpas sinceras pelo inconveniente.
Nesse ínterim, o artigo ao qual você se refere, juntamente com todo o resto da edição de dezembro, está disponível online em technetmagazine.com/issues/2007/12.


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

Desbloqueio de arquivos
Unlocker
ccollomb.free.fr/unlocker
Isso já aconteceu a todos nós – determinado processo automatizado trava durante sua operação e um arquivo fica preso com um bloqueio de gravação, fazendo com que outra operação falhe, pois não é possível copiar, mover, gravar nem excluir o arquivo. E, às vezes, você apenas não sabe quem foi o culpado por manter o arquivo bloqueado, mas sabe qual arquivo foi bloqueado. Então, o que fazer?
Há várias formas de lidar com isso, mas uma ferramenta que fornece uma solução rápida e fácil integrada ao Windows® para problemas de bloqueio de arquivo é a ferramenta gratuita Unlocker, escrita por Cedrick Collomb. Graças a sua integração com o Windows Explorer, você pode localizar o invasor simplesmente clicando com o botão direito do mouse no arquivo bloqueado (ou até mesmo um conjunto de arquivos) e, em seguida, selecionando Unlocker do menu de contexto. Em seguida, se um bloqueio for detectado, você poderá escolher a partir de várias opções, como eliminar o processo invasor, desbloquear o arquivo (encerrando o identificador), excluí-lo, movê-lo ou renomeá-lo. Também é possível copiar o arquivo bloqueado em seu estado atual para outro local.
A ferramenta Unlocker tem um instalador de aplicativo completo, de modo que você não precisará registrar ou cancelar o registro de quaisquer DLLs manualmente, nem precisará reiniciar o seu sistema para iniciar a ferramenta. Essa ferramenta também é compatível com a notificação de atualização automática (se você não se importar de executar a verificação de vez em quando) para se certificar de que tenha a versão mais recente.
A ferramenta Unlocker é compatível até mesmo com a execução da linha de comando, que é excelente para automação. Isso significa que, por exemplo, você pode configurar facilmente um processo de envio de log para que encerre automaticamente o identificador e elimine o processo de compactação caso detecte um arquivo .zip bloqueado ao tentar mover os logs, talvez assim evitando assim que você precise acordar cedo para tentar resolver o problema manualmente.
O utilitário também tem uma ferramenta na bandeja do sistema denominada Unlocker Assistant. Essa ferramenta pode iniciar automaticamente a interface do Unlocker quando você tentar mover, renomear ou excluir um arquivo bloqueado, eliminando a necessidade de cliques adicionais para localizar o arquivo e escolher Unlocker do menu de contexto com o botão direito do mouse. A ferramenta Unlocker é compatível com a maioria das versões do Windows, incluindo o Windows Vista®.

Preço: gratuito
Com a ferramenta Unlocker, você pode localizar e desbloquear rapidamente arquivos bloqueados
Com a ferramenta Unlocker, você pode localizar e desbloquear rapidamente arquivos bloqueados

Análise de tráfego de rede
Wireshark
wireshark.org
Um bom analisador de protocolo de rede permite que você tenha acesso aos fundamentos do tráfego de rede na sua infra-estrutura, a fim de ver o que realmente está acontecendo em todas essas camadas de aplicativos interconectados. Talvez o analisador de código-fonte aberto mais conhecido seja o Wireshark, que utiliza a biblioteca de captura de pacotes WinPcap de código-fonte aberto para Windows e é derivado do Ethereal, com Gerald Combs ainda no controle.
Com o Wireshark, você pode capturar facilmente a passagem de tráfego na interface de rede e examinar os detalhes de cada pacote em uma interface gráfica e fácil de usar. Iniciar uma nova sessão de captura de pacotes é tão fácil quanto selecionar a sua interface e clicar em iniciar. A interface gráfica do usuário exibe os pacotes capturados em um quadro codificado por cores, que apresenta detalhes sobre a hora, a origem, o destino, o protocolo e uma descrição predeterminada do evento em horário próximo ao real. Clicar em uma transmissão destaca os detalhes e interpreta os dados do pacote em um painel de detalhes fácil de seguir. Abaixo disso, você poderá ver os dados de pacote não processados em hexadecimal e ASCII.
Assim que você tiver o conjunto de dados necessários para sua análise, você também poderá, é claro, salvar ou exportar a sessão para análise posterior. O Wireshark pode decodificar vários protocolos diferentes e deverá abranger a maioria das suas necessidades de resolução de problemas.
As redes são “ruidosas” e para ajudá-lo a filtrar todos esses dados, o aplicativo tem um excelente recurso de filtro com base em expressão, que permite que você refine sua pesquisa por cada parâmetro de um protocolo. Por exemplo, você poderia filtrar todo o tráfego, exceto o relacionado à BitTorrent de/para IPs específicos na sua rede. Ou, os filtros poderiam permitir que você detectasse facilmente qual máquina está causando confusão na rede ao emitir várias mensagens de difusão falsas.
A interface também permite que você sinalize facilmente pacotes para revisão e defina uma transmissão específica como a sua referência de horário na captura. Um dos meus recursos favoritos do Wireshark é a capacidade de acompanhar um fluxo TCP, quando essa opção é escolhida no menu de contexto com um clique com o botão direito do mouse em um pacote TCP. Isso exibirá uma janela com exibição de texto formatada e codificada por cor do conteúdo de fluxo TCP, que será excelente para a detecção de erros de aplicativo Web, cabeçalhos HTTP falsos ou outros problemas de comunicação TCP que venha a detectar. E, a partir disso, você poderá rapidamente imprimir ou salvar a conversação para exame ou demonstração posterior.
Minha abordagem foi superficial em comparação à funcionalidade do aplicativo. O Wireshark foi lançado sob a licença GPL; além de estar disponível para Windows, ele também tem binários compilados para a maioria das versões do Linux e FreeBSD.

Preço: gratuito
O Wireshark permite que você analise seu protocolo de rede completo
O Wireshark permite que você analise seu protocolo de rede completo

Reforço do Windows PowerShell
Extensões de comunidade do PowerShell
codeplex.com/PowerShellCX
Se você já teve a oportunidade de realmente trabalhar com o Windows PowerShellTM, provavelmente observou alguns padrões recorrentes para os quais seria excelente ter um cmdlet ou alias. Para esse fim, um grupo de usuários do Windows PowerShell e defensores da comunidade de código-fonte aberto criaram o projeto Extensões de comunidade do PowerShell, que resume a funcionalidade comumente solicitada em um conjunto distribuível de cmdlets, aliases, provedores, funções, filtros e scripts.
Alguns dos cmdlets incluídos no pacote são Get-Clipboard e Write-Clipboard, que permitem que você adicione e recupere os dados no buffer da área de transferência. Enquanto isso, Get-DomainController recupera uma lista de controladores de domínio disponíveis no domínio atual, e Write-GZip e Write-Zip permitem que você grave arquivos GZIP ou ZIP.
Você pode criar um novo link simbólico ou junção no Windows Vista ou Windows Server® 2008 com New-Symlink e New-Junction, respectivamente. Há um provedor DirectoryServices útil que fornece acesso a servidores LDAP, como Active Directory® e AssemblyCache, permitindo que você acesse o GAC (Global Assembly Cache) do Microsoft .NET Framework e os assemblies nele.
Também há vários scripts excelentes. Os scripts Set-Writable e Set-ReadOnly permitem que você altere rapidamente um status somente leitura do arquivo. Get-Url faz uma WebRequest e retorna a WebResponse como uma cadeia de caracteres, e Export-History despeja o histórico de comandos para um arquivo .clixml para uso posterior. Você pode se deparar com informações de uso do disco com o script Get-DiskUsage ou até mesmo fazer com que o seu computador fale usando o divertido comando Out-Speech. Além disso, o pacote inclui um bom número de outras funções úteis, como Quote-List, que reduz a digitação da sua linha de comando, e Add-PathVariable, que pode adicionar um conjunto de caminhos a um ambiente especificado.
Esse projeto adiciona um conjunto muito útil de extensões ao ambiente padrão do Windows PowerShell. E, se você for um especialista do Windows PowerShell, estou certo de que o projeto receberá muito bem as suas contribuições.

Preço: gratuito
As Extensões de comunidade do PowerShell fornecem funções comumente solicitadas
As Extensões de comunidade do PowerShell fornecem funções comumente solicitadas

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


 P+R SQL: &#205;ndices n&#227;o agrupados e permiss&#245;es de reten&#231;&#227;o
P+R SQL
Índices não agrupados e permissões de retenção
Saleem Hakani and Dan Carollo

Índices não agrupados e seus usos
P O que são índices não agrupados e quais são as vantagens e as desvantagens de usá-los?
R Um índice não agrupado é semelhante a um índice remissivo (encontrado geralmente no final de livros). Todas as informações contidas neste livro são representadas no índice por tópico. Há indicadores na forma de números de página que o direcionam para localização das informações, talvez em várias áreas do livro. Além disso, os dados no índice de um livro não são registrados na mesma ordem em que aparecem no texto do livro. Ocorre o mesmo com os índices não agrupados. Se você tiver um índice agrupado em uma tabela, poderá especificar qual será a ordem dos itens. Caso contrário, não será possível ter certeza de qual será a ordem.
Além disso, os índices não agrupados têm duas limitações: somente 16 colunas podem ser incluídas no índice e o tamanho máximo da chave de índice não pode exceder 900 bytes. Portanto, o que isso significa? Vejamos o que acontece se você quiser indexar as seguintes colunas na tabela Movie do banco de dados MovieList de amostra: MovieTitle NVarchar(50), DirectorName NVarchar(50), ShortStory NVarchar(400).
Suponha que você emita a seguinte instrução para criar a tabela:
Use MovieList;
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName, ShortStory);
Isso irá gerar a seguinte na mensagem de erro: “Atenção! O tamanho máximo da chave é de 900 bytes. O índice 'Movie_IDX' tem o comprimento máximo de 1.000 bytes. Para certa combinação de valores maiores, a operação inserir/atualizar falhará." Você receberá a mensagem acima porque o tipo de dados "nvarchar" utilizará dois bytes para cada caractere; um índice contendo as três colunas anteriores excederia o limite de tamanho de 900 bytes.
Com o lançamento do SQL Server® 2005, agora você terá a oportunidade de solucionar esse problema adicionando as colunas à cláusula INCLUDE. Isso é muito útil se você quiser solucionar as limitações de tamanho e de coluna. Você fará isso executando a seguinte instrução:
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName) INCLUDE (ShortStory);
É importante salientar que quando você usar a cláusula INCLUDE durante a criação de índice, o mecanismo do banco de dados não considerará colunas não chave ao calcular o número das colunas chave de índice ou tamanho de chave de índice.
Para localizar informações mais úteis sobre índices não agrupados, visite "Índices não agrupados" em msdn2.microsoft.com/aa174537 e "Usando índices não agrupados" at msdn2.microsoft.com/aa933130. Para obter dicas sobre a otimização de índices, consulte sql-server-performance.com/optimizing_ indexes.asp.

Preservação dos dados de permissões
P Como posso evitar a perda de permissões quando uma assinatura for reinicializada? Tive o seguinte problema várias vezes: quando um instantâneo é reinicializado, ele perde todas as permissões concedidas.
R Por padrão, todos os objetos no banco de dados de assinaturas são descartados e recriados sempre que uma assinatura é reinicializada. Mas há duas formas de administrar esse cenário.
Primeiro, você pode reaplicar todas as permissões depois da reinicialização. Quando você configurar as permissões de modo manual, deverá criptografar todas as permissões no nível de objeto/instrução e armazená-las separadamente, de modo que possa usá-las de imediato depois de reinicializar a assinatura.
Em segundo lugar, você pode configurar a sua assinatura para que não descarte objetos sempre que você reinicializá-la. Para que você possa usar o procedimento armazenado do sistema SP_CHANGEARTICLE para configurar o valor de PRE_CREATION_CMD para o parâmetro @PROPERTY e um valor de NONE, DELETE ou TRUNCATE para o parâmetro @Value.
Além disso, na caixa de diálogo Article Properties (Propriedades do artigo) na seção do objeto de destino, selecione um valor de "Keep existing object unchanged, delete data." (Manter o objeto existente inalterado, excluir dados.), de "If article has a row filter, delete only what matches the filter." (Se o artigo tiver um filtro de linha, excluir somente o que corresponder ao filtro.) e de "Truncate all data in the existing object." (Truncar todos os dados no objeto existente.) Certifique-se de tentar isso no seu ambiente de teste e, se você precisar de mais ajuda, verifique a última versão dos Manuais Online do SQL Server para obter informações atualizadas.

Saleem Hakani é engenheiro sênior de banco de dados, engenheiro sênior de resolução de problemas e líder da comunidade mundial do Microsoft SQL Server com 14 anos de experiência em sistemas de banco de dados. Ele lidera o site da Comunidade externa do SQL Server sqlcommunity.com e pode ser contatado pelo email Saleem@sqlcommunity.com.
Dan Carollo é engenheiro de operações e administrador de banco de dados SQL Server que trabalha com a equipe de resposta e pesquisa anti-malware do Windows na Microsoft. Ele é MCT em SQL Server.


 Utilit&#225;rio em destaque: ADMX Migrator
Utilitário em destaque
ADMX Migrator
Lance Whitney
Faça download do código deste artigo: ADMX Migrator (2765KB)

Aqueles de vocês que empregam a Diretiva de grupos já estão, é claro, familiarizados com o uso de modelos administrativos para definir as configurações de aplicativo e do sistema operacional. Os arquivos ADM incluídos com o Windows® e principais aplicativos, como o Microsoft® Office, abrangem as configurações mais comuns de desktop. No entanto, às vezes, você precisa criar seus próprios modelos ADM para incorporar configurações personalizadas. A criação de ADMs do zero pode ser um fardo, pois eles têm sua própria sintaxe exclusiva e requer que sejam criados com o uso de um editor de texto. Mas graças ao tempo e à experiência, muitos profissionais de Diretiva de grupo se tornaram adeptos de criar eles mesmos arquivos ADM.
Com o Windows Vista®, a Microsoft alterou o formato dos modelos de Diretiva de grupo para uma estrutura baseada em XML. Esse novo formato, denominado ADMX, oferece diversas vantagens em relação aos arquivos ADM herdados, como suporte a vários idiomas e um ponto de armazenamento central no qual você pode gerenciar todos os seus modelos.
Essa é uma boa notícias, mas se você quiser criar seus próprios arquivos ADMX e não estiver familiarizado com XML? E, mais importante, o que restará para todos aqueles ADMs personalizados que você passou anos criando? Felizmente, o utilitário ADMX Migrator veio para salvá-lo. Essa ferramenta gratuita, desenvolvida pela FullArmor Corporation e licenciada para a Microsoft, oferece duas importantes vantagens: permite que você crie seus próprios arquivos ADMX e pode converter seus arquivos ADM herdados em ADMX.
Interface gráfica do ADMX Migrator
Interface gráfica do ADMX Migrator
Para criar modelos no novo formato, o ADMX Migrator fornece o ADMX Editor, que apresenta uma interface gráfica do usuário – não é mais necessário o uso do editor de texto. Assim, você cria seus modelos usando menus e listas suspensos em uma interface clara e simples (veja a figura). Para iniciar, escolha o comando New Template (Novo modelo), nomeie o arquivo de modelo e insira uma categoria na qual classificar seu arquivo. Em seguida, crie a configuração de diretiva real inserindo a chave do Registro à qual a diretiva se aplicará, o nome do valor do Registro e a classe que ela afetará (Usuário, Máquina ou ambos). Também é possível descrever a função da diretiva.
Quando você tiver concluído, salve o seu novo modelo no formato ADMX. Ele será armazenado como um arquivo ADMX e um arquivo ADML. O arquivo ADMX contém as configurações da diretiva real e o arquivo ADML fornece informações específicas de idioma da diretiva. Agora, você pode copiar ambos os arquivos nos diretórios apropriados no seu domínio e incorporá-los na Diretiva de grupo.
Você provavelmente converterá seus arquivos ADM em ADMX para aproveitar o novo formato. O ADMX Migrator fornece dois métodos de conversão – por meio do editor ou por meio de um programa da linha de comando. A partir do ADMX Editor, escolha a opção para gerar ADMX a partir do ADM. Vá até o seu arquivo ADM e a ferramenta o converterá de modo rápido e automático. Então, você poderá abrir o arquivo convertido no editor, a fim de examinar seus valores e propriedades e modificá-lo caso deseje. A janela de comando do ADMX Migrator é um pouco mais complicada; ela requer que você digite uma cadeia de caracteres de comando mais longa no prompt para execução das conversões. No entanto, ela inclui algumas opções de flexibilidade não disponíveis no editor gráfico.
O ADMX Migrator é um snap-in do MMC (Console de Gerenciamento Microsoft); portanto, ele requer o MMC 3.0 e o Microsoft .NET Framework 2.0. O ADMX Migrator será executado no Windows XP SP2, no Windows Server® 2003 SP1 e no Windows Vista. Você pode baixar o software no endereço go.microsoft.com/fwlink/?LinkId=77409.

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


 The Cable Guy: Autentica&#231;&#227;o com fio IEEE 802.1X
The Cable Guy
Autenticação com fio IEEE 802.1X
Joseph Davies
Este artigo se baseia em uma versão de pré-lançamento do Windows Server 2008. Os detalhes deste artigo estão sujeitos a alterações.

Com o aumento na popularidade da autenticação IEEE 802.1X para redes sem fio IEEE 802.11, os administradores de rede também podem desejar usar esse padrão para suas conexões de rede com fio. Assim como um cliente sem fio deve enviar um conjunto de credenciais a serem validadas antes de permitir que quadros sem fio sejam encaminhados para a intranet, um
cliente com fio IEEE 802.1X deve executar uma autenticação antes de poder usar sua porta do comutador. A autenticação IEEE 802.1X fornece uma barreira de segurança adicional para a sua intranet – você pode impedir que computadores convidados, não autorizados ou não gerenciados que não executem uma autenticação bem-sucedida conectem-se à sua intranet.
A autenticação IEEE 802.1X provavelmente já é compatível com os seus comutadores com fio e apenas precisa ser habilitada e configurada. Para a autenticação e a autorização de uma conexão com fio, os computadores compatíveis com 802.1X geralmente utilizam o protocolo RADIUS (Remote Authentication Dial-In User Service) para enviar informações de solicitação de conexão para um servidor RADIUS, como NPS (Servidor de diretivas de rede) baseado no Windows Server® 2008 ou um servidor de IAS (Serviço de autenticação da Internet) do Windows Server 2003.
Depois que configurar seus comutadores para RADIUS mas antes de exigir a autenticação 802.1X, você precisará habilitar e configurar a autenticação 802.1X nos seus computadores com fio. A autenticação IEEE 802.1X para conexões de rede com fio é compatível com o Microsoft® Windows® desde o Windows XP. No entanto, você deve definir manualmente as configurações de autenticação 802.1X no Windows XP e Windows Server 2003 em cada cliente com fio individual (a partir da guia Autenticação das propriedades de uma conexão de rede na pasta Conexões de rede). Infelizmente, não há como configurar centralmente ou criptografar configurações 802.1X com fio para esses sistemas operacionais anteriores.
Felizmente, o suporte a configurações com fio na Diretiva de grupo e o suporte a script com a ferramenta Netsh no Windows Vista® e no Windows Server 2008 significam que a implantação de configurações com fio 802.1X é muito mais simples do que antes.

Configurações de rede com fio na diretiva de grupo
Como usar o serviço AutoConfig com fio
No Windows XP e no Windows Server 2003, o comportamento de 802.1X em conexões com fio é controlado pelo serviço Configuração zero sem Fio. Nesses sistemas operacionais, esse serviço foi habilitado por padrão e conexões de rede com fio foram colocadas em um modo de escuta passivo, aguardando para que o comutador inicie a autenticação.
Em contraste, no Windows Vista e no Windows Server 2008, o serviço AutoConfig com rede controla o comportamento 802.1X em conexões com fio, mas é desabilitado por padrão. Portanto, a guia Autenticação das propriedades de conexões de rede não aparece até que o serviço AutoConfig com fio seja iniciado.
Para um cliente com fio individual executando o Windows Vista ou Windows Server 2008, você pode usar o snap-in Serviços para iniciar o serviço AutoConfig com fio e configurá-lo para inicialização automática. Quando o serviço AutoConfig com fio for iniciado, as conexões de rede com fio operam em um modo de escuta ativo no qual a conexão de rede tenta iniciar a autenticação com o comutador.
Para um domínio Active Directory, você pode usar a Diretiva de grupo para configurar o serviço AutoConfig com rede para inicialização automática. Usando o snap-in Editor de gerenciamento da diretiva de grupo, define a Configuração do Computador | Configurações de Segurança | Serviços do Sistema | configuração AutoConfig com fio como modo de inicialização Automático.

Para centralizar e automatizar a definição de configurações de rede com fio, os serviços de domínio do Windows Server 2008 e do Windows Server 2003 Active Directory® são compatíveis com as configurações de diretiva com fio na Diretiva de grupo. Essas definições permitem que você defina configurações de rede com fio como parte da Diretiva de grupo de configuração do computador para um objeto da diretiva de grupo com base em domínio.
Com essas configurações de diretiva com fio, você pode especificar o método de autenticação e outras configurações de 802.1X para clientes com fio executando o Windows Server 2008 ou o Windows Vista. Ao ingressar no domínio, inicializar ou periodicamente depois de iniciar, esses sistemas operacionais baixam automaticamente as configurações da Diretiva de grupo com fio e as aplicam. Apenas observe que um domínio Active Directory do Windows 2003 deve ser ampliado para que seja compatível com essas novas diretivas. Para obter mais informações sobre como ampliar um domínio Active Directory do Windows Server 2003, consulte technet.microsoft.com/bb727029.
Você pode configurar diretivas com fio a partir do nó Configuração do Computador | Configurações do Windows | Configurações de Segurança | Diretivas de Rede com Fio (IEEE 802.3) no snap-in Editor de gerenciamento da diretiva de grupo. Por padrão, não há diretivas de rede com fio (IEEE 802.3). Para criar uma nova diretiva, clique com o botão direito do mouse em Diretivas de Rede com Fio (IEEE 802.3) na árvore de console e clique em Criar uma nova diretiva do Windows Vista.
A caixa de diálogo de propriedades de uma diretiva com fio do Windows Vista consiste em uma guia Geral e uma guia Segurança. A Figura 1 mostra a guia Geral padrão. Na guia Geral, você pode configurar um nome e uma descrição para a diretiva e especificar se é necessário usar o serviço AutoConfig com fio, que controla o comportamento 802.1X em conexões com fio. Para obter mais informações, consulte a barra lateral "Como usar o serviço AutoConfig com fio" desta coluna.
Figura 1 A guia Geral padrão de uma diretiva com fio do Windows Vista
Figura 1 A guia Geral padrão de uma diretiva com fio do Windows Vista
A Figura 2 mostra a guia Segurança padrão de uma diretiva com fio do Windows Vista. Na guia Segurança, você pode habilitar ou desabilitar a autenticação 802.1X, selecionar e configurar o método de autenticação EAP (Extensible Authentication Protocol), selecionar o modo de autenticação (reautenticação do usuário, somente computador, autenticação do usuário ou autenticação de convidado), configurar o número de vezes de tentativas de autenticação com falha antes de a autenticação ser abandonada, bem como configurar se as informações do usuário devem ser armazenadas em cache para conexões subseqüentes. Quando o armazenamento em cache estiver desabilitado, o Windows removerá os dados de credenciais do usuário do Registro quando o usuário fizer logoff. Isso fará com que as credenciais do usuário sejam solicitadas (como o nome de usuário e a senha) quando ele fizer logon novamente.
Figura 2 A guia Segurança padrão de uma diretiva com fio do Windows Vista
Figura 2 A guia Segurança padrão de uma diretiva com fio do Windows Vista
Quando você clicar no botão Avançado, na guia Segurança, poderá definir as configurações avançadas para 802.1X e Logon único. A Figura 3 mostra a caixa de diálogo de configurações de segurança Avançadas de uma diretiva com fio do Windows Vista. Da caixa de diálogo de configurações de segurança Avançadas, você poderá definir as configurações de 802.1X exibidas na Figura 4.
Figure 4 Configurações de 802.1X na caixa de diálogo configurações de segurança Avançadas (Close Figure 4)

Configuração | Descrição
Mensagens de início EAPOL máx. | O número de sucessivas mensagens de início EAPOL (EAP sobre LAN) que são enviadas quando não há resposta para as mensagens de início EAPOL recebidas.
Período de retenção | O intervalo de tempo entre a retransmissão de mensagens de início EAPOL quando não há resposta às mensagens de início EAPOL previamente enviadas recebidas.
Período de início | O período durante o qual o cliente de autenticação não executará qualquer atividade de autenticação 802.1X depois que tiver recebido uma indicação de falha de autenticação do autenticador.
Período de autenticação | O período de tempo em que o cliente de autenticação precisará aguardar antes de retransmitir quaisquer solicitações de 802.1X depois que a autenticação 802.1X de ponta a ponta for iniciada.
Mensagem de início EAPOL | Quando o cliente com fio enviar a mensagem de início EAPOL.
Figura 3 A caixa de diálogo de configurações de segurança Avançadas de uma diretiva com fio do Windows Vista.
Figura 3 A caixa de diálogo de configurações de segurança Avançadas de uma diretiva com fio do Windows Vista.
Os clientes com fio executando o Windows Server 2008 são compatíveis com o Logon único para conexões com fio. Esse recurso também está previsto para o próximo lançamento do Windows Vista Service Pack 1. Mais informações estão disponíveis online em technetmagazine.com/issues/2007/11/CableGuy.
Há configurações de logon único disponíveis para realizar a autenticação de 802.1X no nível de usuário antes ou logo após o processo de logon do usuário e aguardar o número configurado de segundos para que a autenticação de 802.1X seja concluída antes do início do processo de logon do usuário. Também é possível determinar se caixas de diálogo devem ou não ser exibidas para a autenticação no nível de usuário além da consolidação dos campos de entrada na tela de logon do Windows. Por exemplo, caso um tipo de EAP queira que o usuário confirme o certificado enviado do serviço RADIUS durante a autenticação, o tipo de EAP pode exibir a caixa de diálogo.
Além disso, você pode especificar se, depois da autenticação no nível de usuário, o sistema deve iniciar a renovação do protocolo DHCP (Dynamic Host Configuration Protocol) da configuração TCP/IP do adaptador com fio. Selecione essa opção caso haja VLANs (LANs virtuais) separadas para clientes sem fio autenticados no nível de computador e usuário e se essas VLANs forem sub-redes IPv4 ou IPv6 diferentes.

Suporte a script com a ferramenta Netsh
O Windows Server 2008 e o Windows Vista são compatíveis com comandos no contexto netsh lan da ferramenta para a definição de configurações com fio ou exportação ou importação de um perfil com fio, que é um conjunto nomeado de configurações com fio no formato XML. Com a configuração da linha de comando das configurações com fio, você poderá implantar mais facilmente redes com fio ao criar scripts automatizados para configurações com fio sem usar a Diretiva de grupo. As configurações da Diretiva de grupo da rede com fio (IEEE 802.3) aplicam-se somente ao domínio Active Directory. Para um ambiente sem uma infra-estrutura de Diretiva de grupo, um script que automatiza a configuração de conexões com fio com um perfil com fio pode ser executado manual ou automaticamente, inclusive como parte do script de logon.
Para executar a configuração da linha de comando de clientes com fio executando o Windows Vista ou o Windows Server 2008, execute comandos netsh lan com os parâmetros apropriados. Por exemplo, o seguinte comando habilita o Logon único da conexão de rede nomeado “Conexão de área local” e configura o logon único para que execute a autenticação do usuário antes do logon do usuário:
netsh lan set profileparameter interface="Local Area Connection" ssomode=prelogon
Para obter mais informações sobre a sintaxe do comando netsh lan, consulte technet.microsoft.com/aa905084.
Os perfis XML com fio podem ser exportados a partir de um cliente com fio do Windows Server 2008 ou Windows Vista e então importados para um cliente com fio do Windows Server 2008 ou Windows Vista usando a ferramenta Netsh. Para exportar um perfil com fio, use o comando de perfil de exportação netsh lan. Se você quiser importar um perfil com fio, use o comando de perfil de acréscimo netsh lan. Para obter alguns exemplos úteis de perfis com fio, consulte msdn2.microsoft.com/aa816372.
Com a linha de comando e o suporte a perfil XML, você pode inicializar um cliente com fio na rede com fio autenticada com 802.1X da organização. Um computador cliente com fio que não for membro do domínio não poderá se conectar à rede com fio usando credenciais do computador. Além disso, um computador não pode ingressar no domínio até que tenha se conectado com êxito à rede com fio. No entanto, a linha de comando e o suporte a perfil XML permitem que um computador com fio se conecte à rede com fio da organização usando credenciais de usuário e, em seguida, ingresse o computador no domínio. Para obter mais informações, consulte technet.microsoft.com/bb727031.

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


 Windows PowerShell: Permiss&#245;es Shell
Windows PowerShell
Permissões Shell
Don Jones
Faça download do código deste artigo: PowerShell2008_02.exe (151KB)

Ao discutir o Windows PowerShell, muitas vezes me perguntam sobre permissões, especialmente se e como o shell permite a automação de alterações a permissões. Permissões de arquivo são, talvez, a solicitação mais comum, embora permissões de diretório e registro também surjam com freqüência. Em se tratando de permissões e de quase
todas as interfaces de linha de comando ou script (incluindo o Windows PowerShellTM e o VBScript), tenho boas e más notícias.
As más notícias são que as permissões no Windows® são simplesmente intrinsecamente complicadas e não há muito o que o Windows PowerShell possa fazer para corrigir isso. O problema tem origem no fato de, em um sistema operacional Windows, há vários objetos em se tratando de permissões, independentemente de se você está examinando o sistema de arquivos, o Active Directory®, o registro ou quase qualquer outra coisa.
Em primeiro lugar, há o recurso em si—por exemplo, um objeto de diretório, arquivo ou pasta. Em seguida, há o objeto da ACL (Lista de Controle de Acesso), que está anexado ao recurso. A ACL consiste em uma ou mais Entradas de Controle de Acesso, ou objetos ACE. Uma ACE essencialmente vincula uma entidade de segurança (um usuário ou grupo, que é outro objeto) a uma permissão (como de Leitura ou Controle Total) e a um status Conceder ou Negar. Há não menos do que cinco objetos: o recurso, a ACL, uma ACE, uma entidade e uma permissão.
As permissões são ainda mais complicadas pelo fato de que todo tipo de recurso tem diferentes tipos de permissão. Objetos de diretório, por exemplo, têm permissões complexas governando o acesso a atributos de objeto individuais. Permissões de arquivo são relativamente pouco complicadas, em comparação.
E, tecnicamente, tudo isso é duplicado em se tratando de auditorias. Cada recurso tem, na verdade, duas ACLs. Em primeiro lugar, há a DACL (Lista de Controle de Acesso Condicional), que governa o acesso ao recurso. Em segundo lugar, há a SACL (Lista de Controle de Acesso de Segurança), que controla a auditoria do recurso. Tentar trabalhar com essas permissões significa lidar com uma pilha de objetos de programação razoavelmente complicados e há um limite para o que um shell como o Windows PowerShell pode fazer para simplificar isso para você.

Limitado pelo .NET Framework
Ainda quer mais?
Para obter mais recursos do Windows PowerShell, incluindo uma biblioteca pesquisável de cmdlets, e para conectar-se com Don Jones e outros especialistas em Windows PowerShell, visite www.PowerShellCommunity.org.

A natureza do Windows PowerShell torna as coisas um pouco mais complicadas. Por ser baseado no Microsoft® .NET Framework, o Windows PowerShell usa as classes subjacentes do .NET Framework para representar e trabalhar com permissões. Essas classes subjacentes do .NET Framework foram criadas para fornecer aos desenvolvedores de software um controle granular e preciso sobre as permissões. É claro, "granular e preciso" significa muita informação e muitas vezes é traduzido como "muito complicado".
Além disso, o .NET Framework não fornece classes que representem as permissões de todos os tipos de recursos do Windows. Por exemplo, enquanto o .NET Framework fornece classes que permitem a manipulação da segurança dos arquivos, ele não fornece classes que permitem o trabalho com a segurança em pastas compartilhadas. O resultado é que o Windows PowerShell não pode manipular permissões em todos os tipos de recursos do Windows. Simplificando, o Windows PowerShell é limitado às capacidades oferecidas pelo .NET Framework.

Permissões no Shell
O gerenciamento de permissões no Windows PowerShell é derivado de dois cmdlets: Get-ACL e Set-ACL. Como esperado, Get-ACL recupera a ACL de um recurso. É possível modificar a ACL para atender às suas necessidades e usar Set-ACL para gravá-la novamente no recurso. Esses dois cmdlets são genéricos e recorrem ao sistema do Windows PowerShell de fornecedores PSDrive. Portanto, esses dois cmdlets ACL poderiam, teoricamente, trabalhar com qualquer tipo de recurso, desde que haja um fornecedor PSDrive capaz de compreender um tipo de recurso específico e de modificar as suas permissões. Os fornecedores PSDrive FileSystem e Registry, que estão incluídos no Windows PowerShell, oferecem suporte ao gerenciamento de permissões por meio de dois cmdlets ACL. (Outros fornecedores PSDrive podem não oferecer esse suporte).
O script de exemplo mostrado na Figura 1 permite especificar um diretório inicial, uma entidade de segurança e uma permissão. O script aplica a permissão especificada para aquela entidade para todos os arquivos e pastas dentro do diretório especificado. O script pesquisa de forma recursiva os subdiretórios também.
Figure 1 Aplique uma permissão de uma entidade a arquivos e pastas em um diretório (Close Figure 1)
#ChangeACL.ps1
$Right="FullControl"

#The possible values for Rights are
# ListDirectory, ReadData, WriteData
# CreateFiles, CreateDirectories, AppendData
# ReadExtendedAttributes, WriteExtendedAttributes, Traverse
# ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes
# WriteAttributes, Write, Delete
# ReadPermissions, Read, ReadAndExecute
# Modify, ChangePermissions, TakeOwnership
# Synchronize, FullControl

$StartingDir=Read-Host "What directory do you want to start at?"
$Principal=Read-Host "What security principal do you want to grant" `
"$Right to? `n Use format domain\username or domain\group"

#define a new access rule.
#note that the $rule line has been artificially broken for print purposes.
#it needs to be one line. the online version of the script is properly
#formatted.
$rule=new-object System.Security.AccessControl.FileSystemAccessRule
($Principal,$Right,"Allow")

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  $acl=get-acl $file.FullName

  #Add this access rule to the ACL
  $acl.SetAccessRule($rule)

  #Write the changes to the object
  set-acl $File.Fullname $acl
  }
A parte suculenta desse script é onde ele define uma nova regra de acesso na variável $rule. Para fazer isso, estou usando uma classe do .NET Framework “crua”, que é talvez a parte mais complicada do gerenciamento de permissões no Windows PowerShell. Em seguida, o script recupera a ACL de cada arquivo e pasta separadamente, usando Get-ACL, aplica a nova regra usando o método SetAccessRule da ACL e grava a ACL modificada de volta no recurso usando Set-ACL.
Na realidade, isso não é tão complicado, embora operações mais complexas como remover uma ACE de uma ACL envolvam mais. Em minha opinião, o que faz parecer complicado é o fato de haver tantas etapas envolvidas: obter a ACL, definir uma regra, modificar a ACL e gravar a ACL. Não é um comando único e limpo que faz tudo de uma vez. E como eu desejava modificar as ACLs em vários arquivos, tive de juntar tudo em um loop foreach, usando Get-ChildItem para acessar todos os arquivos e pastas.

Farei da maneira mais fácil
Cmdlet do mês: Get-QADUser
Esse cmdlet é obrigatório se você gerencia um Active Directory. Ele não é interno no Windows PowerShell, mas está disponível para download gratuito como parte do ActiveRoles Management Shell for Active Directory da Quest Software (www.quest.com/activeroles-server/arms.aspx).
Depois de instalar o snap-in, é possível usar o Get-QADUser para recuperar objetos de usuário do diretório. Claro, simplesmente executar o cmdlet retorna todos os seus usuários, o que não é exatamente útil para a maioria das tarefas administrativas. Mas o cmdlet permite a especificação de critérios de filtragem, que são aplicadas no controlador de domínio para que somente os usuários com os quais você estiver preocupados sejam realmente retornados ao Windows PowerShell. Essa é uma técnica muito mais rápida do que obter todos os usuários e, em seguida, filtrá-los com o cmdlet Where-Object. Por exemplo, Get-QADUser -l Redmond retornará somente os usuários cujo atributo "l" contenha "Redmond." (A propósito, o atributo "l" signifca localidade e é listado como cidade na GUI). É possível canalizar esses usuários para outros cmdlets para gerar um relatório em HTML, colocá-los em um grupo ou mesmo excluí-los.

Não acho que o meu exemplo seja complexo, mas sei que muitos administradores prefeririam uma maneira mais simples de trabalhar com permissões. Talvez eles desejem remover um grupo de usuários de um conjunto de pastas todos de uma vez mas não desejam escrever um script de várias etapas como o mostrado na Figura 1.
Felizmente, o Windows PowerShell oferece um meio simplificado de trabalhar com permissões e você provavelmente já o conhece.
O Windows PowerShell não faz você desistir das maneiras famosas de fazer as coisas. É possível usar ainda as ferramentas de linha de comando—como Dsacls.exe, Cacls.exe e Xcacls.exe—que foram desenvolvidas especificamente para fornecer uma maneira mais simples de trabalhar com vários tipos de permissões. Embora sua sintaxe seja completamente diferente da sintaxe padronizada usada pelos cmdlets do Windows PowerShell, esses utilitários de linha de comando não precisam mais ser usados em uma maneira ad hoc na linha de comando como eram usadas no antigo shell cmd.exe. E é possível usar o Windows PowerShell para automatizar esses utilitários.
Eu encontrei alguns caras—os chamarei de "puristas"—que insistem que usar um utilitário de linha de comando antigo dentro do Windows PowerShell é, de alguma forma, errado. Não entendo sua lógica. Sou a favor que o trabalho seja feito e se a maneira mais fácil for usar um utilitário de linha de comando de 10 anos, é o que farei. Não gastarei horas a mais tentando fazer algo de uma determinada maneira somente porque parece "mais pura". E a equipe do Microsoft Windows PowerShell tem uma atitude semelhante. Se uma ferramenta existente faz o trabalho, deixe o Windows PowerShell usar essa ferramenta dentro do shell. Para quê reinventar a roda?
A Figura 2 mostra um script curto—retirado do meu livro Windows PowerShell: TFM (SAPIEN Press, 2006)—que usa o Windows PowerShell para automatizar o Cacls.exe. Esse script é somente uma demonstração, o que significa que você precisará ajustá-lo se desejar torná-lo uma ferramenta de automação real. Mas ele mostra como um script do Windows PowerShell pode coletar informações e usá-las para iniciar o Cacls.exe, como se o Cacls.exe fosse um comando "nativo" do Windows PowerShell. (Embora esse script colete informações solicitando-as ao usuário, os parâmetros poderiam ser lidos de um arquivo ou banco de dados).
Figure 2 Automatize o Cacls.exe (Close Figure 2)
#SetPermsWithCACLS.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir=Read-Host "What directory do you want to start at?"
$Right=Read-Host "What CACLS right do you want to grant? Valid choices are F, C, R or W"
Switch ($Right) {
  "F" {$Null}
  "C" {$Null}
  "R" {$Null}
  "W" {$Null}
  default {
    Write-Host -foregroundcolor "Red" `
    `n $Right.ToUpper() " is an invalid choice. Please Try again."`n
    exit
  }
}

$Principal=Read-Host "What security principal do you want to grant?" `
"CACLS right"$Right.ToUpper()"to?" `n `
"Use format domain\username or domain\group"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Right.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

 foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  #display filename and old permissions
  write-Host -foregroundcolor Yellow $file.FullName
  #uncomment if you want to see old permissions
  #CACLS $file.FullName

  #ADD new permission with CACLS
  CACLS $file.FullName /E /P "${Principal}:${Right}" >$NULL

  #display new permissions
  Write-Host -foregroundcolor Green "New Permissions"
  CACLS $file.FullName
 }
}

Sucesso com as Permissões?
Ouvi argumentos que diziam que o Windows PowerShell deixa a desejar em se tratando de permissões porque não fornece um cmdlet nativo que ofereça gerenciamento de permissões simplificado e universal. Eu não concordo. Em primeiro lugar, esse argumento é, muitas vezes, dito por administradores com antecedentes fortes em UNIX e o fato é que o sistema de permissões do Windows é extremamente mais complicado do que o usado no UNIX. Ao expor esse sistema, o Windows PowerShell também será complicado. No entanto, esse não é um problema do Windows PowerShell.
Além disso, o Windows PowerShell permite o uso de ferramentas simplificadas na forma dos velhos e bons utilitários de linha de comando, como demonstrei aqui. É verdade, o .NET Framework precisa de alguma expansão para abordar mais profundamente o gerenciamento de permissões na plataforma Windows inteira. Mas no geral, o Windows PowerShell oferece a você os dois mundos: gerenciamento de permissões simplificados bem como acesso a ferramentas de gerenciamento granulares e precisas.

Don Jones é editor-colaborador da TechNet Magazine e co-autor de Windows PowerShell: TFM (SAPIEN Press, 2007). Ele é professor de Windows PowerShell (consulte www.ScriptingTraining.com) e pode ser contatado pelo site www.ScriptingAnswers.com.


 Ei, Equipe de Scripts!: Os jogos v&#227;o come&#231;ar! Ah, e algum XML tamb&#233;m
Ei, Equipe de Scripts!
Os jogos vão começar! Ah, e algum XML também
The Microsoft Scripting Guys
Faça download do código deste artigo: HeyScriptingGuy2008_02.exe (151KB)

Sabe, sempre que as pessoas falam sobre as lendas do mundo esportivo, os mesmos nomes invariavelmente surgem: Babe Ruth. Pelé. Muhammad Ali. Walter Payton. ScooterK e MrRat. Johnny—
Ha, isso foi engraçado, você... ah, você está falando sério? Você realmente não sabe quem são ScooterK e MrRat? Bem, para aqueles que obviamente não acompanham os Jogos de Script de Inverno (de 15 de fevereiro a 3 de março no TechNet Script Center; visite microsoft.com/technet/scriptcenter/funzone/games), ScooterK e MrRat são verdadeiras lendas, competidores que atingiram pontuações perfeitas em ao menos uma divisão dos Jogos de Script de Inverno de 2007.
E aqui está a melhor parte: você realmente tem esperanças realistas de se tornar uma lenda do futebol como o Pelé? Provavelmente não. Você poderia ter esperanças em se tornar o campeão do mundo de boxe peso-pesado? Bem, alguns dos membros da Equipe de Scripts parecem entender da parte peso-pesado, mas ser campeão de boxe é algo muito mais complicado. Mas você—sim, você—pode facilmente se tornar o próximo ScooterK ou o próximo MrRat.
Observação: em teoria, você poderia se tornar o próximo Babe Ruth também. Tudo o que você precisaria fazer seria comer 24 cachorros-quentes entre os jogos de baseball.
Acalme-se; nós diremos como você pode se tornar o próximo ScooterK ou MrRat (e talvez até mesmo o próximo Bizzy ou H2Data). Você só precisa aparecer no Script Center e participar dos Jogos de Script. No dia 15 de fevereiro publicaremos 10 eventos diferentes (10 desafios de script) e desafiá-lo a concluir um ou todos eles. Escreva um script que resolva o problema proposto e envie por email para a Equipe de Script. (Você encontrará as instruções completas na home page dos Jogos de Script). Testaremos o seu script e, se funcionar, computaremos os seus pontos. Conclua com êxito todos os 10 eventos e você também se tornará uma lenda do mundo esportivo. Ou ao menos no mundo esportivo dos scripts, o que é quase a mesma coisa.
Os Jogos de Script (de 15 de fevereiro a 3 de março) são divertidos e desafiadores. O melhor de tudo é que os Jogos de Script são para todos. Você ainda é relativamente novato em scripts de administração do sistema? Então participe da Divisão de Iniciantes; teremos competições separadas para iniciantes em VBScript, Windows PowerShellTM e (novidade este ano) Perl. Você acha que a Divisão de Iniciantes é fácil? Então participe da Divisão de Avançada, que também tem competições em VBScript, Windows PowerShell e Perl.
Os Jogos (já mencionamos que ocorrerão entre o dia 15 de fevereiro e 3 de março?) são simplesmente o evento da temporada de scripts, e você não vai querer perdê-lo. Visite a home page do Script Center agora para obter dicas e truques para treinar para a competição, e volte no dia 15 de fevereiro quando os Jogos começarão oficialmente.
Dia 15 de fevereiro ao dia 3 de março. Caso você não tenha percebido.
O quê? Na verdade, concordamos com você: criar uma nova coluna do Ei, Equipe de Scripts! além do anúncio sobre os Jogos de Script é, provavelmente, muita empolgação para um mês só. No entanto, para manter os caras da TechNet Magazine felizes (nossa meta principal na vida, não é necessário dizer), decidimos arriscar e criar uma nova coluna de qualquer maneira.
Exatamente um ano atrás (uau, já faz assim tanto tempo?), publicamos uma coluna que explicava como usar um script para ler um arquivo XML. O que aquela coluna não dizia era como usar um script para criar, gravar e modificar um arquivo XML. Este mês, estamos corrigindo isso. Você diz que gostaria de saber como escrever um script que possa criar um arquivo XML? Tudo o que você tinha de fazer era perguntar. Bem, perguntar e esperar um ano para que respondêssemos. A Figura 1 mostra o script. Com certeza isso parece complicado, mas explicaremos como tudo isso funciona.
Figure 1 Criando um arquivo XML (Close Figure 1)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName

Set objDate = _
  xmlDoc.createElement("AuditDate")
objDate.Text = Date
objRecord.appendChild objDate

Set objIntro = _
  xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)

xmlDoc.Save "C:\Scripts\Audits.xml"
Para começar, criamos uma instância do objeto Microsoft.XMLDOM. Como você deve ter adivinhado, esse é o objeto que nos permite trabalhar com arquivos XML. Nossa meta é produzir um arquivo XML simples que se pareça com a Figura 2.
Figura 2 Nossa meta: um arquivo XML simples
Figura 2 Nossa meta: um arquivo XML simples
Para criar esse arquivo XML, a primeira coisa a ser feita é criar o nó raiz (ITChecklist). Como fazemos isso? Assim:
Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot
Essa foi bem fácil, não foi? Tudo o que precisamos fazer foi chamar o método createElement, passando para createElement o nome que desejamos dar ao nó raiz. Em seguida, simplesmente chamamos o método appendChild, passando a referência de objeto ao nosso novo elemento (objRoot) como o único parâmetro do método. Nesse ponto, temos um nó raiz.
Mas, espere; tem mais. Em seguida, criamos o nó ComputerAudit, filho do nó ITChecklist que representa a informação de um único computador. Como você pode ver, o código para a criação desse nó é semelhante ao código usado para criar o nó raiz:
Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord
A única diferença é essa: ao criar o nó raiz, chamamos appendChild no nosso próprio documento XML. (Observer a referência de objeto xmlDoc). Para adicionar um nó filho à raiz, chamamos appendChild no nó raiz (objRoot) em vez do documento XML. É muito fácil.
É fácil também adicionar os nós ComputerName e AuditDate como nós filho do ComputerAudit. Para fazer isso, vamos passar por um processo semelhante: chamaremos createElement para criar o novo nó e chamaremos appendChild para anexar esse novo nó ao arquivo.
(Pergunta rápida: de onde chamamos appendChild desta vez? Sim, você está certo: de objRecord, o nó pai (ComputerAudit) que acabamos de criar).
Ah, e como os nós ComputerName e AuditDate precisam conter valores, é importante especificar um valor para a propriedade Text de cada nó antes de adicioná-los ao documento.
Tudo deve ficar mais claro depois de examinarmos o código que realmente cria o nó ComputerName:
Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName
Como esperado, o código para a criação de AuditDate é quase idêntico. Precisamos somente especificar um nome de nó diferente ao chamar createElement e atribuir um valor diferente para a propriedade Text.
Cara, estamos tornando as coisas fáceis demais para todos, não acha?
Depois de concluir a criação dos nós do nosso primeiro (e único, nesse caso) registro, executamos este lindo bloco de código:
Set objIntro = _
 xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)
Isso simplesmente insere a marca <?xml version="1.0" ?> ao início do arquivo, assegurando que temos um documento XML bem formado.
Nesse ponto, tudo o que nos resta fazer é chamar o método Save e salvar o nosso novo arquivo como C:\Scripts\Audits.xml:
xmlDoc.Save "C:\Scripts\Audits.xml"
Assim, de repente, temos um documento XML novo em folha.
Agora, isso é realmente útil: você sabe como criar um arquivo XML novo em folha usando um script. Naturalmente, as chances são grandes de que, na maior parte do tempo, você não precise realmente criar um arquivo XML novo em folha; em vez disso, você simplesmente anexa novos dados a um arquivo existente. Então, será que a Equipe de Scripts mostrará a todos como fazer isso?
Sabe, decidimos originalmente que a resposta a essa pergunta seria não, não mostraremos a todos como anexar dados a um arquivo XML existente. E então, sendo pessoas boas e generosas, decidimos tentar e fazer um acordo com os leitores da TechNet Magazine: se todos que estiverem lendo esta revista concordarem em participar dos Jogos de Script de Inverno de 2008, em troca mostraremos a todos como usar um script para anexar dados a um arquivo XML. Então, todos concordam em participar dos Jogos de Script?
Hum, esperamos por você. Sim, você—o cara em Rochester, MN.
Sim, assim é melhor. E acredite, nos divertimos muito durante os Jogos de Script; todos sempre se divertem. Nós prometemos.
E agora, como um acordo é um acordo, mostraremos um script que anexa dados a um arquivo XML existente. Observe a Figura 3.
Figure 3 Anexando a um arquivo XML (Close Figure 3)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set objRoot = xmlDoc.documentElement

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objFieldValue = _
  xmlDoc.createElement("ComputerName")
objFieldValue.Text = "atl-ws-100"
objRecord.appendChild objFieldValue

Set objFieldValue = _
  xmlDoc.createElement("AuditDate")
objFieldValue.Text = Date
objRecord.appendChild objFieldValue

xmlDoc.Save "C:\Scripts\Audits.xml"
Como você pode ver, não é extremamente diferente do script que criou o arquivo XML. Começamos criando uma instância do objeto Microsoft.XMLDOM e definindo a propriedade Async como False, o que informa ao script que desejamos carregar o documento de forma síncrona em vez de assíncrona. E daí? Bem, se carregarmos o documento de forma assíncrona, o script ficaria livre para continuar mesmo que o documento não estivesse totalmente carregado. Não é necessário dizer que problemas podem surgir se você tentar realizar uma tarefa em um documento que ainda não existe. Ao certificar-se de que o nosso arquivo XML é carregado de forma síncrona, também nos certificamos de que o arquivo será totalmente carregado antes que o script prossiga.
Por falar em totalmente carregado—bem, deixe pra lá; vamos deixar essa passar. Em vez disso, chamaremos o método Load para abrir o arquivo C:\Scripts\Audits.xml. Assim que o arquivo for aberto, usamos essa linha de código para criar uma instância da classe documentElement, que tem o efeito de ligar-nos à raiz do documento. Nesse caso, é claro, ela é o nó ITChecklist:
Set objRoot = xmlDoc.documentElement
Desse ponto em diante, tudo vai ladeira abaixo. Chamamos uma nova instância do nó ComputerAudit, usando o método appendChild para adicionar o novo nó ao arquivo. Em seguida, criamos novas instâncias dos nós ComputerName e AuditDate, especificando os valores apropriados (atl-ws-100 e a data atual, respectivamente) para cada novo nó. Juntamos esses dois itens dentro do novo nó ComputerAudit que acabamos de criar, chamamos o método Save para salvar o arquivo e voltamos a trabalhar nos nossos scripts para os Jogos de Script.
Jogos que, caso não tenhamos mencionado, estão programados para 15 de fevereiro a 3 de março no TechNet Script Center.
Até aqui tudo bem. Podemos criar um novo arquivo XML e podemos adicionar novos registros ao ele. Isso é muito interessante, mas ainda temos algumas coisas a fazer; por exemplo, como modificar os registros existentes no arquivo? Bem, há ao menos uma forma de fazer isso, como mostrado na Figura 4.
Figure 4 Modificando o XML (Close Figure 4)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
A parte importante desse script ocorre ao chamarmos o método selectNodes, um método que determina quais registros a nossa consulta retornará. Como você pode ver, ao chamarmos selectNodes fomos cuidadosos ao especificar dois critérios: desejamos somente registros onde o atributo ComputerName seja igual a atl-ws-100 e desejamos obter somente o atributo AuditDate.
Observação: você diz que não consegue ver como isso funciona? Então observe o nosso primeiro artigo sobre como trabalhar com arquivos XML (technetmagazine.com/issues/2007/02/HeyScriptingGuy); a sintaxe de consulta selectNodes é explicada em maiores detalhes ali.
Como é espero, selectNodes retorna uma coleção de todos os registros XML que atendem aos critérios especificados. Por sua vez, isso significa que podemos atualizar o valor do atributo AuditDate (o único atributo pelo qual pedimos) simplesmente configurando um loop For Each para percorrer todos os itens na coleção e, dentro do loop, atribuir um novo valor a AuditDate:
For Each objNode in colNodes
   objNode.Text = Date
Next
O quê? Você está imaginando se poderíamos modificar mais de um atributo por vez? Sim, poderíamos. Mas infelizmente, não hoje; isso é algo que teremos de tratar em uma coluna no futuro.
Você diz que tem outra pergunta: como atualizar a data de auditoria de todos os computadores em um arquivo? Isso é fácil; você usa o script mostrado na Figura 5.
Figure 5 Alterando a data de auditoria (Close Figure 5)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
A única diferença entre esse script e o script de modificação de XML anterior? Com este não especificamos que desejávamos exibir somente os registros onde ComputerName fosse igual a atl-ws-100. Excluindo esse critério, obtivemos todos os registros por padrão.
Vamos dar uma olhada no último script antes de terminar. Vamos supor que nosso antigo colega atl-ws-100 tenha jogado seu último jogo de Paciência e tenha sido embaralhado para o cemitério de computadores no céu.
Nota teológica: para onde vão os computadores quando morrem? Ao que parece, são geralmente dados a um dos caras da Equipe de Script. Por exemplo, o cara da Equipe de Scripts que escreve essa coluna um dia ganhou um laptop porque "você faz muitas coisas boas para a Microsoft e realmente deve ter um laptop". A única desvantagem dessa oferta generosa? O computador estava quebrado e não ligava. O que provavelmente não era um problema. Como aconteceu, ele também não tinha um disco rígido.
Para completar o grande ciclo da vida de silicone, precisamos excluir o atl-ws-100 do nosso arquivo XML. Como faremos isso? Verifique a Figura 6.
Figure 6 Excluindo do arquivo XML (Close Figure 6)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")

For Each objNode in colNodes
  xmlDoc.documentElement.removeChild _
    (objNode)
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
Como você pode ver, esse script é semelhante ao anterior, aquele que modificou a propriedade AuditDate. Há somente duas diferenças. Por um lado, observe que não nos importamos em especificar qualquer valor de propriedade na nossa consulta selectNodes; ao fazermos isso, obteríamos o registro XML inteiro para o atl-ws-100:
Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")
Em seguida, dentro do nosso loop For Each, simplesmente chamamos o método removeChild para excluir todos os registros onde ComputerName seja igual a atl-ws-100:
xmlDoc.documentElement.removeChild _
  (objNode)
E isso é tudo. Adeus, atl-ws-100; nós mal o conhecemos.
Certo, algum editor da TechNet Magazine ainda está lendo a coluna deste mês? Você diz que todos foram tentar o quebra-cabeça de script mensal? Excelente. Agora que não há ninguém lendo sobre nossos ombros, podemos dizer isso: deixe de lado o que você estiver fazendo (como, digamos, ler esta revista), venha para o Script Center e comece a se preparar para os Jogos de Script. Afinal, a TechNet Magazine estará aqui por muito tempo. Mas os Jogos de Script acontecem somente uma vez por ano e por tempo limitado (especificamente, de 15 de fevereiro a 3 de março, pra você ficar sabendo). Não perca!
Observação: sabe, agora que você mencionou, nós esperamos até que você lesse nossa coluna inteira antes de falar para você parar de ler a TechNet Magazine, não foi? Ficamos imaginando como isso foi acontecer...

O desafio de script do Dr. Scripto
O desafio mensal que testa não apenas sua habilidade de resolver quebra-cabeças, mas também de criar scripts.

Fevereiro de 2008: Símbolos misteriosos
O teclado do computador inclui todo tipo de caracter estranho; ainda mais estranho é o fato de que a maior parte desses caracteres têm um uso específico nas linguagens de script VBScript ou Windows PowerShell. Confira se você consegue corresponder cada símbolo ao seu uso em scripts. O primeiro está pronto para você.

O desafio de script do Dr. Scripto
Resposta: Símbolos misteriosos, fevereiro de 2008

The Microsoft Scripting Guys trabalham para a — bem, são empregados da — Microsoft. Quando não estão jogando/treinando/assistindo beisebol (e diversas outras atividades), eles administram o Script Center da TechNet. Confira no site www.scriptingguys.com.


 Security Watch: Saltos de ilha: redu&#231;&#227;o de depend&#234;ncias indesej&#225;veis
Security Watch
Saltos de ilha: redução de dependências indesejáveis
Jesper M. Johansson

Na última edição de Security Watch, abordei as etapas iniciais do uso de uma unidade flash USB para atacar uma rede. O ataque foi iniciado com a conexão de uma unidade flash USB infectada a um computador. Em seguida, o código malicioso foi executado automaticamente ou com mínima ajuda do usuário (fazendo uso de uma simples
engenharia social). Esse ataque permaneceu local à estação de trabalho, mas é evidente que o malware poderia se disseminar para o restante da rede. Abordo detalhadamente essa forma de ataque em uma rede no meu próximo livro, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008) e estou adaptando parte de um capítulo para esta coluna.
Obviamente, uma opção de proteção é proibir o uso de unidades removíveis. Embora possa parecer prudente, os usuários irão detestá-lo se você tentar fazer isso; e será complicado culpá-los por isso. A melhor opção, em todos os ambientes, com exceção dos mais confidenciais, é tentar administrar o risco envolvido e conter a exposição.
Além disso, as unidades removíveis são certamente o único método de comprometer um computador cliente. Você está lembrado das "10 Leis Imutáveis de Segurança" (disponíveis em microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)? Bem, o sentido geral da Lei 3 ainda é válido: "Se uma pessoa mal-intencionada tiver acesso físico irrestrito ao seu computador, o computador não é mais seu". No contexto desta discussão, se um invasor tiver acesso ao seu computador, esse computador deverá ser considerado comprometido. Isso pode ser realizado até mesmo remotamente se o invasor conseguir fazer com que você execute o código dele no seu computador. Você pode reconhecer isso como a Lei Imutável número 1: “Se uma pessoa mal-intencionada conseguir persuadi-lo a executar um programa em seu computador, o computador não é mais seu”.
É seguro pressupor que as leis imutáveis ainda são válidas – elas se mostraram extremamente flexíveis e é improvável que sejam alteradas de modo signicativo enquanto não alterarmos fundamentalmente o modo como os computadores funcionam. Então, considerando como essas leis se aplicam ao cenário descrito, é fundamental que você remova unidades removíveis. Além disso, você pode fazer isso com alguns ajustes do Registro.
É claro,você também deve usar camadas adicionais de proteção. Você pode pressupor razoavelmente que muitos de seus computadores cliente já foram comprometidos ou são operados por usuários que nem sempre consideram os melhores interesses de segurança da organização. Isso significa que você precisa reduzir esses efeitos no restante da rede e, assim, aumentar a importância da compreensão, da análise e da redução de dependências de segurança.

Definição de uma dependência de segurança
Uma dependência de segurança ocorre quando a segurança de um computador é dependente da segurança de outro. Você já deve ter ouvido alguém falar que se o seu DC (controlador de domínio) for atacado, toda a sua rede também será atacada. Essa é uma forma simplista de afirmar que todos os membros do domínio são dependentes nos DCs de sua segurança. Se o DC não for mantido seguro, os computadores membro não poderão ser mantidos seguros. Se um invasor puder alterar a configuração de segurança do domínio, ele poderá assumir qualquer computador no domínio ao, por exemplo, adicionar novas contas ao grupo de administradores em um computador membro. Qualquer vulnerabilidade que permitir comprometimento por um administrador não é nada interessante. Um administrador deve ter acesso total ao que quer que seja que ele esteja administrando.
As dependências nos sistemas de computador são inevitáveis. Na realidade, elas são comuns e freqüentemente desejáveis; no entanto, isso não significa que todas as dependências sejam aceitáveis. Nesta coluna, abordo quais tipos de dependências são aceitáveis e quais não o são; em seguida, analisarei os tipos de dependências e como reduzi-las. No Windows Server 2008 Security Resource Kit, abordo em mais detalhes as dependências específicas e como gerenciá-las.

Dependências aceitáveis
Em geral, uma dependência é aceitável quando um sistema menos confidencial depende de um sistema mais confidencial para segurança. Os computadores e sistemas em geral podem ser divididos em classes com base em seu nível de sigilo. (O conjunto específico de classes em qualquer ambiente específico é irrelevante para a discussão geral – tudo o que é importa é que há classificações inerentes.) Apenas para nossa discussão, vamos supor que tenho duas classificações: estações de trabalho e DCs. Nesse cenário, é aceitável que as estações de trabalho dependem de DCs para sua segurança. A classe de DCs é muito mais confidencial do que as estações de trabalho; portanto, obviamente, essa deve ser mais bem protegida.
O mesmo argumento pode ser feito para contas de usuários. É aceitável que um administrador possa comprometer os dados de propriedade de um usuário. Isso ocorre devido ao fato de os administradores terem mais responsabilidade e acesso irrestrito (embora nem sempre direto ou evidente) ao computador e a tudo que há nele. Se você compreender esse ponto e gerenciar os computadores adequadamente, não haverá nada de errado com essa dependência.
Até mesmo o software pode ser analisado da mesma forma. É certamente aceitável para uma parte menos confidencial do software, como um navegador da Web, que use e dependa de uma parte mais confidencial do software, como o sistema operacional, para sua segurança. Se o SO tiver um bug, o fato de o navegador da Web agora estar vulnerável a algum novo problema não será nenhuma surpresa e provavelmente está no final da lista de preocupações imediatas – o SO e outros dados e aplicativos críticos serão o foco principal de atenção. Isso tem a ver com como os bugs são corrigidos ou onde são instalados hotfixes – um bug deve ser corrigido o máximo possível do problema. Ao fazer isso, o impacto de proteção da correção é maximizado. Portanto, em vez de trabalhar para resolver o problema no navegador da Web, o próprio SO deverá ser corrigido.
Como alternativa, a dependência poderá ser removida alterando-se o projeto. Por exemplo, o navegador da Web poderá ser reescrito para reduzir suas dependências no SO. Essa última abordagem é apropriada nos casos em que a funcionalidade de componentes mais seguros (o SO, nesse caso) nunca tiver sido planejada para de fato ser usada da forma como o componente menos confidencial (o navegador da Web) a está utilizando.

Dependências inaceitáveis
Em decorrência da minha explicação de dependências aceitáveis, a definição de uma dependência inaceitável agora deveria ser óbvia. Basicamente, um sistema mais confidencial nunca deve depender de um sistema menos confidencial para sua segurança.
Se o comprometimento de uma estação de trabalho significar que a segurança do DC foi violada, você terá um sério problema de segurança em mãos. É impossível proteger uma rede se sua segurança agregada for dependente da segurança de cada computador nessa rede.
Considere isso estatisticamente. Se cada computador na rede estiver “seguro” 99,999% do tempo, você poderá achar que tem uma rede extremamente segura. Na realidade, esse percentual está provavelmente muito longe do que é a realidade em todas, exceto as menores redes hoje em dia. Agora, vamos supor que a sua rede tenha 40 mil computadores, qualquer um deles sendo vulnerável em 0,001% do tempo. Curiosamente falando, a sua rede geral estaria desprotegida em um potencial de até 40% do tempo.
E, é claro, com dependências não gerenciadas, é necessário apenas um computador nesse 0,001% de tempo para comprometer toda a rede. Nesses termos, o quão segura é a rede? É claro que é absolutamente fundamental que sistemas mais confidenciais estejam protegidos dos menos confidenciais.
Esse argumento pode ser facilmente ampliado para contas de usuários e software. Por exemplo, o novo cliente de Serviços de Terminal para Windows® permite que você armazene nomes e senhas de usuários para logon de Serviços de Terminal praticamente transparente. Essas credenciais são armazenadas usando a API do Credential Manager, protegidas pelas credenciais usadas para a sessão principal de logon.
Isso pode criar uma dependência de segurança. Considere o caso de uma administradora de rede fazendo logon em sua estação de trabalho pessoal. Ela usa essa estação de trabalho para email, navegação na Web e outras tarefas características de operadores de informações. Naturalmente, ela usa uma conta de domínio com poucos privilégios para esse fim.
Em algum momento durante o dia, essa administradora se conecta a um dos DCs para realizar determinadas tarefas de gerenciamento. Ela usa o cliente de Serviços de Terminal para fazer isso e escolhe armazenar sua senha para facilitar futuras conexões. Isso resulta em pelo menos uma, e possivelmente duas, dependências de segurança não aceitáveis. A primeira é que suas credenciais de conta administrativa de domínio agora são protegidas por suas credenciais de operadora de informações com poucos privilégios. Se essa conta de usuário com poucos privilégios for comprometida, a conta de usuário administrativo de domínio também será comprometida e, portanto, todo o domínio será comprometido.
A segunda dependência resulta do fato de que ela digitou uma credencial administrativa de domínio em um controlador que não é de domínio. A não ser que a estação de trabalho pessoal dela esteja tão protegida quanto os DCs – e provavelmente não está – haverá uma dependência na qual a segurança dos DCs dependerá da segurança dessa estação de trabalho pessoal do usuário. Se, por exemplo, um funcionário insatisfeito no mesmo escritório tiver instalado um agente de log de pressionamentos de tecla na estação de trabalho do administrador da rede, as credenciais administrativas de domínio agora teriam sido capturadas. A qualquer momento que digitar uma credencial administrativa de domínio em um controlador que não seja de domínio, você estará expondo todo o domínio a quaisquer falhas de segurança no controlador que não for de domínio.
Suponha agora que um invasor insira uma unidade removível em um computador no qual o administrador de domínio esteja atualmente conectado ou já tenha efeito logon ou até mesmo no qual efetuará logon. Esse administrador de domínio será comprometido e, por extensão, todo o domínio será comprometido. É fundamental que você compreenda essa situação para que possa evitá-la. E, é claro, a mesma situação pode acontecer com software quando um aplicativo seguro depender da funcionalidade de um aplicativo menos seguro para realizar determinada tarefa.

Análise de um ataque
Anteriormente, descrevi o que pode acontecer se uma unidade removível maliciosa for inserida em um computador. No entanto, talvez somente seja óbvio o que aconteceria ao computador no qual a unidade foi inicialmente inserida. Portanto, vamos supor que o computador em questão seja integrado ao domínio, conforme mostra a Figura 1.
Figura 1 Dependências ideais de domínio
Figura 1 Dependências ideais de domínio
O cenário ilustrado aqui descreve uma dependência ideal. As setas são direcionais e indicam de onde a dependência é herdada. Por exemplo, a segurança da estação de trabalho depende da segurança do DC e a segurança do usuário é dependente da segurança da estação de trabalho. O invasor poderá comprometer a estação de trabalho, que poderia comprometer todas as informações que o usuário tiver inserido nessa estação de trabalho, mas o comprometimento nesse caso seria isolado.
Mas vamos supor que o usuário efetuando logon na estação de trabalho seja um membro do grupo de administradores locais no servidor. Além disso, digamos que o administrador do domínio faça freqüentemente logon no servidor. Agora, você terá as dependências mostradas na Figura 2.
Figura 2 Dependências de domínio comprometidas
Figura 2 Dependências de domínio comprometidas
Ao simplesmente alterar a pressuposição de quem efetuou logon nos computadores em questão, a segurança de toda a rede pode ter sido comprometida. Como um administrador de domínio efetuou logon no servidor, a segurança do DC e, portanto, de todo o domínio é dependente da segurança desse servidor.
Isso seria aceitável se o servidor fosse gerenciado de modo tão seguro quanto o DC. No entanto, nesse caso, um usuário que efetua logon na estação de trabalho é um membro do grupo de administradores no servidor. Portanto, a segurança do servidor é dependente da segurança da estação de trabalho. Isso significa que a segurança de todo o domínio é dependente da segurança da estação de trabalho. E, adivinhe só: o usuário nessa estação de trabalho executou involuntariamente a ferramenta do invasor.
Há provavelmente alguns conceitos no atual mundo da segurança da informação que são mais importantes do que as dependências de segurança. Se você começar a analisar sua rede e tentar compreender o que são as dependências, você certamente encontrará dependências inaceitáveis. No pior cenário possível, que é muito mais comum do que você possa imaginar, a segurança de toda a rede é dependente de toda a rede – em outras palavras, a segurança de cada computador é, de alguma forma, dependente da segurança de cada computador. Portanto, é impossível criar qualquer tipo de estratégia de gerenciamento de risco razoável e realista nesse tipo de ambiente, pois as relações são impossíveis de controlar e a complexidade é incompreensível. A solução é analisar e gerenciar suas dependências.
Nesta coluna, apresentei somente uma breve visão geral das dependências e como você pode analisar e reduzi-las. Você pode encontrar mais informações no meu livro, Windows Server 2008 Security Resource Kit. Ele contém um capítulo inteiro dedicado ao tópico de segurança da rede ao analisar dependências e gerenciá-las usando técnicas avançadas, como Isolamento de servidor e domínio, bem como técnicas mais comuns, como gerenciamento de conta administrativa.
Gostaria de agradecer a David LeBlanc por me ajudar a desenvolver as idéias embrionárias que resultaram nesta coluna.

Jesper M. Johansson é arquiteto de software e trabalha com questões de segurança de software, além de editor-colaborador da TechNet Magazine. Ele possui PhD em MIS (sigla em inglês para Sistemas de Gerenciamento de Informação) e mais de 20 anos de experiência em segurança.


 Os arquivos da &#225;rea de trabalho: Inicializa&#231;&#227;o dupla com o Windows XP e o Windows PE 2.0
Os arquivos da área de trabalho
Inicialização dupla com o Windows XP e o Windows PE 2.0
Wes Miller
Faça download do código deste artigo: Desktop2008_02.exe (151KB)

Nas edições anteriores de Os arquivos da área de trabalho, mencionei que o Windows PE se tornou uma ferramenta para recuperação e expliquei como usá-lo a partir de uma segunda partição. Uma consulta que recebi recentemente me fez pensar que talvez seja válido discutir um novo ponto—usar o Windows PE 2.0 e o Windows XP juntos.
Afinal, muitos de vocês podem estar usando o Windows® XP há algum tempo e o Windows PE 2.0 é a versão que a Microsoft está oferecendo suporte em avanço (observe que não haverá mais atualizações para o Windows PE 1.x).
Uma diferença importante entre o Windows PE 1.x e o 2.x é que o Windows PE 2.x pode ser inicializado por meio de uma interface de inicialização padrão (versus o método especializado que o Windows PE 1.x usa). Embora seja possível inicializar o Windows PE 1.x ou 2.x a partir de uma segunda partição, a conveniência de inicializá-lo na mesma partição em que o seu sistema operacional está instalado tem muito potencial, que discutiremos posteriormente.

Duas inicializações para o Windows
O Windows NT® sempre foi relativamente tolerante em relação a inicializações duplas. Mas como os computadores baseados em EFI (Extensible Firmware Interface) começaram a substituir os antigos IBM PC AT BIOS, a Microsoft alterou o mecanismo de inicialização do Windows para funcionar de maneira ideal com EFI e ter um mecanismo de inicialização em todas as arquiteturas. O novo mecanismo de inicialização do Windows, começando com o Windows Vista®, é chamado de Banco de dados de configuração de inicialização, ou BCD (consulte microsoft.com/whdc/system/platform/firmware/bcd.mspx). Mas se você estiver falando do antigo boot.ini ou do novo mecanismo BCD, o Windows pode geralmente inicializar outros sistemas operacionais, mesmo que isso signifique entregar o processo de inicialização para outro carregador de inicialização.
Antes de começarmos, é crítico lembrar que o Windows PE 2.0 funciona somente em sistemas que tenham compatibilidade total com ACPI (Interface de Energia e Configuração Avançada) e 384MB (em condições ideais, 512MB) de RAM. Como observei na minha coluna de maio (technetmagazine.com/issues/2007/05/DesktopFiles), sistemas não baseados em ACPI falharão em inicializar o Windows PE 2.0 e, como o Windows PE 2.0 deve ser inicializado em um RAMDisk, ele necessita que haja RAM suficiente para usar o RAMDisk, qualquer espaço temporário e todo o conjunto de trabalho da RAM. Se o seu sistema tem menos de 384MB de RAM, nem ao menos considere essa rota; use o Windows PE 1.6. Mesmo alguém com habilidade suficiente para reduzir o tamanho do Windows PE conseguiria executá-lo bem com 256MB.

Ah, os problemas que você resolverá
Agora, vamos examinar os problemas que você poderá resolver por meio da inicialização do Windows PE 2.0 da mesma partição que o Windows XP.
Recuperação total do sistema Essa é somente uma das tarefas possíveis com a inicialização do Windows PE diretamente da partição do Windows XP. Como o Windows PE 2.0 (bem como o Windows PE 1.6 antes dele) pode ser inicializado inteiramente em um RAMDisk, é possível recriar o disco inteiro—ou usar o ImageX para restaurar os arquivos do Windows XP automaticamente, uma vez que não é necessário recriar a partição inteira.
Ao permitir aos usuários a inicialização do Windows PE na inicialização, eles podem recuperar seus próprios sistemas mesmo ao trabalhar remotamente. A imagem pode vir de uma partição secundária, um compartilhamento de rede (se os usuários não puderem estar móveis), um DVD ou disco rígido USB de recuperação ou, se você estiver usando o ImageX, até mesmo armazená-la em uma partição em recuperação. Este tipo de recuperação em disco é uma ótima solução para muitos problemas (exceto para a corrupção de disco físico). Obviamente, não é a melhor para a restauração de dados de usuário, a menos que os dados estejam protegidos em primeiro lugar e então restaurados como parte da recuperação. Lembre-se de que você deve usar perfis móveis e realizar backup de dados do PC para prevenir esse tipo de perda. Você deve também certificar-se de que qualquer mecanismo de recuperação usado possa reduzir qualquer perda de dados em potencial em nome do usuário (incluindo perda devido à redefinição de chaves de criptografia EFS).
Recuperação de arquivos O Windows PE também fornece o mecanismo para colocar um sistema em execução mesmo que a instalação principal do Windows não seja inicializada. Nesse caso, é possível inicializar e recuperar os dados do usuário em outro sistema (desde que você tenha sistemas de backup recentes disponíveis para os usuários) ou em outro local para que o usuário possa começar logo a trabalhar novamente.
Reparação do sistema Finalmente, inicializar o Windows PE no Windows XP permite a reparação de um sistema por meio da execução de um conjunto de scripts de solução de problemas ou de um aplicativo simples de reparação ou recuperação controlado pelo usuário. O processo é semelhante à recuperação total do sistema, mas terá um escopo mais restrito (e não arriscará os dados do usuário).
Agora que você conhece o que é possível fazer inicializando o Windows PE na partição do Windows XP, vamos examinar o que acontece nos bastidores para que você possa aplicar o processo a qualquer solução desejada.

Antes do Windows Vista
Antes do advento do Windows Vista, era assim que os sistemas baseados em BIOS/MBR (registro mestre de inicialização) eram inicializados. O BIOS apontava para o dispositivo de inicialização (no caso do disco rígido, ele apontava para o MBR no disco). O MBR executava código que especificava qual partição inicializar. Observe que essa era a primeira partição que tivesse um sinalizador ativo definido para ela. Nas primeiras versões do diskpart, não era possível tornar uma partição inativa (ou seja, não era possível remover o sinalizador ativo). O comutador foi adicionado ao diskpart para corrigir isso—caso contrário, seria a primeira partição na ordem da tabela de partições que tivesse um sinalizador ativo definido. A partição contém o setor de inicialização—que informa qual código deve ser executado em seguida. Do Windows NT para o Windows Server® 2003, o código a ser executado está em um arquivo nomeado ntldr, sem extensão de arquivo. Se você já formatou um disco, não instalou o Windows e tentou a inicialização, viu a mensagem de erro "NTLDR not found".
Será interessante saber que o ntldr é totalmente compatível com versões anteriores—mas não é, obviamente, compatível com versões posteriores. Isso significa que o ntldr do Windows XP pode inicializar o Windows 2000, mas não o inverso. É por isso que é sempre importante instalar o sistema operacional mais antigo antes se você planeja realizar uma inicialização dupla. Como o ntldr não tem um número de versão anexado, é ainda mais importante manter isso em dia.
O ntldr é um aplicativo em modo real (16-bit) que inicia o NTDetect.com, que realiza a detecção de dispositivos básica e inicia o kernel, ntoskrnl.exe (esse pode ser um de vários arquivos—sempre renomeado para ntoskrnl.exe). O kernel é o componente crítico no processo de inicialização do Windows.
Este resumo do processe de inicialização é, de certa forma, simplista, e omiti totalmente a inicialização do Win32®, mas isso não é pertinente a esta discussão. Se você desejar obter mais informações sobre isso, recomendo a leitura do Windows Internals, Quarta Edição, de Mark Russinovich e David Solomon (Microsoft Press®, 2004).
Outra coisa a se observar é que ao inicializar do CD, a Instalação do Windows e do Windows PE executam o setupldr.bin em vez do ntldr. Esse arquivo, na verdade, contém um código de inicialização ligeiramente diferente para que possa ser inicializado a partir do CD (o ntldr não pode). Foi por isso que, para inicializar o Windows PE 1.x, você renomeou o setupldr.bin para ntldr e o colocou no disco. Foi por isso também que aquele arquivo não poderia carregar um arquivo boot.ini (pois o setupldr.bin foi desenvolvido para inicialização por CD e, como resultado, não é esperado que o boot.ini seja necessário).

Windows Vista e além
O Windows Vista mudou muitas partes desse processo. O Windows Server 2008 muda ainda mais habilitando o IA32 (suporte a 32-bit) para a inicialização a partir do EFI—algo que não era possível até agora fora dos sistemas baseados em Itanium. Para os sistemas baseados em BIOS, as etapas iniciais do processo de inicialização está basicamente inalterado. A diferença principal é que o BOOTMGR é o carregador de inicialização que é inicializado e então realiza as etapas seguintes.
Ele procura no diretório de inicialização pelo arquivo BCD, que é efetivamente o seu próprio hive de registro. O BCD contém as entradas de inicialização (incluindo a padrão) a serem inicializadas. Consulte a Figura 1 para tipos de imagem (tipos de arquivo executáveis e a Figura 2 para os tipos de aplicativo específicos a iniciar. Uma (ou mais) dessas entradas podem ser uma referência ao ntldr. Somente uma delas pode realmente fazer referência ao GUID conhecido usando para carregar o ntldr (consulte a quinta linha da Figura 3). O bootmgr decide então qual entrada será carregada a seguir, dependendo de se o sistema está sendo inicializado, se estava hibernando ou se está sendo inicializado pelo ntldr ou por outro gerenciador de inicialização (nesse caso, ele apontaria para outro setor de inicialização e iniciaria esse carregador). Isso seria mais comum se você estivesse realizando uma inicialização dupla com um sistema operacional diferente do Windows. É possível encontrar mais informações em microsoft.com/whdc/system/platform/firmware/bcd.mspx.
Figure 3 Objetos de aplicativo padrão (Close Figure 3)

Descrição | ID do BCDEdit | GUID
Gerenciador de inicialização do Windows | {bootmgr} | 9dea862c-5cdd-4e70-acc1-f32b344d4795
Firmware de gerenciador de inicialização | {fwbootmgr} | a5a30fa2-3d06-4e9f-b5f4-a01df9d1fcba
Testador de memória do Windows | {memdiag} | b2721d73-1db4-4c62-bf78-c548a880142d
Aplicativo de retomada do Windows | Sem alias | 147aa509-0358-4473-b83b-d950dda00615
Carregador herdado do Windows | {ntldr} | 466f5a88-0af2-4f76-9038-095b170dc21c
Entrada de inicialização atual | {current} | fa926493-6f1c-4193-a414-58f0b2456d1e
Entrada de inicialização padrão | {default} | sem GUID predefinida
Figure 2 Tipos de aplicativo (Close Figure 2)

Descrição | Valor | Descrição
Firmware de gerenciador de inicialização | 0x1 | Aplica-se somente a sistemas EFI.
Gerenciador de inicialização do Windows | 0x2 | Controla o fluxo de inicialização. Em um sistema de inicialização dupla, exibe para o usuário um menu de seleção de inicialização.
Carregador de inicialização do Windows | 0x3 | Carrega uma versão ou configuração específica do Windows.
Aplicativo de retomada do Windows | 0x4 | Restaura o Windows para o seu estado de execução quando um computador retorna da hibernação.
Testador de memória do Windows | 0x5 | Um aplicativo de diagnóstico de memória.
Ntldr | 0x6 | Aplica-se somente a sistemas PC/AT BIOS. Carrega as versões do Windows anteriores ao Windows Vista.
Setor de inicialização | 0x8 | Um aplicativo em modo real de 16-bit. Aplica-se somente a sistemas PC/AT BIOS. Pode ser usado para reiniciar o processo de inicialização e carregar um sistema operacional diferente do Windows.
Figure 1 Tipos de imagem (Close Figure 1)

Descrição | Valor
Aplicativo firmware | 0x1
Aplicativo de inicialização | 0x2
Objeto de carregador baseado em ntldr | 0x3
Aplicativo em modo real | 0x4
Você observará que a infra-estrutura de inicialização remodelada do Windows Vista é muito mais organizada do que as versões anteriores—fora do bootmgr, todo o código de inicialização existe dentro do nível raiz do diretório \boot e é transferido para os binários específicos do Windows uma vez que o BCD tenha especificado isso.

Inicializando o Windows XP e o Windows PE 2.0
Você provavelmente começa agora a ver como o Windows PE, usando o gerenciador de inicialização do Windows Vista, pode agir como um intermediário que permite continuar a inicializar o Windows XP ou versões anteriores do Windows enquanto adiciona o Windows PE 2.0 à mistura para uma ferramenta de recuperação integrada.
Claro, você adicionará uma outra etapa ao processo de inicialização, mas é uma etapa desenvolvida pela Microsoft. Sabendo que a nova infra-estrutura do bootmgr necessitava de compatibilidade com o ntldr existente e com outros gerenciadores de inicialização de terceiros, o bootmgr foi criado intencionalmente para oferecer suporte a essas soluções.
Agora que examinamos como o Windows é inicializado e como o novo BCD funciona, como unimos os dois e obtemos o Windows PE 2.0 na nossa instalação do Windows XP existente? Há duas maneiras de criar o setor de inicialização do Windows Vista—a parte do código de inicialização que informa ao sistema para iniciar o bootmgr. Uma delas é usar o diskpart e criar e formatar uma nova partição com o Windows PE 2.0. Mas essa não será uma opção aqui, uma vez que você já tem uma instalação do Windows XP existente que não deseja danificar ou mover. Em vez disso, siga este processo:
  1. Certifique-se de ter uma cópia do bootsect.exe e do bcdedit.exe no seu CD de inicialização do Windows PE 2.0 (os dois arquivos podem ser encontrados no seu DVD de instalação do Windows Vista).
  2. Inicialize o seu sistema Windows XP pelo CD do Windows PE 2.0.
  3. Uma vez inicializado, execute este comando:
    bootsect.exe /NT60 ALL
Isso definirá o setor de inicialização como sendo o setor de inicialização compatível com o Windows Vista que sabe como iniciar o bootmgr.
4. Copie o gerenciador de inicialização para o disco rígido:
    xcopy BOOTMGR C:\BOOTMGR /I
5. Copie o arquivo boot.SDI para o diretório \BOOT no disco rígido. Será necessário fazer uma cópia dele antes da inicialização, pois ele estará bloqueado e não poderá ser copiado enquanto executa o Windows PE:
    xcopy BOOT.SDI C:\BOOT\
Corrija o caminho de origem de acordo.
6. Copie o boot.WIM para o disco rígido. Como o SDI, você deve ter disponível uma cópia secundária; não será possível copiar o arquivo do qual você está executando:
    xcopy BOOT.WIM C:\BOOT\BOOT.WIM
Corrija o caminho de origem de acordo.
7. Agora, crie um novo armazenamento BCD:
    bcdedit /createstore
8. Em seguida, crie as entradas BCD para carregar o Windows PE:
    bcdedit /create {ramdiskoptions} /d
    "Boot Windows PE"
    bcdedit /set {ramdiskoptions}
    ramdisksdidevice partition=c:
    bcdedit /set {ramdiskoptions}
    ramdisksdipath \boot\boot.sdi
    bcdedit /create /d "Windows PE" /
    application
    OSLOADER
9. A última linha retornará um GUID. Substitua {YOURGUID} com o GUID real retornado. Essas são entradas no RAMDisk que inicializam o Windows PE do seu disco rígido, mostradas na Figura 4.
Figure 4 Entradas no RAMDisk que inicializam o Windows PE do seu disco rígido (Close Figure 4)
bcdedit /set {YOURGUID} device ramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} path \windows\system32\winload.exe
bcdedit /{YOURGUID} osdeviceramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} systemroot \windows
bcdedit /set{YOURGUID} winpe yes
bcdedit /set {YOURGUID} detecthal yes
10. Agora, crie entradas do bootmgr para que o Gerenciador de Inicialização seja iniciado:
    bcdedit /create {bootmgr} /d
    "Boot Manager"
    bcdedit /set {bootmgr} device boot
11. Finalmente, configure uma entrada BCD para a sua instalação do Windows existente (altere o texto de exibição do Windows XP para qualquer um que você deseje exeibir no menu de inicialização do gerenciador de inicialização. O último comando também a define como a primeira (padrão) entrada no menu de inicialização:
    bcdedit /create {ntldr} /d "Windows XP"
    bcdedit /set {ntldr} device partition=C:
    bcdedit /set {ntldr} path \ntldr
    bcdedit /displayorder {ntldr} /addfirst
12. Agora deve ser possível reiniciar o seu sistema e iniciar a instalação anterior do Windows ou o Windows PE 2.0 selecionando a entrada de menu de atualização adequada. A Figura 5 mostra a saída de exemplo de bcdedit /enum all. Esse comando lista todas as entradas no BCD depois que as entradas foram adicionadas (de dentro do Windows PE 1.6).
Entrada de exemplo
Entrada de exemplo
Venho trabalhando em um script que possa executar essa tarefa automaticamente. Atualmente, ele somente copia os arquivos de inicialização para o disco rígido e configura as suas entradas BCD. Ele não define o setor de inicialização como o novo valor do Windows Server 2008 enquanto executa o Windows —isso deve ser feito offline, no Windows PE. É possível encontrar o script na seção de downloads de código do site da TechNet Magazine em technetmagazine.com. Para executar o script, você deverá ter os seguintes itens no mesmo diretório do VBScript que está executando:
  1. BCDEdit
  2. BOOTMGR
  3. Um diretório \BOOT\ (da mídia do Windows Vista ou Windows PE 2.0)
  4. Um diretório \SOURCES\ com um arquivo BOOT.WIM do Windows PE válido e inicializável
Ele criará o BCD e copiará os arquivos de inicialização adequados. Depois de inicializar o Windows PE e executar o bootsect, você deve conseguir realizar a inicialização dupla.

Desfazendo a inicialização dupla
Desfazer a inicialização dupla é ainda mais fácil do que realizá-la. É necessário somente que você restaure o setor de inicialização para o setor de inicialização pré-Windows Vista executando o seguinte comando:
bootsect.exe /NT52 ALL
Uma vez que tenha sido restaurado, é possível excluir o bootmgr e o diretório \boot. Na inicialização seguinte, o setor de inicialização forçará o ntldr a iniciar e removerá completamente o Windows PE 2.0 e todos os binários de inicialização do Windows Vista do fluxo de inicialização.

Wes Miller é Gerente técnico de produto da Initiate Systems (InitiateSystems.com) em Austin, no Texas. Anteriormente, ele trabalhou na Winternals Software e como Gerente de programas na Microsoft. Entre em contato com ele pelo email technet@getwired.com.


 Anota&#231;&#245;es de campo: Doe o seu PC
Anotações de campo
Doe o seu PC
Jim Lynch

A sabedoria convencional sobre a forma mais econômica de descartar computadores, por muitos anos, foi melhor captada em uma pesquisa publicada em 2003 por Frances O'Brien do The Gartner Group entitulada "PC Disposal: TCO's Last Surprise". Essa análise comparativa sobre descarte de PCs descobriu que doar equipamentos era a opção mais cara (entre seis opções de descarte) devido à quantidade de tempo gasta para localizar a organização de caridade correta disponível para receber doações.
Dicas para a doação
O TechSoup.org oferece dicas adicionais para a doação e também para obter doações em techsoup.org/recycle. Algumas considerações antes de doar são:
  • Não segure o equipamento de TI depois da atualização para novo hardware. Equipamentos de computação perdem seu valor de reutilização depois de cinco anos. Do mesmo modo, celulares geralmente atingem o fim da vida depois de três anos.
  • Doe equipamento de TI mais novo do que cinco anos para recondicionadores em vez de diretamente para organizações sem fins lucrativos ou escolas.
  • Empacote os acessórios com o equipamento, incluindo teclado, mouse, impressora, modem, discos de software e manuais que vieram com o equipamento.
  • Mantenha uma lista do que você doou para seus registros e obtenha um recibo. Você pode se qualificar para obter uma redução de impostos se a doação for para um recondicionador sem fins lucrativos. Nos EUA, doadores de negócios podem deduzir o valor não depreciado do computador e indivíduos podem deduzir o valor atual de mercado de um computador. Para determinar o valor de mercado justo de um computador, visite o Avaliador de Computadores Usados gratuito do Canadá (servlets.edeal.com/servlets/PcEval).

Hoje em dia, a história é outra. Na verdade, o EPA dos EUA embarcou recentemente em uma campanha chamada "Do the PC Thing", que educa os usuários sobre como preparar seu hardware antigo para reutilização e oferece uma lista de recursos. Essa campanha faz parte do site de conscientização pública de reciclagem e reutilização de eletrônicos do EPA, Plug-In To eCycling (epa.gov/plugin/). Clique no link "Reuse It!" para obter artigos direcionados a consumidores ou negócios.
Neste site, você aprenderá que o problema mais importante em relação à doação ou reciclagem de hardware é proteger a si próprio. A literatura do "Do the PC Thing" oferece apontadores básicos sobre como apagar o disco rígido e os requisitos legais de segurança de dados e confidencialidade. Se você estiver descartando o seu computador para reciclagem ou reutilização no fim da vida, deve remover seus dados confidenciais, como senhas, documentos, informações de cartão de crédito, mensagens de email e logs da Web.
A maioria das empresas de reciclagem, recondicionamento e gerenciamento de ativos fornece serviços de segurança de dados destruindo discos rígidos ou usando um utilitário de software de limpeza de disco que substitui os dados para que fiquem irrecuperáveis. Observe que se os seus computadores forem consignados para reutilização, é preferível manter o seu hardware intacto.
Os softwares de limpeza de disco bem conceituados usam especificações 5220.22-M do Departamento de Defesa dos EUA. Esse tipo de limpeza de dados baseada em software substitui sistematicamente todos os locais endereçáveis no seu disco rígido com um caractere, verifica a substituição e, em seguida, substitui todos os locais endereçáveis novamente com caracteres aleatórios. Em 2004, a Agência de Segurança Nacional dos EUA (NSA Advisory LAA-006-2004) descobriu que uma única substituição usando o software padrão do Departamento de Defesa é suficiente para tornar irrecuperáveis os arquivos eletrônicos.
Agora é razoavelmente fácil realizar a sua própria limpeza de dados. Há aplicativos freeware bem conceituados como o Active@ Kill Disk Hard Drive Eraser (killdisk.com/eraser.htm) ou o Darik's Boot and Nuke (dban.sourceforge.net). Se você tem vários computadores para limpeza de dados, considere aplicativos comerciais mais robustos como o Blancco Data Cleaner (blancco.com) ou o WipeDrive (whitecanyon.com).
Se o seu equipamento de TI tiver mais de cinco anos ou estiver quebrado, uma das seis opções de descarte estudadas por Gartner foi a reciclagem de eletrônicos no fim da vida. Há atualmente mais de 900 empresas que realizam esse trabalho nos EUA. Para reciclar equipamento de TI de maneira adequada, consulte a lista de recicladores responsáveis da Electronic TakeBack Coalition (www.computertakeback.com/the_solutions/recyclers_map.cfm).

Jim Lynch é Diretor do programa de reciclagem e reutilização de computador da TechSoup.org, uma empresa de alta tecnologia sem fins lucrativos com sede em São Francisco cuja missão é fornecer hardware de baixo custo, software e experiência a instituições de caridade de todo o mundo.


 Segredos do Windows: Eliminando os recortes
Segredos do Windows
Eliminando os recortes
Raymond Chen

Isso não acontece com freqüência , mas ocasionalmente um antigo recurso é excluído – com muita comemoração por parte da equipe de produto. No Windows® XP, por exemplo, a interface para configuração de um padrão de desktop foi removida. A funcionalidade subjacente ainda existe, se você conseguir escrever um programa que chame SystemParametersInfo(SPI_SETDESKPATTERN), mas não há mais uma interface interna. Por que o padrão de área de trabalho foi removido do painel de controle da área de trabalho?
A nossa pesquisa indicou que praticamente ninguém utilizou mais padrões de área de trabalho. Eles foram mais populares quando a memória era mais cara e os usuários não queriam gastar um quarto da memória da máquina com um papel de parede de 1 MB. Um minúsculo padrão monocromático 8×8 repetido na tela fornecia algum grau de personalização em um monitor de 640×480 a um custo muito mais inferior.
No entanto, as alterações ao longo dos anos tornaram esses padrões de área de trabalho cada vez menos atrativos. Em primeiro lugar, é claro, agora os computadores têm muito mais memória do que em 1983. Em segundo lugar (também obviamente), os monitores são executados em resoluções muito superiores do que antigamente. Um interessante padrão quadriculado 8×8 é basicamente uma mancha cinza quando exibido em um monitor 1.600×1.200.
Esse não é o único recurso antigo na pilha de sucatas. Outro exemplo são os recortes. Introduzidos no Windows 95, os recortes aparecem como fragmentos de documentos capturados em um arquivo. O fragmento do arquivo é realmente um objeto OLE. A idéia por trás dos recortes era que você poderia, por exemplo, realçar algum texto em um processador do word e arrastá-lo para a área de trabalho, onde então o recorte seria criado. Posteriormente, você poderia selecionar o recorte e arrastá-lo novamente para o processador de texto ou para algum outro programa e o texto utilizado para criar o recorte seria inserido no novo documento. Isso é semelhante a copiar e colar, exceto que, em vez de armazenar os dados temporariamente na área de transferência, eles são armazenados em um arquivo.
Agora, assim que você cria um arquivo de recorte, a única ação que você realmente pode fazer com ele é inseri-lo em outro documento, da mesma forma que a única ação que pode realmente fazer com algo na área de transferência é colá-lo em algum lugar. Em algum momento, alguém adicionou o recurso onde você poderia clicar duas vezes no arquivo de recorte e poderia abri-lo o aplicativo no qual ele foi originariamente criado. (O conteúdo poderia ser qualquer coisa; portanto, a única forma de exibir o recorte é acessar o programa onde ele foi originariamente criado.)
Não sei se esse recurso foi adicionado como uma ferramenta de depuração ou algo semelhante que os usuários poderiam ver o que estivesse em um recorte sem precisar criar um documento fictício para acessá-lo. De qualquer uma das formas, os autores de vírus adoraram a funcionalidade de “abrir o aplicativo que originariamente criou o recorte”, pois isso permitiu que eles criassem um arquivo de recorte e o preenchessem com dados; digamos, "O aplicativo original seria cmd.exe e o fragmento do documento seria esse arquivo de lote”. Quando alguém clicar duas vezes nesse arquivo específico de recorte para ver o que há nele, o visualizador de recorte disponibilizará um arquivo de lote para o processador de comando e dirá “Abra isso e mostre para o usuário”.
Graças à história dos recortes, a equipe do shell decidiu remover o recurso do Windows Vista®. Para fazer isso, a equipe precisou pesquisar qual era a popularidade dos recortes no mundo real. Assim, a equipe do shell solicitou ao grupo de suporte de produtos que verificasse os registros de chamadas do grupo, a fim de descobrir quantas pessoas tinham dúvidas sobre recortes. A teoria foi que um recurso popular obtém chamadas de suporte e recursos não populares não têm (pois ninguém os está utilizando). Os recortes em específico não se enquadram exatamente na categoria de recursos “evidentemente intuitivos”; portanto, um pequeno número de chamadas não poderia ser explicado de forma alguma como “Bem, o recurso é tão óbvio que ninguém precisa entrar em contato para obter ajuda com ele!".
A resposta surgiu com o grupo de suporte de produtos. No ano passado, o grupo recebeu um total de quatro chamadas. E todas elas foram do tipo: “Criei esse arquivo esquisito. O que é isso e como faço para eliminá-lo?".

Raymond Chenpossui um site, The Old New Thing (A velha novidade), e escreveu um livro homônimo (Addison-Wesley, 2007) para tratar da história do Windows e da programação Win32. Faz tempo que Raymond não entra em contato e ele gostaria de saber como as coisas estão.