 TechNet Magazine July 2007

TechNet Magazine July 2007

Comunicações: Proteção de dados e recuperação de desastres no Exchange Server 2007

O Exchange Server 2007 inclui algumas opções para oferecer suporte a alta disponibilidade e a recuperação de desastres. Explore as alternativas oferecidas pelo Exchange e planeje a solução de recuperação ideal para a sua organização.

Lee Benjamin Comunicações: Aumente a segurança com o Windows Mobile 6

Embora os smartphones e os PDAs ofereçam acesso à rede para quem estiver fora do escritório, eles também podem expor a rede a diversas vulnerabilidades. Este é um guia de como o Windows Mobile 6 e o Exchange Server podem ajudá-lo a proteger os dispositivos móveis e a infra-estrutura da sua empresa.

Matt Fontaine Comunicações: Uma alternativa poderosa para pastas públicas

O MOSS 2007 fornece uma solução muito mais poderosa para compartilhar dados do que as pastas públicas do Exchange, oferecendo recursos aprimorados e facilidade de administração. Veja como usar o SharePoint para compartilhar calendários, contatos e documentos.

Alan Maddison Comunicações: Logon no Outlook Web Access com cartões inteligentes

Um dos vínculos mais vulneráveis na cadeia de segurança tem a ver com senhas fracas, que podem ser facilmente comprometidas. Saiba como aperfeiçoar a segurança de email, implementando a autenticação de cartão inteligente de dois fatores para usuários móveis.

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Administração do Windows: O ActiveX Installer Service no Windows Vista

Como você protege os desktops de controles ActiveX maliciosos sem limitar a compatibilidade de aplicativos? Levaremos você por um tour do ActiveX Installer Service (AxIS) no Windows Vista, que resolve esse problema com uma nova forma de gerenciar controles ActiveX.

Rob Campbell and Joel Yoker Do editor: Seis graus

Joshua Trupin Toolbox: Novos produtos para profissionais de TI

Greg Steen P&R do SQL: Clusters internos, paradas misteriosas, a conta SA e muito mais

Edited by Nancy Michell Destaque de utilitário: SMSMap

Jeff Tondt Como funciona: Solucionando problemas de RPC

Zubair Alexander The Cable Guy: Tráfego IPv6 em conexões VPN

Joseph Davies Windows PowerShell: Repensando o pipeline

Don Jones Ei, Equipe de Scripts!: Nos scripts, assim como na vida, a aparência é muito importante

The Microsoft Scripting Guys Perguntas e respostas do Exchange: Funções de Transporte de Borda e Transporte de Hub, máquinas virtuais e muito mais

KC Lemson and Nino Bilic Security Watch: Ferramentas para gerenciar ACLs

Jesper M. Johansson Os arquivos da área de trabalho: O Microsoft Desktop Optimization Pack

Wes Miller Segredos do Windows: Os poderes curativos do modo de segurança

Raymond Chen


 Comunica&#231;&#245;es: Prote&#231;&#227;o de dados e recupera&#231;&#227;o de desastres no Exchange Server 2007
Comunicações Lee Benjamin

Proteção de dados e recuperação de desastres no Exchange Server 2007
Visão geral:
  • Backup e restauração básicos
  • Continuidade de dados
  • Tecnologias de replicação
  • Soluções alternativas

O Microsoft Exchange Server foi projetado com o backup em mente. As organizações precisam fazer backup dos dados de seus sistemas de mensagens e também devem ser capazes de recuperar essas informações. Para atender a essas necessidades, a Microsoft construiu toda uma gama de opções de proteção de dados, desde os tradicionais
backup e restauração no nível inferior, até a continuidade operacional e as soluções de continuidade de negócios que oferecem os mais altos níveis de disponibilidade e de recuperação de desastres. Neste artigo, examinarei essas opções a ajudarei você a decidir como implementar a melhor solução de recuperação do Exchange para a sua organização.

NÍVEL 1: BACKUP E RESTAURAÇÃO BÁSICOS
Você pode fazer backup dos arquivos do Exchange colocando seus bancos de dados offline, mas também pode fazer isso enquanto eles estão em execução. Na verdade, a última opção é a forma mais recomendada de backup do Exchange. Mas o Exchange é mais do que um conjunto de arquivos. É um armazenamento de informações com grandes arquivos de bancos de dados e logs de transação. As mensagens enviadas para o Exchange são registradas imediatamente nos logs de transação e, quando o sistema tem alguns ciclos livres (normalmente alguns milissegundos mais tarde), essas mensagens são copiadas para o banco de dados. Ao gravar as informações em disco o mais rápido possível, o Exchange oferece um nível muito alto de capacidade de recuperação. A disponibilidade de ambos os conjuntos de informações é fundamental para a recuperação do Exchange. Caso haja uma falha no seu sistema, a combinação do backup anterior e de todas as transações até aquele ponto permitirá que você restaure o Exchange até a informação mais recente. Observe que o Exchange reproduz automaticamente as transações em um banco de dados restaurado, se necessário.
Os programas de backup acessam informações no banco de dados do Exchange por meio da API de backup ESE (Mecanismo de Armazenamento Extensível) ou por meio de soluções VSS mais novas, das quais falarei mais adiante. Sempre que um backup ESE é iniciado, o Exchange suspende temporariamente todas as gravações no banco de dados. Ao mesmo tempo em que o ESE coloca temporariamente o banco de dados em um modo somente para permitir que ele seja copiado em um backup completo, ele também utiliza um banco de dados temporário para armazenar novas transações que ocorram durante o backup. Quando o backup estiver concluído, o ESE retornará o banco de dados ao seu modo leitura/gravação normal e aplicará as transações acumuladas em seu banco de dados temporário. Os logs de transação antigos também são limpos no final de um processo de backup bem-sucedido.
Embora esse processo de backup seja direto e transparente até mesmo para os usuários que se conectam no meio da noite durante o backup, o ESE pode demorar bastante tempo para terminar, especialmente porque os bancos de dados do Exchange podem ter desde alguns poucos gigabytes até 30 a 50, ou até mesmo 100 GB — fazendo com que fique praticamente impossível para as tecnologias padrão concluírem o backup em uma noite. Para você ter uma idéia das opções disponíveis com o NTBackup.exe, dê uma olhada na Figura 1.
Figura 1 Usando o utilitário NTBackup
Figura 1 Usando o utilitário NTBackup

Práticas recomendadas para o Exchange
Se você quer poder se recuperar rapidamente de falhas comuns de hardware e do sistema, deverá executar backups completos do Exchange todas as noites. Para aprimorar o desempenho e a capacidade de recuperação sempre que um servidor Exchange utilizar discos locais, é importante que você use matrizes RAID separadas para armazenar os bancos de dados e os logs de transação do Exchange. Dessa forma, se um controlador RAID falhar, ou se mais de um disco do RAID falhar de forma que os outros discos não possam mais recriar os dados distribuídos, ainda assim você poderá se recuperar. Se você perder os seus logs de transação, ainda terá bancos de dados atualizados no Exchange nas outras unidades que garantirão a continuidade das operações normais com novos logs de transação. Se você perder as unidades de banco de dados, a sua estratégia de recuperação será voltar ao seu backup completo da noite anterior e aplicar os logs de transação do dia atual para atualizar os bancos de dados.
É importante que você limite o tamanho dos bancos de dados do seu Exchange para que cada um possa ser copiado para o backup — e, mais importante, restaurado — em um tempo razoável. Para a maioria das organizações, isso significa manter o tamanho dos bancos de dados entre 30 e 50 GB. Quando um banco de dados ficar maior do que isso, será recomendável dividi-lo em diversos bancos de dados para que a restauração seja gerenciável.

A seqüência de backup e de restauração
A localização dos bancos de dados e dos logs de transação é muito importante — não só para o desempenho do backup como também para a velocidade de recuperação. Hoje, todos os servidores oferecem suporte a diversos níveis de redundância de unidades de disco, conhecidos como RAID. Basicamente, o RAID permite que uma unidade de disco falhe sem prejudicar o sistema, embora seu desempenho se torne mais lento até que o disco seja substituído e recriado. Até lá, o controlador RAID deve recriar os dados a partir dos discos que restaram de forma dinâmica, em resposta a cada solicitação de acesso a disco. Para obter mais informações sobre o design de espaço de armazenamento no servidor para caixas de correio, consulte o documento do IT Showcase da Microsoft "Adotando os 64 bits com o Exchange Server 2007".
Um dos principais recursos do Exchange é o seu design de banco de dados de instância única. Isso significa que somente uma cópia de uma mensagem específica e um único anexo (se existir) serão armazenados em um banco de dados do Exchange. Se a mensagem foi enviada para vários destinatários do mesmo armazenamento de informações, serão criados ponteiros adicionais para os objetos (mensagem, anexo), evitando que eles sejam duplicados. Essa vantagem não vale só para obtermos mais eficiência de entrega, mas também economiza espaço para o Exchange, tanto em disco como em fita.
Embora o Exchange seja bom em recuperar todo o banco de dados, a restauração de caixas de correio, pastas ou mensagens individuais exige primeiro a recuperação de toda a fita. Não é nenhuma surpresa saber que os usuários querem recursos de restauração mais granulares. A instância única em fita dificulta muito essa restauração. Os fornecedores de backup responderam a essa necessidade com o "Backup Brick-Level" (que eu não recomendo). Após a conclusão de um backup completo do banco de dados do Exchange usando a API de backup ESE aprovada, os produtos adicionam todas as caixas de correio à fita de backup. Como a API de backup não oferece uma forma de retirar os dados de caixas de correio individuais, usa-se o MAPI. Como resultado, a fita de backup leva consideravelmente mais tempo, já que você está duplicando todas as mensagens e anexos.
A Microsoft fez alguns aperfeiçoamentos que resolveram parcialmente o problema. Por exemplo, a lixeira administrativa (ou Dumpster) mantém os itens por um tempo depois que eles são excluídos pelos usuários, caso eles sejam novamente necessários. Além disso, não é mais necessário manter um servidor reserva como uma floresta de recuperação do Exchange; os grupos de armazenamento de recuperação permitem que um administrador monte parcialmente bancos de dados restaurados recuperados de fita e copie ou mescle dados no nível das caixas de correio.

A prática leva à perfeição
Muitas organizações aprenderam da forma mais difícil que, a despeito do nível de backup e de recuperação escolhido, a mídia de backup e os procedimentos de recuperação devem ser testados regularmente. Muitos administradores descobriram se a sua tecnologia de backup e seus procedimentos de restauração funcionavam ou não somente depois de um desastre. O melhor momento para o teste é o dia seguinte à criação e à configuração do seu servidor novo, quando ele já estiver operacional em sua organização do Exchange mas ainda possuir alguns poucos usuários. Neste momento, você deve executar um backup completo do Exchange, backups regulares das suas unidades e capturar o estado do sistema, o que inclui os arquivos fundamentais no disco do sistema, assim como a metabase do IIS (onde é mantida a configuração de roteamento do Exchange). Em seguida, reformate calmamente o novo servidor e comece tudo outra vez, atualizando as notas tomadas durante a primeira instalação do servidor. Você deve ser capaz de restaurar configurações a partir do estado do sistema, mas também precisa ter a documentação adequada para reimplementá-las manualmente.
O tempo gasto neste exercício de fogo reduzirá significativamente o seu tempo de recuperação no futuro. Repita esse processo periodicamente. Durante o processo, cronometre o tempo de obtenção das fitas armazenadas em um local externo. Aqueles que já passaram por esse intervalo interminável quase sempre começam a pensar mais seriamente em como os backups de disco para disco podem ser uma parte importante de sua estratégia de backup e de restauração — mesmo quando o armazenamento de fitas em um local externo continue a ser a sua principal opção para a recuperação de desastres.

Os desafios do backup em fita
A restauração a partir de fita leva muito tempo. Agora, o Exchange é tão fundamental para as organizações que os usuários e a gerência esperam que ele esteja disponível sempre. Quando há um problema sério, a maioria das organizações é pega de surpresa. Ninguém está preparado para ouvir que a restauração do banco de dados de 75 GB a partir de uma fita levará 8 horas — e isso não inclui o tempo gasto com a obtenção das fitas do local externo ou com a reinstalação do sistema operacional.
Além disso, ainda há o desafio da recuperação do banco de dados correto a partir da fita. Em 10 anos, desde o lançamento do Exchange, o custo do armazenamento em disco e de WANs caiu consideravelmente. Como resultado, muitas organizações podem adquirir métodos mais rápidos de backup e de restauração. Essas organizações podem aproveitar as tecnologias que permitem a elas obter uma continuidade operacional e a recuperação de desastres para a infra-estrutura do seu Exchange.

NÍVEL 2: CONTINUIDADE OPERACIONAL
A Continuidade Operacional é um conjunto de processos e de tecnologias criado para tornar a recuperação a mais rápida possível, minimizando o tempo de inatividade inesperado. A Continuidade Operacional oferece um RTO (Recovery Time Objective) e um RPO (Recovery Point Objective) aprimorados em fitas para a recuperação local. Ela se esforça para eliminar, onde for possível, o tempo gasto no retorno das fitas para a organização. Examine a Figura 2 para fazer uma comparação entre a Continuidade Operacional e o backup e a restauração, além da recuperação de desastres.
Figura 2 Continuidade da recuperação
Figura 2 Continuidade da recuperação
Esse diagrama ilustra a seqüência da recuperação e da disponibilidade, desde o lento e barato, no canto inferior esquerdo, até o rápido e caro, no canto superior direito, com uma transição deliberadamente difusa entre a continuidade operacional e as soluções de recuperação de desastres.
O gráfico lhe dá uma idéia das vantagens e desvantagens de custo, de tempo de recuperação e de disponibilidade nessas abordagens. Neste artigo, farei uma distinção clara entre os processos de continuidade local e de recuperação de desastres. A recuperação de desastres é sempre vista como remota, com o envio de dados para um local externo como o principal objetivo. A distância introduz desafios adicionais e, normalmente, é muito mais cara, mas a recuperação de desastres está relacionada à continuidade de negócios após eventos catastróficos. Falarei mais sobre isso em instantes.

Um pouco de história
Como o Exchange se tornou uma parte vital da infra-estrutura e, à medida que mais informações são armazenadas em seus bancos de dados, ficou claro que os tempos de backup e de restauração precisavam ser reduzidos. Trabalhando com a Microsoft, algumas das grandes organizações chegaram a uma abordagem que oferecia um retorno bastante aperfeiçoado para operações parciais. Se uma organização pudesse receber emails do mundo externo e enviar emails para ele, seria como se nada tivesse acontecido. Afinal de contas, a aparência é importante.
Para implementar essa restauração do tipo "sinal de linha" para o Exchange, um novo banco de dados vazio foi colocado no lugar do danificado. O Exchange e o Active Directory® criaram, então, novas caixas de correio com as permissões apropriadas, e os usuários eram capazes de enviar e de receber. Quando as fitas de backup foram obtidas e os dados recuperados, eles poderiam ser montados administrativamente. O administrador do Exchange mesclaria então as caixas de correio restauradas às caixas de correio de "sinal de linha". As caixas de correio poderiam ser priorizadas conforme a necessidade. Embora fosse um aperfeiçoamento, esse era um processo complexo e muito demorado que originalmente usava o EXMERGE e que foi adaptado aos grupos de armazenamento de recuperação. Entretanto, devemos notar que a restauração completa dos dados após um cenário de recuperação "sinal de linha" pode ser uma tarefa árdua e complicada (especialmente quando podemos ter até 50 grupos de armazenamento no Exchange 2007). Se você considerar a implementação de um cenário de recuperação "sinal de linha", tenha o cuidado de verificar se todas as vantagens valem o esforço.

Serviços de Cópia de Sombra de Volume
Para aproveitar os discos mais baratos e remover a sobrecarga de processador dos servidores Exchange de produção, foi desenvolvida uma nova API de backup para o Microsoft® Windows Server® 2003 e para o Exchange. O serviço VSS (Cópia de Sombra de Volume) foi criado para fazer cópias consistentes do estado atual dos dados. Esses instantâneos são cópias somente leitura rápidas dos dados do Exchange que incluem sucessivamente somente os dados alterados. As cópias normalmente apontam para outro servidor com espaço em disco disponível ou para uma SAN (Rede de Área de Armazenamento). Diversos instantâneos podem ser mantidos, com backups feitos em fita. Como resultado, o servidor Exchange de produção não precisa mais sofrer um impacto em seu desempenho por causa do software de backup e da sobrecarga da cópia para fita.
Existem diversas vantagens em usar o VSS para a proteção dos dados do Exchange. Primeiro, o seu servidor Exchange não sofrerá mais quedas de desempenho causadas por operações de backup em fita. Embora o backup em fita ainda seja necessário, ele poderá usar a cópia dos dados do Exchange, não causando impacto no desempenho do usuário. Segundo, é possível capturar instantâneos com mais freqüência do que um por noite. E, como bônus, você pode manter vários instantâneos no servidor secundário ou em outro armazenamento local.
Existem alguns produtos de terceiros no mercado que aproveitam os recursos de instantâneo do VSS. Alguns simplesmente reduzem o tempo necessário para o backup e a restauração dos bancos de dados do Exchange, enquanto que outros adicionam recursos como uma recuperação mais granular do que a nativa do Exchange, para que você possa restaurar até o nível das caixas de correio. Embora ninguém goste de backups brick, as pessoas querem ser capazes de restaurar pastas específicas ou até mesmo mensagens.

Tecnologias de replicação
O failover do Exchange mediado por software é uma opção oferecida por alguns fornecedores de replicação. Ele faz com que um servidor Exchange em espera seja disponibilizado e, em seguida, informa ao Active Directory que todas as caixas de correio dos usuários foram movidas. Existem duas formas de se fazer isso e ambas requerem algumas personalizações nos ambientes do Exchange e do Windows. Uma envolve alguns truques com o seu DNS para que o servidor em espera assuma o nome e o endereço IP do servidor que falhou. Essa opção tem a vantagem de ser mais fácil do ponto de vista das estações de trabalho clientes, já que o Outlook® acha que ainda está usando o mesmo servidor.
A segunda opção usa um servidor em espera que esteja executando o Exchange e que mantém cópias do banco de dados, mas sem nada montado. No caso de uma falha, o servidor em espera informa o Active Directory que todas as caixas de correio dos usuários foram movidas para ele. Em seguida, um script é executado, ou uma Diretiva de Grupo é distribuída, dizendo aos clientes que eles estão em um servidor de email diferente. O Outlook 2007 reconhece o Active Directory, o que facilita o processo, já que ele descobrirá automaticamente esses mapeamentos por conta própria.

Cluster local com MSCS
O ponto mais alto da seqüência de disponibilidade é o MSCS (Microsoft Cluster Services); o Exchange é um aplicativo que reconhece clusters. O cluster compartilha informações entre dois ou mais computadores para que, quando um deles falhar, os outros possam assumir o controle. Hoje, a maioria dos clusters do Exchange possui dois ou quatro nós, embora até oito nós possam ser usados. Um dos nós será sempre designado como passivo — operacional com o Windows Server em execução e com o Exchange Server instalado, mas sem caixas de correio ativas. Era possível haver um cluster de dois nós ativo/ativo no Exchange 2003, mas, devido às cargas de desempenho, isso não é mais recomendado e não será suportado no Exchange 2007.
Assim como o esquema de clusters do Exchange 2003, os clusters do Exchange 2007 que incluem um nó passivo ainda poderão usar uma única matriz de armazenamento compartilhada. Embora as matrizes de armazenamento de cluster normalmente tenham alguns recursos de redundância para resistirem a muitos tipos de falhas, ainda assim elas oferecem somente uma cópia dos dados, deixando uma janela de vulnerabilidade aberta. É por isso que esses agrupamentos são chamados de SCC (cluster de cópia única), para podermos distingui-los da próxima geração em proteção de dados, que chegará com o MCC (cluster de várias cópias) do Exchange 2007. Discutiremos os MCCs mais adiante, quando examinarmos a recuperação de desastres.

Replicação contínua local
A LCR (Replicação contínua local) é um novo recurso do Exchange 2007 que oferece uma forma aperfeiçoada de manter uma segunda cópia dos bancos de dados e dos logs de transação do Exchange no mesmo servidor. Ela adiciona uma camada de redundância à prática recomendada de termos o banco de dados do Exchange em um RAID e o log de transações em outro: a LCR possibilita o armazenamento de uma segunda cópia dos logs na matriz que contém a cópia principal do banco de dados e, então, armazena uma segunda cópia do banco de dados na matriz que contém a cópia principal dos logs (consulte a Figura 3). Se tanto o controlador RAID como a matriz falharem, você ainda terá o seu banco de dados e os logs de transação na outra matriz. Dessa forma, você poderá continuar a operar — embora um pouco nervoso e com alguma degradação no desempenho — até ser capaz de recriar a matriz que falhou.
Figura 3 Configurando a LCR
Figura 3 Configurando a LCR
A LCR é uma solução de continuidade operacional local, não uma solução de backup e, portanto, você ainda precisa de uma estratégia de backup completo. Com a LCR, também há um impacto no desempenho, já que o seu servidor fará duas cópias do banco de dados e dos logs de transação. Além disso, na implementação do Exchange 2007, existem algumas limitações que tornarão a LCR mais adequada somente a organizações menores, já que ela só oferece suporte a um banco de dados em um grupo de armazenamento e a um banco de dados de pastas públicas na organização.
O failover com uma recuperação de LCR não é instantâneo — um profissional de TI experiente terá de executar scripts para ter o Exchange de volta. O processo exige a execução de comandos do Shell de Gerenciamento do Exchange, executados fora do console de gerenciamento do Exchange.
Onde o Exchange Server 2003 Enterprise Edition permitia que uma organização executasse até 20 bancos de dados do Exchange (quatro grupos de armazenamento com até cinco bancos de dados cada), o Exchange 2007 Enterprise Edition permite até 50 grupos de armazenamento, cada um com seu próprio banco de dados. Os logs de transação também foram reduzidos dos arquivos de 5 MB do Exchange 2003 para arquivos de 1 MB no Exchange 2007. Ambas as alterações foram feitas para oferecerem suporte à LCR — e à CCR (Replicação contínua em cluster), que se tornará relevante dentro de algum tempo.
As pequenas e médias empresas usarão a LCR para oferecerem uma proteção maior de dados para suas operações com o Exchange. A LCR é fácil de implementar mas ainda envolve a intervenção manual. Como uma solução mesmo servidor/disco local, a LCR é somente a primeira etapa em direção à continuidade operacional aperfeiçoada. Embora ela ofereça proteção contra falhas de um RAID e de controlador RAID, várias panes de disco ou falhas de controlador RAID simultâneas são relativamente raras. Na maior parte do tempo, os cenários de falha envolvem a queda de todo o servidor, o que nos leva à próxima etapa da proteção do Exchange.

A replicação local fora do host feita por terceiros
Para enriquecer os recursos de recuperação do Exchange, outros fornecedores desenvolveram produtos que aproveitam a replicação "fora do host" usando os arquivos de log do Exchange para manter uma cópia em espera do banco de dados do Exchange em outra máquina. Neste caso, a solução de proteção de dados ou arquivamento executa um backup completo ESE do Exchange em um computador diferente e, em seguida, extrai os logs de transação assim que o Exchange os fecha. Ela insere essas transações em sua cópia do banco de dados do Exchange para que esteja sempre atualizada. Como já observei, esses logs são relativamente pequenos (de 5 MB no Exchange 2003 e de 1 MB no Exchange 2007) e, portanto, assim que o backup completo é concluído, a cópia desses arquivos de log para o servidor fora do host quase não representará sobrecarga para o servidor Exchange.

NÍVEL 3: RECUPERAÇÃO DE DESASTRES E ALTA DISPONIBILIDADE
A recuperação de desastres é a capacidade de voltar a operar caso o principal data center se torne indisponível. O Exchange merece uma recuperação de desastres efetiva porque as funções de email e de calendário são a alma de muitas organizações de hoje.
Algumas empresas imaginam que seus tradicionais backups em fita armazenados em um local externo são uma forma de recuperação de desastres, mas se o seu data center for destruído pelo fogo ou por uma enchente, uma van trazendo alguns conjuntos de fitas não terá utilidade alguma. A recuperação de desastres envolve, necessariamente, a mudança não só de seus dados para um local externo, como também da tecnologia e dos processos necessários para que o aplicativo volte a funcionar. Para ser eficiente, a recuperação de desastres se baseia na separação dos sistemas principal e secundário por alguma distância. A distância que deve haver entre os locais depende da magnitude do desastre com que você está preocupado. Se você se preocupa com fogo, talvez outro prédio do seu campus seja remoto o suficiente. Entretanto, os desastres de infra-estrutura que envolvem trens ou aeronaves poderiam afetar um raio de dois quilômetros ou mais. Muitos desastres são regionais: enchentes, tempestades de gelo, terremotos e até falta de energia elétrica. As comunicações podem sofrer com suas próprias calamidades — qualquer coisa, desde uma escavadeira que destrua o link com o seu provedor até ataques de negação de serviço e ataques de negação de serviço da Internet visando o comércio em geral.
De forma prática, se a sua organização já tiver mais de um local com equipes de TI, um deles poderá atender aos seus critérios para a continuidade operacional remota, dados os tipos de desastres dos quais você está se defendendo. Usar as suas próprias instalações e pessoal será bem mais barato do que contratar um provedor de recuperação de desastres ou do que alugar um espaço em um novo local.
Por fim, a recuperação de desastres também está relacionada à percepção: passar aos clientes a confiança de que você ainda está funcionando. As pessoas são compreensivas quando um desastre atinge uma cidade ou uma área, mas se a sua empresa não voltar a funcionar dentro de dois dias ou de uma semana, existe a possibilidade de que os clientes e os fornecedores acreditem no pior; muitas empresas vão à falência por esse motivo. Para o cliente, você deve passar a idéia de que está se recuperando, para que eles tenham a certeza de que o seu negócio vai continuar operando. Os clientes terão idéias diferentes sobre uma recuperação em tempo hábil: é compreensível que eles sejam menos pacientes com problemas em suas empresas de serviços financeiros do que com, digamos, problemas em seus fornecedores de móveis de escritório.

Exigência da recuperação de desastres
Ser capaz de fazer o Exchange funcionar novamente após um desastre requer a replicação de seus dados para o site secundário e o uso da tecnologia de replicação preparada para apresentar os dados para um outro servidor Exchange que possa usá-los e, em seguida, notificar os clientes do Outlook que suas caixas de correio foram movidas.
O Exchange é um aplicativo exigente em relação à replicação, particularmente se ela for feita a uma distância muito longa. Como um banco de dados verdadeiramente transacional, a ordem de cada gravação é extremamente importante. Para complicar ainda mais o desafio, o protocolo de transporte usado pelo Exchange para comunicar todas as transações e informações do sistema entre servidores é o SMTP, protocolo que usa intensivamente a largura de banda. Além disso, com clusters do Exchange, é preciso manter uma pulsação entre os sistemas a cada 500 milissegundos. Se o nó secundário não receber essa pulsação, poderá disparar um failover.
As complexidades de gerenciamento de tais desafios pode ser o motivo pelo qual a Microsoft só esteja entrando nesse espaço agora, com o Exchange 2007. Na ausência da Microsoft, diversas soluções de terceiros têm sido desenvolvidas para a replicação de dados do Exchange, tanto na forma baseada em host como na baseada em matriz.
Os fornecedores perceberam que poderiam estender um cluster dispersando os nós por locais diferentes; chamamos isso de um cluster estendido. Hoje, a forma mais comum de implementar os clusters estendidos é por meio de produtos de replicação de dados de uso geral feitos por terceiros ou por aqueles especificamente voltados para a extensão de um nó do Exchange. Você pode fazer isso com o MSCS, mas o requisito de sub-rede é desafiador em uma WAN. Os clusters e as complexidades de provisionar conectividade confiável e em grande largura de banda a data centers remotos aumentam, compreensivelmente, o custo e os requisitos da equipe para criar, manter e testar periodicamente os sistemas de recuperação de desastres.

Replicação contínua em cluster
A Microsoft estende seu suporte a cluster com a replicação contínua em cluster no Exchange 2007. A CCR estende a capacidade da LCR de manter duas cópias de um banco de dados e dos logs de transação do Exchange para implementar a mesma idéia em dois nós de cluster. A recuperação de desastres implica em separação geográfica dos sistemas principal e secundário, e os clusters de várias cópias (MCC) não serão capazes de se estender por distâncias significativas até que o Windows Server 2008, cujo codinome era "Longhorn", possibilite a utilização de clusters estendidos.
A tecnologia que permite que nós MCC tenham cópias separadas dos dados chama-se conjunto de nós principais (MNS) e se refere ao processo de seleção conduzido por dois ou mais nós, para determinar qual deles manterá a cópia de produção dos dados. Quando houver uma falha, os nós restantes farão uma nova seleção para determinar quem assumirá o papel de novo servidor principal de processamento/dados. Quem oferece suporte a essa democracia técnica é a CCR, garantindo que cada nó tenha um banco de dados atualizado. Os clusters do Exchange 2007 que utilizarem a CCR ficarão limitados a dois nós.
Em cenários maiores, os servidores Exchange normalmente configuram o disco de sistema local no próprio servidor e se conectam ao banco de dados do Exchange por meio de uma SAN, usando SCSI, fibra ou matrizes de disco iSCSI. Com um cluster MCC/MNS, uma questão interessante é se o armazenamento avançado do Exchange voltará a usar matrizes RAID locais para cada nó. Se a finalidade de um cluster MNS é permitir que cada nó tenha seu próprio armazenamento separado, ainda assim faz sentido apontar cada nó para uma SAN, cujo principal propósito é oferecer armazenamento comum?
Um cenário provavelmente intermediário do MCC/MNS seria ter um nó principal com armazenamento na SAN e um nó de cluster secundário com discos locais ou com uma SAN iSCSI de menor custo. Esse nó secundário poderia ser remoto em relação ao data center principal, em um local sem uma infra-estrutura de SAN.
A despeito de como isso acontece, o fato de o MCC usar MNS e CCR é uma outra etapa na hierarquia de redundância e de disponibilidade avançada, já que vários computadores estarão preparados para o failover e os dados serão replicados em elementos de armazenamento separados. Entretanto, isso ainda está totalmente confinado em um único data center até o lançamento do Windows Server 2008. O Windows Server 2008 oferecerá suporte nativo aos clusters estendidos, permitindo que os nós de um cluster MNS estejam geograficamente separados pela distância que quiserem — desde que a latência da rede entre os nós seja menor do que 500 ms. Até lá (e depois), a tecnologia de cluster de terceiros pode ser usada sobre o MNS e a CCR para oferecer a separação geográfica necessária para os clusters estendidos como uma solução de recuperação de desastres eficiente.
A utilização de clusters é o ponto mais alto da seqüência de recuperação de desastres, e a CCR está adequadamente posicionada como um recurso de grande disponibilidade do Exchange. E mesmo que a combinação represente uma sobrecarga de custos e de pessoal, ela promete ser a melhor solução para clientes que desejam operar um ambiente Microsoft homogêneo.

Continuidade operacional remota de terceiros
Não há dúvidas de que a solução da Microsoft e as extensões de terceiros ocuparão o lugar mais alto na seqüência de recuperação quando essa combinação estiver disponível. O failover automático em segundos — melhor é impossível. Ainda assim, nem todas as empresas precisam desse nível de disponibilidade e de continuidade de negócios, nem podem investir as centenas de milhares de dólares necessários para obtê-lo. Para muitas empresas, uma solução confiável que restaure totalmente o Exchange em minutos oferecerá toda a continuidade operacional necessária.
Como um exemplo, a Mimosa Systems, Inc. estende a continuidade operacional em um único data center para a continuidade remota. No local remoto, a recuperação de desastres da Mimosa mantém uma cópia do Exchange, a mantém atualizada com os logs de transação enviados pelo servidor Exchange principal e está sempre pronta para disponibilizar essa cópia para o servidor Exchange em espera. O servidor Exchange remoto usa hardware de servidor padrão e, assim como na implementação de um data center único, você o mantém aquecido e sempre pronto para ser ativado em caso de desastre. Se houver um desastre, um operador no site remoto inicia o failover e o executa, incluindo a montagem dos arquivos do banco de dados em espera, remapeando as caixas de correio e os perfis do Outlook. Entretanto, devemos notar que tais soluções de terceiros estão sujeitas aos limites de suporte definidos no artigo da Base de Dados de Conhecimento "Diretiva de suporte da Microsoft para produtos de terceiros que modificam ou extraem conteúdo de banco de dados do Exchange".

Conclusão
A proteção de dados do Exchange está disponível como uma seqüência de tecnologias e procedimentos que podem ser agrupados em três níveis, com base no custo e nos recursos. Quando começar a pensar sobre seus requisitos para a proteção de dados do Exchange, você deverá considerar quanto tempo de inatividade será tolerado pelas pessoas atingidas. Um desempenho maior e uma recuperação mais rápida custam mais, sendo que as opções avançadas giram em torno dos seis dígitos. Existem soluções mais baratas que se aproximam dos mais altos níveis de disponibilidade, mas não chegam a alcançá-los. As opções que você fizer deverão refletir as necessidades reais da sua organização.
Service Pack 1 para Exchange 2007
Ainda em versão beta, o Service Pack 1 (SP1) para o Exchange 2007 deve incluir alguns recursos que estão fazendo falta aos administradores, incluindo aperfeiçoamentos no OWA, recursos adicionais de GUI no Console e muito mais.
Os administradores que planejam soluções de recuperação se interessarão particularmente no fato de que o Exchange 2007 SP1 também inclui uma solução de disponibilidade de terceiros para complementar a LCR e a CCR: a replicação contínua secundária (SCR). Ela é uma abordagem intermediária e a Microsoft visa a uma capacidade de recuperação maior, sem a complexidade da "alta disponibilidade completa".
A SCR permitirá a replicação do banco de dados e dos logs de transação do Exchange para um servidor Exchange diferente daquele que normalmente armazena as suas caixas de correio. O destino da SCR pode ser local ou remoto, e pode ser um servidor Exchange em espera ou um cluster. No entanto, a SCR não requer um cluster em ambos os locais e é diferente da CCR, já que o destino é um ambiente em espera e o failover é um processo manual. Observe que você ainda precisará fazer aquela primeira cópia grande pela rede — essencialmente, um backup completo. Talvez você precise fazer essa replicação grande de tempos em tempos e deve ficar atento ao impacto causado na rede, assim como acontece com a CCR e as soluções de terceiros. Estou esperando uma adoção significativa tanto da SCR como da CCR e de produtos complementares que ofereçam recursos similares e, algumas vezes, melhores.

Lee Benjamin tem uma empresa chamada ExchangeGuy Consulting Services, onde trabalha diretamente com clientes e presta consultoria a parceiros da Microsoft. Lee é presidente do maior grupo de usuários de Exchange do mundo, o ExchangeServerBoston, e é diretor do BostonUserGroups. Ele também é MVP para Exchange, Microsoft Certified Trainer e, com freqüência, faz palestras em conferências do setor.
© 2007 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..


 Comunica&#231;&#245;es: Aumente a seguran&#231;a com o Windows Mobile 6
Comunicações Matt Fontaine

Aumente a segurança com o Windows Mobile 6
Visão geral:
  • Segurança no dispositivo
  • Segurança do Exchange Server
  • Segurança de rede

Os dispositivos móveis aumentam a produtividade dos trabalhadores em todo o mundo, permitindo que eles acessem informações cooperativas e mantendo-os conectados mesmo quando distantes
fisicamente do escritório. Os aumentos na produtividade são reais: basta ligar o dispositivo móvel e começar a trabalhar.
No outro lado da moeda estão os profissionais de TI que são desafiados pela difícil tarefa de manter o escritório virtual seguro e estável. Da sua perspectiva, todo dispositivo móvel é uma potencial falha de segurança na rede a ser conectada e um potencial risco de furto de dados. A criação de uma implantação mais segura de dispositivos móveis é crucial, mas também deve ser equilibrada com o oferecimento de uma experiência de usuário contínua e intuitiva.
O Microsoft® Windows Mobile® 6 e seu antecessor, o Windows Mobile 5.0 com o MSFP (Messaging and Security Feature Pack), incluem muitos recursos que o ajudarão a proteger a infra-estrutura corporativa com uma dificuldade mínima — e com um nível mínimo de inconveniência para seus usuários. A utilização do Microsoft Exchange Server como a plataforma de mensagens aumenta ainda mais as opções de segurança disponíveis. Neste artigo, demonstrarei como você pode usar o Windows Mobile, o Exchange Server e algumas práticas recomendadas de segurança de rede como fundação para a proteção dos dispositivos móveis da sua empresa.

A arquitetura da comunicação móvel
Existem três camadas a serem consideradas durante o planejamento ou a atualização de uma implantação móvel: o dispositivo, o servidor de mensagens e a rede (consulte a Figura 1). Quanto ao dispositivo, os principais desafios incluem permitir somente acesso autorizado ao dispositivo e evitar o uso de aplicativos não autorizados no dispositivos. O Windows Mobile ajuda a evitar o acesso não autorizado ao dispositivo por meio da autenticação de PIN e de proteção de senha, do bloqueio de tempo de expiração do dispositivo e da capacidade de "eliminar" ou de apagar a memória do dispositivo, seja de forma local ou remota, caso ele seja perdido ou furtado. A criptografia de dados do canal de comunicação e o armazenamento removível são suportados. Evitar que aplicativos não autorizados como vírus ou spyware sejam instalados ou acessem partes importantes do dispositivo também é essencial. A definição da função de gerenciamento, camadas de acesso de aplicativo, configurações de assinatura de código, configurações de segurança e certificados de segurança se combinam para ajudá-lo a obter a proteção em nível de dispositivo.
Figura 1 As camadas da comunicação móvel
Figura 1 As camadas da comunicação móvel
A próxima camada de segurança é o servidor de mensagens, como o Exchange Server 2003 com Service Pack 2 (SP2) ou o Exchange Server 2007. Essa camada inclui tanto a segurança da mensagem — a tecnologia pela qual as mensagens são transmitidas com segurança de e para dispositivos — assim como a interação entre o servidor de mensagens e o dispositivo móvel por meio do Exchange ActiveSync®. O uso do Exchange Server não é obrigatório para a utilização de dispositivos Windows Mobile, mas a sua presença oferece vantagens de custo, de escalabilidade, de desempenho e administrativas.
Boas práticas de segurança no servidor de mensagens e no dispositivo são fundamentais, mas a proteção da camada de rede também é muito importante. Configurar a sua rede corporativa de acordo com as práticas recomendadas e implementar protocolos de segurança fortes podem ajudar a evitar danos em sua rede, mesmo que um ou mais dispositivos móveis sejam comprometidos.

Diretivas de segurança no dispositivo
A primeira linha de defesa contra brechas de segurança está no próprio dispositivo com Windows Mobile. O sistema operacional Windows Mobile oferece diversos serviços de segurança de dispositivo que oferecem suporte a autenticação, criptografia de cartão de armazenamento, VPN (rede virtual privada), criptografia Wi-Fi e serviços SSL (Secure Sockets Layer). A segurança de dispositivo envolve o gerenciamento de quem terá acesso a um dispositivo e aos seus dados, o controle de quais aplicativos poderão ser executados no dispositivo e o estabelecimento de como os dados serão transmitidos de e para o dispositivo. Em geral, os administradores têm uma boa dose de flexibilidade na configuração e na imposição de diretivas de segurança, tanto no Windows Mobile 5.0 com MSFP como no Windows Mobile 6.
O acesso de usuário é gerenciado por meio de um PIN ou de autenticação de senha. Um dispositivo pode ser definido para ser automaticamente bloqueado após um período de inatividade ou depois de ser desligado, exigindo que o usuário desbloqueie o dispositivo para poder usá-lo (consulte a Figura 2). As especificações de controle de acesso de usuário são definidas por diretivas de segurança, que podem ser alteradas dependendo da função de segurança do administrador.
Figura 2 Configurando diretivas de senha
Figura 2 Configurando diretivas de senha
As diretivas de segurança definem níveis globais de segurança para o dispositivo móvel (consulte a Figura 3). As funções de segurança determinarão quem poderá definir e alterar essas diretivas de segurança. A função de gerente, normalmente reservada para operadores móveis, oferece um controle completo sobre configurações de diretivas de segurança. A função corporativa é usada pelo Exchange no gerenciamento de algumas diretivas de dispositivo, configuradas pelo administrador do Exchange. Dependendo do seu acordo com o provedor do dispositivo, você poderá ser capaz de personalizar as diretivas de segurança para a sua empresa.
Figure 3 Diretivas de segurança para os dispositivos móveis (Close Figure 3)

Diretiva Dispositivo móvel
Block unauthorized penetration into device (Bloquear acesso não autorizado a este dispositivo)

Windows Mobile 5.0 com MSFP

Especifica que o usuário sempre deve ser autenticado no dispositivo para desbloqueá-lo ou para permitir que ele insira um PIN no desktop.
Função padrão: Gerente, Corporativa.

Windows Mobile 6

Concede ou nega a permissão de usuário para alterar configurações de criptografia móvel para mídia de armazenamento removível.
Função padrão: Gerente, Corporativa.
Especifica se o usuário deve ou não ser autenticado no dispositivo quando conectado se o bloqueio do dispositivo estiver ativo. Função padrão: Gerente, Corporativa.
Protect sensitive data in case of device theft or loss (Proteger dados confidenciais em caso de furto ou perda do dispositivo)

Windows Mobile 5.0 com MSFP

Especifica que o usuário sempre deve ser autenticado no dispositivo para desbloqueá-lo ou para permitir que ele insira um PIN no desktop.
Função padrão: Gerente, Corporativa.

Windows Mobile 5.0 com MSFP e Windows Mobile 6

Especifica se uma senha deve ser configurada no dispositivo. Define as configurações de apagamento local e remoto do dispositivo.
Função padrão: Gerente, Corporativa.
Os métodos de autenticação personalizável usados pelo Windows Mobile são controlados por LAPs (Local Authentication Plug-Ins), que interagem com o LASS (Local Authentication Subsystem). Essa tecnologia permite que o Exchange Server controle a configuração do dispositivo em um nível granular — por exemplo, ao impor o comprimento e os requisitos de força da senha ou ao permitir a autenticação PIN simples.
O Windows Mobile 6 possui um conjunto expandido de funções LAP configuradas por meio do Exchange Server 2007. Você pode habilitar o reconhecimento do padrão PIN (por exemplo, negar o uso de padrões simples, como "1111" ou "1234"), configurar os períodos de expiração da senha ou do PIN, permitir que usuários solicitem a redefinição de um PIN com base em certas condições ou manter um histórico de PINs/senhas para evitar que os usuários reutilizem PINS ou senhas antigos quando for solicitado que criem novos.

Protegendo dados em dispositivos
Caso um PIN (ou uma senha) incorreto seja inserido mais vezes do que o permitido pelo administrador, o apagamento de dados no dispositivo o redefine permanentemente, limpando sua memória — incluindo as credenciais de autenticação do usuário. O limite é definido como parte das diretivas de segurança do Exchange Server. Após duas entradas incorretas, o dispositivo solicita que o usuário insira uma cadeia de caracteres de chave estruturada para continuar (consulte a Figura 4). Isso evita que o dispositivo seja apagado acidentalmente por causa de pressionamentos aleatórios de teclas. Também é possível apagar remotamente o cartão de armazenamento usando o Windows Mobile 6 e o Exchange Server 2007.
Figura 4 Aplicar a utilização de PIN e de senha
Figura 4 Aplicar a utilização de PIN e de senha
O bloqueio de um dispositivo não será o suficiente caso alguém esqueça um cartão de armazenamento de 2 GB cheio de dados corporativos confidenciais em um táxi. Felizmente, você também pode usar o Windows Mobile 6 para lidar com esse problema. Ele pode criptografar os dados do cartão de armazenamento para que somente o dispositivo que o gravou possa lê-lo. Assim como muitos outros recursos de segurança avançados do Windows Mobile 6, o Exchange Server 2007 pode ser usado para oferecer esse recurso pelo ar. A criptografia do cartão de armazenamento é totalmente transparente para o usuário. O Exchange Server 2007 permite que o administrador escolha os usuários que poderão alterar as configurações de criptografia de seus cartões de armazenamento.
A capacidade de execução dos aplicativos em um dispositivo Windows Mobile baseia-se em três níveis de permissão: privilegiado, normal e bloqueado. Os aplicativos de nível privilegiado (assinados por um certificado no armazenamento de certificados privilegiado) podem fazer gravações no registro e em arquivos do sistema e também podem instalar certificados. Assim com um Desktop PC ou um servidor, quanto mais houver aplicativos que possam alterar o ambiente do sistema operacional, maiores serão as chances de comprometê-lo. A redução do número de aplicativos com acesso privilegiado é, geralmente, uma boa prática. A maioria dos aplicativos só precisa ser executada em nível normal (aplicativos que são assinados por um certificado no armazenamento de certificados Unpriv ou aplicativos não assinados que o usuário concordou em executar), o que permite a sua execução mas evita que acessem os arquivos do sistema. Os aplicativos bloqueados são justamente isso — estão bloqueados e não podem ser executados devido a uma assinatura incorreta ou a uma ação do usuário.
Os dispositivos podem ter uma configuração de acesso de segurança de uma ou de duas camadas. Com a configuração de acesso de uma camada, os aplicativos não assinados são executados com acesso privilegiado ou estão bloqueados e simplesmente não podem ser executados. Uma configuração de acesso de duas camadas executará aplicativos não assinados em nível normal caso a diretiva seja verificada com sucesso ou se o usuário permitir a execução dos aplicativos. Dependendo das configurações do dispositivo, será solicitado ou não que o usuário execute um aplicativo não assinado.
Certificados digitais — uma das formas mais usadas de autenticação pessoal, de dispositivo e de aplicativo — são uma parte fundamental da segurança do Windows Mobile no dispositivo, no servidor e na rede. O sistema operacional Windows Mobile mantém vários tipos de certificados em armazenamentos diferentes no dispositivo. Quanto aos aplicativos, os certificados determinam quais podem ser instalados e executados. Para que um aplicativo seja executado em um dispositivo com o Windows Mobile sem que o usuário seja consultado, ele precisa estar assinado com um certificado, provando que foi aceito pelo programa Mobile2Mobile da Microsoft. Os aplicativos recebem níveis de permissão com base nos certificados que estão associados a eles.
Para a autenticação de rede, cada dispositivo móvel vem com alguns certificados raiz comerciais confiáveis emitidos pela CA (autoridade de certificação) como mostrado na Figura 5. O servidor de mensagens (por exemplo, o Exchange Server) verifica a autenticidade do certificado raiz de um dispositivo antes de estabelecer uma conexão SSL com ele. Se a sua empresa utiliza certificados personalizados, talvez você seja capaz de instalá-los nos dispositivos com Windows Mobile adquiridos ou talvez seja preciso criar novos certificados. Falarei um pouco mais sobre isso na seção sobre segurança de rede deste artigo.
Figura 5 Gerenciando certificados digitais
Figura 5 Gerenciando certificados digitais
O ActiveSync e o Internet Explorer® Mobile podem usar o SSL na proteção das transmissões de dados entre o dispositivo e um servidor Web corporativo. Isso será verdadeiro se a conexão existir para sincronizar dados do Microsoft Exchange, para configurar o dispositivo ou para baixar aplicativos. O SSL criptografa o canal de comunicação com codificação RC4 ou 3DES de 128 bits para que os dados não possam ser lidos por terceiros. O Windows Mobile também oferece suporte a VPN, que usa a criptografia de pacote para oferecer segurança similar à da linha dedicada durante o acesso ao servidor pela Internet.

Segurança do Exchange Server
Embora os dispositivos com Windows Mobile não exijam o Exchange Server para funcionar, ambos os sistemas foram projetados para trabalhar em conjunto e apresentar uma solução de produtividade e de mensagens móveis de ponta a ponta. Desde o lançamento do Windows Mobile 5.0 com MSFP, o ActiveSync foi aperfeiçoado para permitir o gerenciamento remoto das configurações do dispositivo Windows Mobile. Ele oferece um meio fácil, embora poderoso, de propagar e de impor configurações de segurança globais para a maioria dos dispositivos Windows Mobile.
O ActiveSync é executado no IIS, o componente aplicativo/servidor Web do Microsoft Windows Server 2003. O IIS oferece segurança interna que o ajuda a proteger o próprio ActiveSync de ataques vindos da rede. Como o OWA (Outlook® Web Access) do Microsoft Outlook também se baseia no IIS, você poderá usar os mesmos certificados de segurança para ele e para o ActiveSync.
Quando o ActiveSync é usado para propagar uma diretiva corporativa, tal diretiva será entregue aos dispositivos na próxima vez em que eles fizerem a sincronização com o Exchange Server. Os usuários devem aceitar as alterações ou não serão capazes de se conectar ao servidor. Muitas redes lidam com uma grande variedade de dispositivos, incluindo hardware herdado que não aceita diretivas de segurança sofisticadas. Se for necessário, você pode isentar certos dispositivos, como o hardware herdado, do requisito da diretiva de segurança para que eles possam continuar a se conectar.
O Exchange Server 2003 SP2 e o Exchange Server 2007 possuem recursos de controle de diretiva de segurança um pouco diferentes. O Exchange Server 2003 SP2 pode ser usado para especificar um comprimento mínimo de senha de 4 a 18 caracteres, exige números e letras na senha e define o período de inatividade permitido antes do bloqueio do dispositivo. Essa versão do Exchange Server também pode definir a freqüência com que as configurações de segurança devem ser impostas aos dispositivos, assim como pode permitir as isenções citadas anteriormente para dispositivos herdados.
Com o lançamento do Exchange Server 2007, os recursos de gerenciamento de dispositivos móveis do ActiveSync foram aperfeiçoados para incluir todos os recursos do Exchange Server 2003 SP2 mais o seguinte:
  • Permitir ou não as senhas simples (como "1234" ou "1111")
  • Ativar ou desativar o download de anexos
  • Exigir a criptografia do cartão de armazenamento
  • Definir o tamanho máximo do anexo
  • Permitir que o usuário recupere a senha de um dispositivo pelo OWA
  • Permitir o acesso a arquivos UNC (convenção de nomenclatura universal) e WSS (Microsoft Windows SharePoint® Services)
Com o Exchange Server 2007, os profissionais de TI têm a flexibilidade de ajustar as diretivas a cada usuário ou dispositivo para gerenciar diretivas para grupos de usuários, assim como isentar usuários específicos de diretivas de segurança.

Apagamento remoto de acesso
Além do apagamento de dispositivo local detalhado anteriormente, você pode limpar um dispositivo com Windows Mobile de forma remota, usando o Exchange Server 2003 SP2, o Exchange Server 2007 ou o OWA. Os apagamentos remotos, que acontecem na sincronização, podem ser executados mesmo que você não esteja usando as diretivas de segurança do ActiveSync. Uma redefinição definitiva de apagamento remoto não pode ser interrompida no dispositivo. Dados, configurações e chaves de segurança são substituídos por zeros repetidos, fazendo com que seja extremamente difícil recuperar dados que não façam parte do núcleo do sistema operacional.

Segurança de rede
A segurança de rede é tão importante para a segurança móvel quanto os componentes de servidor de mensagens e de dispositivos. Ela também é parte da infra-estrutura móvel que você claramente controla. Mesmo que um ou mais dispositivos móveis sejam comprometidos, configurar a sua rede corporativa de acordo com as práticas recomendadas e implementar os protocolos de segurança corretos poderá ajudá-lo a evitar danos em sua rede.
O Windows Mobile funciona bem com uma variedade de tipos de rede. Usando protocolos de segurança da Internet e firewalls padrão, você pode projetar uma solução que atenda às suas necessidades de desempenho, de estabilidade e de segurança.
Quando servidores de mensagens são mantidos em uma rede corporativa, podem ser protegidos por um firewall de borda que agirá como um buffer entre a Internet e os servidores corporativos. O Microsoft ISA (Internet Security and Acceleration) Server 2004 ou o ISA Server 2006, ambos com recursos projetados especialmente para essa finalidade, inspecionam todos os pacotes de entrada para a determinação de sua identidade antes de passá-los para os servidores Exchange e então enviam informações de saída de volta ao cliente via Internet.
A configuração do ISA Server requer que você habilite a criptografia SSL e especifique a porta 443 como a porta Web SSL que escutará o tráfego do Exchange Server. Isso minimiza a exposição à Internet ao limitá-la a uma única porta. Além disso, deve-se exigir que todos os clientes estabeleçam um link SSL antes de se conectar via ActiveSync.
O ISA Server pode autenticar previamente os usuários de aplicativos Web como o OWA para ajudar a evitar que usuários não autenticados cheguem aos servidores de aplicativos. O ISA Server 2006 aperfeiçoa o modelo de ponte SSL do ISA Server 2004 agindo como o ponto de terminação do SSL para os dispositivos com Windows Mobile. Isso permite que os dispositivos com Windows Mobile sejam autenticados no servidor Exchange, sem nem ao menos uma conexão direta com ele, em vez de confiar no ISA Server 2006 para a passagem do tráfego. E, uma vez que o local recomendado para o ISA Server 2006 é a rede de perímetro, isso gera uma camada extra de segurança entre a nuvem de Internet pública e o front-end do Exchange Server.

Autenticação
Existem dois tipos básicos de autenticação que você pode escolher: a básica e a baseada em certificado. A básica se refere a uma conexão baseada em SSL com nome e senha padrão entre um cliente Windows Mobile e o servidor Exchange de front-end. Ela ainda requer um certificado, já que o Exchange Server procura por uma ocorrência do certificado raiz no dispositivo antes da autenticação. O Windows Mobile e o IIS permitem que você use um conjunto maior de metodologias de criptografia associadas ao SSL.
A autenticação baseada em certificado, disponível no Windows Mobile 5.0 com MSFP e no Windows Mobile 6, usa a TLS (segurança da camada de trabalho) em vez da autenticação básica SSL. Além do certificado raiz, a TLS exige que cada usuário tenha um certificado com chaves pública e privada. Como a TLS usa uma chave de criptografia (de até 2048 bits) em vez de uma senha, esse protocolo oferece uma autenticação mais forte.
Com o Windows Mobile 6, registrar um certificado de usuário com o Desktop Enroll requer que o dispositivo esteja encaixado em um desktop que esteja no mesmo domínio do servidor de registro de certificados. O usuário autentica o registro usando uma senha, um cartão inteligente ou um outro método e então conecta o dispositivo a um desktop PC. Em seguida, o usuário acessa o sistema de certificado por meio do desktop que, por sua vez, instala o certificado no dispositivo móvel. O Desktop Enroll pode servir a uma grande variedade de fins de segurança do Windows Mobile, incluindo a renovação de certificados, assim como a distribuição de certificados de autenticação do ActiveSync, certificados de autenticação SSL/TLS, certificados Wi-Fi 802.1x ou certificados de assinatura digital S/MIME.
Os protocolos de segurança como o SSL protegem os dados da mensagem enquanto eles estão em trânsito, mas não os criptografam quando eles chegam ao dispositivo Windows Mobile ou ao servidor Exchange. O S/MIME é uma forma segura do conhecido padrão de email MIME que oferece suporte a emails criptografados e/ou assinados digitalmente. Isso oferece uma camada adicional de proteção sobre ou abaixo da criptografia de camada de transporte do SSL.

Encerramento
É o exame cuidadoso de cada uma das muitas camadas que formam uma solução que criará uma infra-estrutura suficientemente segura. O Windows Mobile, o Exchange Server e os produtos de segurança de rede da Microsoft, como o ISA Server, trabalham juntos para diminuir muito a dificuldade de gerenciamento da infra-estrutura móvel. Isso ajuda a tirar um pouco da pressão sobre os departamentos de TI, mudando o foco dos desafios de segurança criados por dispositivos móveis para os aumentos de produtividade que eles possibilitam.

Agradeço especialmente a Kathy Esser, Katharine Holdsworth, Sarah Norton e Chip Vollers por sua assistência na criação deste artigo.

Matt Fontaine é escritor de tecnologia da BuzzBee Company.


 Comunica&#231;&#245;es: Uma alternativa poderosa para pastas p&#250;blicas
Comunicações Alan Maddison

Uma alternativa poderosa para pastas públicas
Visão geral:
  • Compartilhar calendários e contatos
  • Comunicar com blogs e wikis
  • Compartilhar e gerenciar documentos

As pastas públicas existem desde a primeira versão do Microsoft Exchange, com o objetivo original de fornecer uma plataforma básica para compartilhamento de documentos, arquivamento de listas de distribuição e desenvolvimento de aplicativos personalizados. Desde o início,
porém, os administradores sofrem com o gerenciamento e usam o que se tornou uma elemento cada vez mais complexo de muitos ambientes do Exchange. Embora o Exchange Server 2007 introduza algumas melhorias significativas no gerenciamento de pastas públicas, o desafio permanece. As pastas públicas simplesmente não oferecem a plataforma robusta de gerenciamento de documentos e de colaboração de que as empresas precisam atualmente.
A Microsoft declarou que o Exchange Server 2007 pode ser a última versão do produto com suporte para pastas públicas. Já que elas possuem total suporte, e continuarão a tê-lo por mais dez anos após o lançamento do Exchange Server 2007, este é um bom momento para examinar uma alternativa.
Felizmente, a Microsoft forneceu uma opção interessante com o lançamento do MOSS (Microsoft® Office SharePoint® Server) 2007. O MOSS 2007 oferece a plataforma de que as empresas e os administradores de TI precisam para substituir e ir além dos recursos oferecidos pelas pastas públicas. Neste artigo, demonstro que o MOSS apresenta uma estrutura robusta e poderosa que pode oferecer recursos muito mais importantes do que as pastas públicas do Exchange. Em especial, descrevo como usar o SharePoint para tarefas normalmente executadas por meio das pastas públicas, como compartilhar calendários, contatos e documentos.
Tenha em mente que você ainda precisará das pastas públicas, pelo menos até atualizar seus clientes. Os clientes do Microsoft Outlook®, desde o Outlook 97 até o Outlook 2003, precisam das pastas públicas por diversos motivos, incluindo o Catálogo de Endereços Offline, a Biblioteca de Formulários Organizacionais e pesquisas de disponibilidade. Assim que você migrar para o Outlook 2007 e o Exchange Server 2007, poderá eliminar totalmente o uso das pastas públicas quando estiver pronto.

Calendários do SharePoint
Os calendários compartilhados são comumente usados nas pastas públicas, e o SharePoint facilita muito a tarefa de substituir um calendário seu por um calendário da pasta pública. Embora uma instalação padrão de um site do SharePoint inclua um calendário, você provavelmente precisará criar vários calendários para acomodar as necessidades da sua organização. Para provar isso, descreverei a criação de um calendário compartilhado por uma equipe de recursos humanos. A primeira etapa é selecionar Exibir Todo o Conteúdo do Site, que normalmente é mostrado no canto superior esquerdo do site do SharePoint (consulte a Figura 1).
Figura 1 Criando um novo conteúdo de site
Figura 1 Criando um novo conteúdo de site
Depois de selecionar Exibir Todo o Conteúdo do Site, clique no botão Criar (que também é mostrado na Figura 1). Depois que a página Criar for carregada, você verá as opções de tipo de conteúdo padrão (como mostra a Figura 2). Para criar um calendário, selecione Calendário na coluna Controle. Em seguida, preencha os campos de nome e descrição e escolha se irá incluir o calendário na seção Links Rápidos.
Figura 2 A página Criar exibe várias opções padrão
Figura 2 A página Criar exibe várias opções padrão
Nesse momento, o calendário é criado. O usuário tem a opção de exibir o calendário compartilhado pelo site do SharePoint ou diretamente de dentro do Outlook. Se escolher a segunda alternativa, o usuário terá de se conectar ao calendário usando um navegador da Web, abrir o menu Ações e selecionar a opção Conectar-se ao Outlook.
Quando a conexão é realizada pela primeira vez, o Outlook exibe um aviso de segurança para lembrar aos usuários que eles devem se conectar apenas a fontes conhecidas e confiáveis. Ao selecionar Sim, o calendário se conectará ao Outlook. A Figura 3 mostra a exibição padrão, que exibe os calendários do SharePoint e do Outlook lado a lado.
Figura 3 Exibindo os calendários do SharePoint e do Outlook lado a lado
Figura 3 Exibindo os calendários do SharePoint e do Outlook lado a lado
Depois que o calendário se conecta ao Outlook, pode ocorrer uma sincronização bidirecional. Os eventos inseridos por meio do Outlook são sincronizados com o SharePoint, e todos os usuários que exibirem o calendário poderão ver as entradas atualizadas. Além disso, se você tiver habilitado o suporte a SMTP dentro do SharePoint, os eventos poderão ser enviados por email diretamente ao calendário, e o SharePoint adicionará essas entradas.

Contatos do SharePoint
Contatos compartilhados, que também dependem de pastas públicas, são usados por muitas organizações. Também neste caso, o SharePoint fornece uma alternativa mais robusta, facilitando a criação e o gerenciamento das listas de contatos. Continuando com o mesmo exemplo, agora mostrarei como criar uma lista de contatos compartilhados para o departamento de recursos humanos.
Novamente, selecione Exibir Todo o Conteúdo do Site e clique no botão Criar. Selecione o link Contatos na coluna Comunicações. É exibida uma tela em que são fornecidas informações para a configuração de Nome, Descrição e Link Rápido (consulte a Figura 4). Ao concluir essas informações, simplesmente clique no botão Criar e uma nova lista Contatos será criada.
Figura 4 Preenchendo a configuração de Nome, Descrição e Link Rápido
Figura 4 Preenchendo a configuração de Nome, Descrição e Link Rápido

Comunicação do usuário
Você também pode usar o SharePoint para criar um quadro de discussões (também conhecido como lista de discussão). Assim como ocorre com Calendários e Contatos, o processo de criação é muito simples: selecione Exibir Todo o Conteúdo do Site, clique no botão Criar e selecione o link Quadro de Discussão na coluna Comunicações. Como você fez anteriormente, preencha as informações apropriadas para a configuração de Nome, Descrição e Link Rápido e, em seguida, clique no botão Criar. A Figura 5 mostra um quadro de discussão com alguns exemplos de postagens.
Figura 5 Um exemplo de quadro de discussão com algumas postagens
Figura 5 Um exemplo de quadro de discussão com algumas postagens
Além dos quadros de discussão, o SharePoint Server agora oferece suporte a duas ferramentas de comunicação conhecidas: blogs e wikis. Não disponíveis em pastas públicas, as ferramentas de blogs e wikis são novidade no SharePoint Server 2007 e fornecem ao conjunto de recursos habilidades de colaboração interessantes e úteis.
Os blogs fornecem um fórum interativo em que um blogger pode compartilhar facilmente pensamentos e idéias, postando-os em um site da Web. Em geral, essas postagens são categorizadas para facilitar aos leitores a localização de postagens de seu interesse. Ao mesmo tempo, os leitores podem fornecer respostas aos comentários de um blogger. Em uma empresa, por exemplo, os membros de gerenciamento executivo talvez tenham de manter um blog. Essa pode ser uma poderosa ferramenta de comunicação com os funcionários, e ela ainda oferece aos membros da equipe um meio de compartilhar idéias e manter uma comunicação fluente em todos os níveis.
Criar um blog em um SharePoint é fácil. A primeira etapa é selecionar Exibir Todo o Conteúdo do Site, clicar no botão Criar, em Sites e em Espaços de Trabalho sob a coluna Páginas da Web. Isso leva você à página Novo Site do SharePoint, em que é necessário fornecer Título, Nome e URL para o site. Depois você escolhe um modelo para o site, neste caso, escolha o modelo Blog. As últimas três opções de configuração são para permissões, navegação e lista de diretórios de site. Depois de concluir todas as opções necessárias, pressione o botão Criar. Isso criará um subsite, dentro do site de nível superior, contendo bibliotecas e listas que fornecem recursos de blog. Assim que o processo for concluído, você será encaminhado ao novo blog.
Wiki é outra ótima ferramenta projetada para uma criação com muito mais colaboração. Os usuários podem adicionar, remover e editar o conteúdo do site, assim como vincular várias páginas. A maneira mais fácil de criar um wiki é selecionar Exibir Todo o Conteúdo do Site, clicar no link Criar e selecionar a opção Biblioteca de Páginas Wiki listada na coluna Bibliotecas. Depois de preencher os campos de configuração obrigatórios de Nome, Descrição e Navegação, pressione o botão Criar para concluir. Para obter mais informações sobre o uso de wikis no SharePoint, consulte o artigo "Wiki enquanto você trabalha" na edição de janeiro de 2007 da TechNet Magazine.

Bibliotecas do SharePoint
As pastas públicas, na verdade, tornaram-se repositórios de documentos, fornecendo um local central no qual os usuários podem acessar e compartilhar documentos com facilidade. Como os administradores do Exchange descobriram há anos, essa é uma das aplicações básicas que tornaram as pastas públicas tão complicadas. Além de causar um aumento na entrada e saída do Exchange para o banco de dados das pastas públicas, isso também afeta a replicação em toda a infra-estrutura do Exchange. As bibliotecas do SharePoint são uma excelente alternativa, aliviando a demanda do Exchange e de seus recursos.
A Biblioteca do SharePoint é um local dentro de um site do SharePoint que permite armazenar e gerenciar arquivos. Há vários tipos de Bibliotecas que incluem Imagem, página Wiki, Formulários e Documento. Ao considerar um substituto para as pastas públicas, a Biblioteca de Documentos é a escolha mais apropriada. A Biblioteca de Documentos oferece suporte a armazenamento, gerenciamento e, em alguns casos, criação de documentos dentro do site do SharePoint.
Muitos tipos diferentes de arquivos podem ser armazenados em uma Biblioteca de Documentos, mas outros, como arquivos executáveis e de scripts, são restritos por padrão por motivos de segurança. Essas restrições, entretanto, podem ser configuradas por meio da seção Operações do site Administração Central do SharePoint.
Uma instalação padrão do MOSS inclui uma Biblioteca de Documentos que pode ser personalizada. A maioria das organizações pensará em criar várias bibliotecas para oferecer suporte às suas diferentes unidades de negócio. Essa é uma tarefa fácil usando as ferramentas fornecidas pelo SharePoint. Por exemplo, ao implantar uma Biblioteca de Documentos para o departamento de recursos humanos, selecione Exibir Todo o Conteúdo do Site, clique no link Criar e escolha a opção Biblioteca de Documentos listada na coluna Bibliotecas. Você verá diversas configurações a serem definidas: fornecer um nome e uma descrição para a biblioteca, especificar se a biblioteca será incluída na seção Links Rápidos, escolher se o controle de versões será habilitado e selecionar um formato padrão para os novos documentos criados diretamente na biblioteca.
Preste especial atenção à opção Histórico de Versão do Documento. A seleção padrão para ela é desabilitada. Entretanto, o controle de versões pode ser útil e apropriado em vários ambientes. Além de armazenar cópias históricas de documentos, essa funcionalidade controla quando as alterações são feitas e quem as faz, e também fornece a capacidade de exibir e restaurar versões anteriores.
A Figura 6 mostra a Biblioteca de Documentos recentemente criada com alguns documentos que foram carregados. Depois de criar suas bibliotecas de documentos, você poderá disponibilizar esses repositórios pelo Microsoft Outlook e pelo Windows® Explorer. O Outlook permite obter o conteúdo de uma Biblioteca de Documentos offline e oferece uma cópia somente leitura para os usuários que não possuem acesso à rede. O acesso por meio do Windows Explorer tira proveito de Meus locais de rede. Ao inserir a URL da Biblioteca de Documentos, você poderá fornecer acesso aos seus usuários. Em documentos maiores, você poderá considerar o uso da Diretiva de Grupo para implantar esses locais de rede.
Figura 6 Biblioteca de Documentos, contendo alguns documentos que foram carregados
Figura 6 Biblioteca de Documentos, contendo alguns documentos que foram carregados

Além das noções básicas
O SharePoint fornece um conjunto de recursos muito superior ao fornecido pelas pastas públicas. Além de apresentar algumas funcionalidades comuns das pastas públicas, o SharePoint Server também fornece recursos mais poderosos capazes de incrementar essas funcionalidades. Esses recursos aprimorados incluem:
  • Histórico de versões
  • Controle de aprovação
  • Procedimentos de check-out
  • Controle de fluxo de trabalho
  • Diretivas de retenção de documentos
  • Auditoria
  • RSS
Recursos como esses são essenciais para qualquer plataforma de gerenciamento de conteúdo corporativo, e o SharePoint fornece uma estrutura de trabalho robusta que os administradores podem usar com tranqüilidade. Essa funcionalidade aprimorada pode ser habilitada para vários recursos do SharePoint, incluindo calendários, tarefas, quadros de discussão e bibliotecas de documentos.
Para configurar essa funcionalidade, selecione o menu Configurações e escolha a opção de configurações, por exemplo, a opção Definições da Biblioteca de Documentos, como mostra a Figura 7. Será exibida a página Configurações, na qual é possível exibir todas as opções de configuração e personalização disponíveis. As configurações de Controle de Versão na coluna Configurações Gerais, por exemplo, permitem configurar o histórico de versões.
Figura 7 Selecionando a opção de configurações para definir a funcionalidade aprimorada
Figura 7 Selecionando a opção de configurações para definir a funcionalidade aprimorada
Como mencionei anteriormente, essa funcionalidade fornece um registro das alterações do documento, incluindo quem as fez e quando elas foram feitas, e permite ao usuário exibir e restaurar versões anteriores, se necessário. Também é possível controlar quantas versões são armazenadas pelo SharePoint. Quando o limite é alcançado, os itens são excluídos sem serem enviados à Lixeira do SharePoint.
A seção Controle de Versão também permite configurar os requisitos de Aprovação de Conteúdo e Check-out necessários. Quando a opção Aprovação de Conteúdo é habilitada, todo item enviado deve ser aprovado antes de estar disponível para outros usuários. Os itens que não são aprovados permanecem em um estado pendente. O processo de Check-out fornece um controle de conteúdo, impedindo que vários usuários trabalhem em um arquivo ao mesmo tempo.
O fluxo de trabalho é outro recurso útil oferecido pelo SharePoint que não está disponível nas pastas públicas. Basicamente, os fluxos de trabalho oferecem uma abordagem estruturada aos processos corporativos que podem ajudar a simplificar as operações da sua empresa. Implementados dentro do SharePoint, os fluxos de trabalho são uma série de tarefas predefinidas que automatizam o movimento de um documento por meio do processo designado. O processo pode ser iterativo, exigindo que cada etapa seja concluída antes de passar para a seguinte, ou pode ser paralelo, permitindo que qualquer tarefa seja concluída a qualquer momento. Os fluxos de trabalho padrão incluídos com o SharePoint são:
  • Aprovação
  • Coletar Comentários
  • Coletar Assinaturas
  • Aprovação de Disposição
As diretivas de gerenciamento de informações são usadas para impor a conformidade com os regulamentos e os requisitos corporativos. As diretivas consistem em um conjunto de regras relacionadas a gerenciamento e controle de documentos. O SharePoint Server oferece suporte a regras personalizadas, mas inclui regras padrão úteis como:
  • Auditoria
  • Expiração
  • Rótulos
  • Códigos de barras
A auditoria fornece a capacidade de registrar eventos com base em um conjunto de ações definidas dentro das configurações do site. Você pode controlar essas ações abrindo um documento, baixando ou exibindo um item ou suas propriedades, editando um documento, fazendo check-in ou check-out do documento, movendo ou copiando itens e excluindo ou restaurando itens.
A expiração de conteúdo permite excluir conteúdo para manter a conformidade com as diretivas de retenção de dados da sua organização. A expiração de dados pode ocorrer em uma data específica ou em um período fixo depois da ocorrência de um determinado evento, como a criação de um documento.
Os rótulos são usados com a impressão, adicionando texto à cópia impressa. Na prática, essa política pode ter diversas utilidades. Por exemplo, você pode exigir que todos os documentos de recursos humanos compartilhados na Biblioteca de Documentos tenham um aviso de confidencialidade, para que estejam em conformidade com os regulamentos do departamento jurídico.
Os códigos de barras fornecem um método de rastreamento formal para documentos online e impressos. O SharePoint criará um identificador exclusivo para cada documento, e os usuários terão a capacidade de inserir uma imagem do código de barras em seus documentos.
Outro aprimoramento importante que o SharePoint oferece é sua integração com RSS feeds. Calendários, contatos, bibliotecas de documentos e quadros de discussão, tudo fornecerá um RSS feed no qual o usuário poderá se inscrever. Seus usuários poderão receber atualizações automáticas para ajudar a manter o controle de suas responsabilidades diárias, bastando para isso ter um leitor RSS, como o Outlook 2007.

Últimas palavras
O Microsoft Office SharePoint Server 2007 fornece recursos de nível empresarial e oferece uma alternativa muito mais poderosa para as pastas públicas do Exchange. Com uma estrutura de trabalho administrativa robusta, fica fácil implementar uma solução para compartilhar calendários, contatos e documentos. Você também pode criar diversos meios de comunicação, incluindo fóruns de discussão, blogs e wikis.

Alan Maddison é consultor sênior em aplicação da tecnologia Microsoft da MTI Technology Corporation. Seu foco principal é o Active Directory, o Exchange Server e virtualização.


 Comunica&#231;&#245;es: Logon no Outlook Web Access com cart&#245;es inteligentes
Comunicações Victor Akinnagbe and Ted Dressel and Jason Opdycke

Logon no Outlook Web Access com cartões inteligentes
Visão geral:
  • Autenticação de dois fatores
  • Delegação restrita de Kerberos
  • Configuração do ISA Server e do Exchange

Os funcionários móveis apresentam um desafio de segurança único para as organizações de TI. Os usuários remotos precisam de acesso seguro a dados e serviços como email. Contudo, infelizmente, a realidade é que os
os vínculos mais vulneráveis na cadeia de segurança envolvem senhas fracas, malware (como keyloggers) e vírus nos computadores remotos que acessam os recursos internos da sua organização.
Uma maneira de aumentar a segurança nesse ambiente móvel é remover um desses vínculos vulneráveis: as senhas (embora a idéia de permitir acesso a uma conta sem uma senha para autenticação possa parecer estranha). Uma técnica básica para eliminar os problemas associados às senhas é conhecida como autenticação de dois fatores (ou, às vezes, de multifatores). Em vez de contar com um único método, uma senha, para permitir acesso, a autenticação de dois fatores impõe o uso de métodos adicionais de autenticação, incluindo uma combinação de nome de usuário/senha, um dispositivo físico, como um cartão inteligente, ou um identificador biométrico, como impressão digital.
Se você tiver usuários remotos, provavelmente terá de abrir um pouco o seu firewall para permitir o acesso remoto à rede corporativa. Um firewall padrão proporciona uma redução básica de risco, fornecendo um isolamento no nível de rede entre as redes interna e externa (consulte a Figura 1). Para obter uma segurança adicional, as portas são simplesmente fechadas e, se a comunicação precisar acontecer com um dispositivo na rede interna, elas serão encaminhadas para o local correto. Essas técnicas fornecem uma proteção considerável no nível de rede, porém, agora várias camadas de segurança de rede tornaram-se necessárias devido a ataques cada vez mais sofisticados.
Figura 1 Firewall padrão com portas bloqueadas ou encaminhadas
Figura 1 Firewall padrão com portas bloqueadas ou encaminhadas
Como os funcionários móveis com acesso aos serviços corporativos mais comuns, em geral, são aqueles que usam email e sistema de mensagens, a configuração da infra-estrutura do Exchange, sem dúvida, nunca foi tão importante. Fornecer aos usuários o acesso ao email por meio do OWA (Outlook® Web Access) é uma maneira de proporcionar serviços seguros aos funcionários móveis. Outra etapa-chave é fornecer uma autenticação segura de dois fatores para o OWA por meio de cartões inteligentes. Neste artigo, examinaremos com mais detalhes a configuração e os problemas que você deve conhecer ao fazer a implantação do OWA habilitado para cartão inteligente.

Melhor do que um firewall
A implantação do ISA (Microsoft® Internet Security and Acceleration) Server 2006 na sua rede pode simplificar a tarefa de abrir a rede para usuários remotos de maneira mais segura. O ISA Server 2006 inclui recursos de aprimoramento de segurança, como VPN habilitada para cartão inteligente, autenticação LDAP para o Active Directory® e delegação restrita de Kerberos. O ISA Server é um pouco diferente do que normalmente se entende por firewall. Ele apresenta várias camadas de segurança, não apenas funcionando na camada de rede, com ou sem o hardware de firewall padrão, mas também fornecendo recursos de segurança adicionais que normalmente não possuem suporte nos firewalls tradicionais, como filtros de aplicativos. Você não quer que ninguém use o método HTTP POST em um site hospedado em particular? Você quer forçar a conformidade RFC em mensagens SMTP antes que cheguem a seu servidor Exchange? Você quer inspecionar os pacotes HTTP SSL (Secure Sockets Layer) antes que eles entrem na rede? O ISA Server pode gerenciar todas essas tarefas e muito mais a fim de garantir que somente um tráfego limpo e filtrado seja encaminhado para a sua DMZ (zona desmilitarizada) ou rede interna.
As sessões SSL são um grande problema para os firewalls padrão. Quando passam pelo firewall, os pacotes permanecem criptografados (o que significa que o SSL está funcionando corretamente). Assim, se um aplicativo como o OWA for publicado por meio de um firewall de hardware ou software usando SSL, não haverá nenhum tipo de inspeção apreciável que possa ser feita pelo firewall padrão, a não ser a inspeção do estado do pacote. O simples fato de abrir e encaminhar portas pode deixar uma área exposta de superfície de ataque considerável. Como nenhuma inspeção real está acontecendo na borda, os pacotes não inspecionados ou não autenticados podem ser roteados para a rede interna.
O ISA Server 2006 pode atuar como um ponto de extremidade SSL para clientes HTTP, garantindo que somente o tráfego autorizado alcance o servidor Exchange publicado. O ISA Server oferece suporte a um recurso útil chamado ponte SSL. Normalmente, um pacote é criptografado por um cliente que se comunica por meio de uma sessão SSL padrão com o ISA Server. Com a ponte SSL, o ISA Server pode terminar a criptografia SSL localmente, inspecionar o pacote que, neste caso, não é criptografado, autenticar o usuário para o Active Directory (se necessário), criptografar novamente o pacote usando SSL e passar o pacote criptografado para o servidor Exchange apropriado (consulte aFigura 2). Usando essa técnica, a ponte SSL minimiza os ataques ocultos dentro de uma sessão SSL, que não pareceriam nada além de blobs de dados criptografados para um firewall sem suporte para aplicativo.
Figura 2 O ISA Server obtém uma exibição do tráfego na camada do aplicativo
Figura 2 O ISA Server obtém uma exibição do tráfego na camada do aplicativo
O tráfego pré-autenticado que alcança o servidor é um ponto importante a se notar quanto à delegação restrita de Kerberos. Em um firewall padrão, as portas são simplesmente encaminhadas para o servidor Exchange, e o próprio servidor front-end é responsável por executar as tarefas de autenticação em relação aos possíveis usuários mal-intencionados. Quando a autenticação é necessária, o ISA Server pode contatar diretamente o Active Directory e fazer a solicitação de credenciais em nome do usuário. Se o usuário for autenticado com êxito, o ISA Server encaminhará a mensagem ao servidor front-end do Exchange. O servidor front-end não precisa mais autenticar solicitações aleatórias desconhecidas de usuário e pode ser usado unicamente para atuar como proxy nas solicitações a servidores back-end. O ISA Server 2005 também pode usar a delegação restrita de Kerberos para permitir acesso com base em certificado a tecnologias como Windows SharePoint Services e Exchange ActiveSync.
O Exchange Server 2003 incluiu suporte para autenticação com base em Kerberos entre servidores front-end e back-end para logins do OWA. (Você está usando IPsec para proteger o tráfego de cliente, certo?) O Exchange Server também oferece suporte à autenticação de Kerberos a servidores de caixa de correio em cluster.

Habilitando a autenticação de cartão inteligente
A implementação da autenticação com base em cartão inteligente para o OWA tornou-se um desafio. Entretanto, desenvolveu-se uma solução com base no recurso de delegação restrita de Kerberos que, agora, está disponível no ISA Server 2006. A solução permite ao usuário enviar credenciais por meio de um certificado a fim de obter uma autenticação bem-sucedida para o OWA. A delegação restrita veio como um aperfeiçoamento bem-vindo do suporte à delegação de Kerberos no Windows® 2000, que usava delegação irrestrita. A função restrita de Kerberos é mais segura e limita o possível risco de ataques sofisticados usando a representação.
No cenário habilitado para cartão inteligente, o ISA Server 2006 contata o Active Directory para autenticar o usuário, já que este não possui acesso roteável para o KDC (centro de distribuição de chaves) da rede externa. O ISA Server submete-se ao mapeamento de usuários de certificado do Active Directory para autenticar o usuário e adquire os tíquetes Kerberos com base no UPN (nome de usuário principal). Nesse caso, o ISA Server está fornecendo a funcionalidade de delegação restrita de Kerberos a um servidor front-end por meio dos serviços de proxy reverso e filtragem no nível de aplicativo. Se houvesse uma tentativa de delegação sem um proxy reverso, o maior risco de explorações poderia afetar a integridade da rede ou do domínio do Active Directory.
O Exchange Server 2003 e o 2007 permitem a autenticação básica e integrada. Entretanto, é necessário aplicar uma atualização de software ao Exchange Server 2003 para a autenticação com base em cartão inteligente de forma que o OWA funcione. (Para obter mais informações, consulte o artigo "Descrição do novo recurso do Exchange Server 2003 que oferece suporte à autenticação de cartão inteligente para o Outlook Web Access".) Você deve ter um domínio no modo funcional nativo do Windows Server® 2003, todos os servidores do Exchange Server 2003 devem ter o SP2 ou superior aplicado e você precisa de um servidor ISA Server 2006 atuando como proxy reverso para o site do OWA.
Depois de instalar a atualização de software e configurar os servidores do Exchange e ISA, os usuários poderão autenticar uma sessão do OWA usando cartões inteligentes. A Figura 3 mostra o fluxo de eventos necessário para a autenticação de cartão inteligente. Primeiro, o usuário abre o site do OWA no Internet Explorer® (1). Na verdade, ele se conecta ao ISA Server e é solicitado a fornecer um certificado, em vez de nome de usuário e senha, para iniciar a sessão do OWA. O certificado apropriado é armazenado no cartão inteligente, para o qual o usuário precisa de um PIN.
Figura 3 Autenticando o OWA com um cartão inteligente
Figura 3 Autenticando o OWA com um cartão inteligente
A validação de certificado (2) é manipulada por meio de uma CRL (lista de certificados revogados) ou de uma solicitação OCSP (protocolo de status de certificados online), dependendo da configuração do ISA Server e de outro software instalado. O ISA Server faz uma solicitação para um DC (controlador de domínio) a fim de verificar as credenciais do usuário. Se a solicitação falhar, o ISA Server apresentará uma página de erro ao usuário e nenhuma solicitação chegará ao servidor front-end do Exchange.
Depois que as credenciais são verificadas, o tíquete Kerberos é gerado e a solicitação é passada para o servidor front-end do Exchange, usando autenticação integrada (3). Ao receber a solicitação, o servidor front-end do Exchange valida o tíquete Kerberos e localiza o servidor de caixa de correio back-end (4).
O servidor front-end solicita um tíquete Kerberos para o servidor back-end apropriado por meio da delegação restrita de Kerberos e atua como proxy na solicitação de caixa de correio para o servidor back-end, usando autenticação integrada (5). A solicitação é atendida pelo servidor back-end (6) e os dados de caixa de correio são retornados ao servidor front-end do Exchange (7). Os dados HTML para a página OWA são passados para o ISA Server (8), que os repassa de volta para o computador cliente (9).

Configurando o ambiente do Exchange
O artigo da Base de Dados de Conhecimento mencionado anteriormente descreve a atualização de software para o Exchange Server 2003 e inclui informações que ajudarão a guiá-lo no processo de habilitar a delegação restrita de Kerberos usando o ISA Server 2006 e o Exchange Server 2003.
A principal ação que a atualização de software permite é automatizar o processo de delegação restrita de Kerberos do servidor front-end do Exchange para os respectivos servidores back-end. A atualização não automatizará o processo de delegação restrita de Kerberos do ISA Server para o servidor front-end, já que o ISA Server não faz parte da organização do Exchange. A delegação terá de ser habilitada manualmente de cada instância do ISA Server para cada servidor front-end do Exchange.
A atualização de software adiciona uma nova guia no ESM (Gerenciador do Sistema do Exchange) que permite designar um servidor front-end do Exchange como um KCD-FE (consulte a Figura 4); este, por sua vez, permite que o servidor seja preenchido na guia de delegação dos respectivos servidores back-end do Exchange.
Figura 4 Habilitando a delegação restrita de Kerberos
Figura 4 Habilitando a delegação restrita de Kerberos
A nova interface do usuário permite especificar nas propriedades do Grupo Administrativo as credenciais que devem ser usadas para preencher o atributo msDS-AllowedToDelegateTo (A2D2), como mostra a Figura 5. Esse é o atributo responsável pela delegação restrita de Kerberos.
Figura 5 Configurando a conta que controla a delegação
Figura 5 Configurando a conta que controla a delegação
Respeitando o princípio do privilégio mínimo, você pode usar uma conta de usuário padrão e conceder-lhe a capacidade de delegar usuários e computadores por meio de um GPO (Objeto de Diretiva de Grupo). Depois que essa permissão elevada for concedida, a conta poderá ser usada como uma conta de serviço a fim de automatizar o processo de delegação restrita de Kerberos para o respectivo Grupo Administrativo.
Verifique se você executou as etapas apropriadas para impedir que um usuário mal-intencionado seja capaz de comprometer a conta de serviço de delegação restrita de Kerberos. Mesmo que a conta não seja de administrador de domínio, o acesso a ela poderia levar a ataques sofisticados que tirem vantagem da delegação de Kerberos. Como não possui a capacidade de estabelecer novas associações de Kerberos, a conta deve ser usada com cuidado. Tome as precauções necessárias para garantir a segurança e a integridade da conta: uma senha longa e complexa, aumento de auditoria, técnicas de desabilitação de conta e assim por diante.
A atualização de software do Exchange também faz uma alteração muito importante na interface ESM em relação à autenticação integrada. Anteriormente, no Exchange Server 2003, quando um servidor era atribuído como front-end, a opção para habilitar a Autenticação Integrada do Windows para Diretórios Virtuais HTTP (sob o Servidor Virtual HTTP) ficava cinza (consulte Figura 6).
Figura 6a A atualização habilita a autenticação integrada
Figura 6a A atualização habilita a autenticação integrada
Figura 6b A atualização habilita a autenticação integrada
Figura 6b A atualização habilita a autenticação integrada
Isso ocorria porque não havia suporte para a autenticação integrada nos servidores front-end do Exchange em decorrência de problemas técnicos, como o fato de que os servidores proxy interrompiam as sessões NTLM, os usuários empregando autenticação de Kerberos precisavam de uma conexão para o Active Directory e, normalmente, os usuários da Internet não faziam parte do domínio. A atualização descrita no artigo da Base de Dados de Conhecimento supramencionado exclui essas limitações. Com a atualização instalada, você pode simplesmente ir para o diretório virtual e marcar a caixa Autenticação Integrada do Windows como o mecanismo para verificar as credenciais do usuário. Quando marcada, ela define um atributo chamado msexchAuthenticationFlags no objeto de diretório virtual do Active Directory (para ver isso, use o snap-in Adsiedit.msc para o Console de Gerenciamento Microsoft).
Os usuários que verificam email por meio do OWA podem conhecer o nome dos servidores back-end do Exchange e se conectarem a eles usando autenticação integrada quando usarem a intranet corporativa. A diferença na experiência do usuário com a autenticação integrada é que, como você está conectado à rede, não é solicitado a fornecer nome de usuário e senha porque o Internet Explorer fará a autenticação no site automaticamente. Isso é ótimo para os usuários que usam a rede corporativa, mas os usuários externos — e os usuários do OWA em geral são externos — não se conectarão a um domínio quando estiverem fora da rede e fizerem logon em um servidor front-end do Exchange. (Esse processo é explicado em detalhes no artigo da Base de Dados de Conhecimento "Como o IIS autentica clientes de navegador".)
No Exchange Server, a atualização preenche a guia Delegação para usar o atributo A2D2, em vez do atributo SPN (nome da entidade de serviço) no Active Directory. Se examinar o objeto do computador do Exchange usando Adsiedit.msc, você notará dois atributos distintos: o atributo A2D2, que é a lista de delegação restrita de Kerberos, e o atributo SPN, que atua como um localizador de Kerberos e ponto de especificação de conta. Embora seja verdade que os dois atributos trabalhem juntos para que ocorra a delegação restrita de Kerberos, você deve modificar apenas o atributo A2D2 na interface gráfica.
O Windows pode usar o HOST SPN incorporado como alias para localizar outros serviços. Isso significa que setspn.exe não precisa ser usado para que a delegação restrita de Kerberos funcione na delegação de front-end para back-end do Exchange. (Embora especificar explicitamente HTTP/Servername na lista de atributos SPN funcione com esta solução, isso abre espaço para mais erros do administrador e não é necessário para que a delegação restrita de Kerberos funcione.) A delegação restrita de Kerberos está procurando o atributo A2D2 no Active Directory. Quando esse atributo não é preenchido (ou possui o valor SPN errado), a delegação restrita de Kerberos não funciona entre os respectivos servidores. Em um cluster do Exchange, porém, o atributo A2D2 do servidor front-end precisa apenas ser apontado para a conta do computador do nó do cluster para funcionar de forma apropriada.
Conforme observado anteriormente, um domínio do Windows Server 2003 contendo os servidores do Exchange 2003 deve estar no modo funcional nativo do Windows Server 2003. A delegação restrita de Kerberos não pode ser usada, a menos que esse nível de funcionalidade de domínio seja alcançado. Se o seu domínio ainda estiver no modo misto e você instalar a atualização de software discutida anteriormente, a princípio, parecerá que ela funciona, mas, na verdade, os registros SPN falharão. A delegação restrita de Kerberos também é uma função de domínio, e não uma função no nível de floresta. Isso significa que, para o Exchange Server 2003, os servidores front-end e back-end do ISA Server e do Exchange devem ser membros do mesmo domínio (embora usuários de diferentes domínios ainda possam autenticar a delegação restrita de Kerberos). A instância do ISA Server que não for membro de um domínio ou que for membro de um domínio diferente não funcionará como parte desta solução.

Configurando o site do OWA
O IIS Admin não deve ser usado para qualquer tipo de alteração de autenticação no OWA. Muito embora o OWA seja executado sob o IIS e responda às alterações na metabase como qualquer outro site da Web, o Exchange apresenta certa complexidade com o processo DS2MB (serviços de diretório para metabase). O processo DS2MB replicará as alterações do Active Directory para a metabase do IIS em um processo unidirecional que substituirá quaisquer alterações feitas diretamente no IIS. O impacto desse processo é que, se um administrador fizer uma alteração diretamente na metabase do IIS (como configurar a autenticação integrada), a solução parecerá funcionar, mas falhará assim que o ciclo da próxima replicação DS3MB começar.
A opção de habilitar a Autenticação Integrada do Windows para Diretórios Virtuais HTTP foi disponibilizada no ESM porque ele faz as edições diretamente no Active Directory, que replica a alteração para a metabase do IIS. Tenha em mente que, embora a interrupção do serviço do Atendedor do Sistema também interrompa o processo DS2MB, permitindo que as alterações sejam feitas na metabase do IIS e não sejam substituídas, isso não é aconselhável. Na próxima vez que for iniciado, o Atendedor do Sistema pesquisará as alterações no Active Directory e a solução será desabilitada automaticamente.
A guia Delegação mostra as opções Usar apenas Kerberos e Usar qualquer protocolo de autenticação. Pela lógica, você selecionaria Usar apenas Kerberos, já que a solução que estamos discutindo trata do uso da delegação restrita de Kerberos, mas essa é uma das muitas situações de TI em que a lógica comum não se aplica. Portanto, em vez disso, você deve selecionar Usar qualquer protocolo de autenticação (como mostra a Figura 7), pois a solicitação não chega como Kerberos, mas como HTTP com um certificado correspondente mapeado para uma conta do Active Directory.
Figura 7 Configurações corretas de autenticação para cartões inteligentes
Figura 7 Configurações corretas de autenticação para cartões inteligentes
Nesse caso, o ISA Server está solicitando o certificado PKI do usuário sobre SSL. A solicitação de entrada não é um tíquete Kerberos, por isso, é necessário que aconteça uma transição para que a delegação restrita de Kerberos funcione de forma apropriada. Assim, se a configuração Usar apenas Kerberos for especificada, a cadeia de comunicação no ISA Server será interrompida. Observe, porém, que a opção Usar apenas Kerberos funcionará na delegação de servidor Exchange front-end para back-end, já que o servidor front-end apenas receberá tíquetes Kerberos do ISA Server.
Os diretórios virtuais \Exchange e \Public são os únicos locais que devem conter informações particulares do usuário e da pasta pública. A configuração SSL no Exchange não é nova para a delegação restrita de Kerberos ou para a autenticação de dois fatores, mas uma conseqüência da habilitação SSL padrão do OWA com credenciais de autenticação básica. Você deve seguir os métodos documentados para habilitar SSL no OWA porque, se incorretamente forçar SSL, poderá interromper o OWA e causar problemas com o ESM também.

Detalhes de configuração adicionais
Ao implementar esta solução, será muito mais fácil implantar o ISA Server e o Exchange da forma padrão primeiro. Não coloque a solução inteira de delegação restrita de Kerberos com todas as configurações definidas (especialmente se, antes, o ISA Server não fazia parte da sua implantação). Isso poderá complicar o processo de solução de problemas se um componente ou uma etapa falhar. É muito mais fácil implantar o ISA Server e o Exchange da forma padrão (com nome de usuário e senha, mas sem autenticação baseada em formulários), garantir que a instalação funcione e, depois, fazer a transição para a delegação restrita de Kerberos e a autenticação de certificação.
Normalmente, a autenticação baseada em formulários não pode ser usada com OWA habilitado para cartão inteligente. A autenticação baseada em formulários indica que um usuário possui um nome de usuário e uma senha para enviar por meio do formulário padrão do Outlook. Entretanto, com a autenticação de dois fatores baseada em cartão inteligente, o usuário terá somente um cartão inteligente e não uma senha. Assim, a autenticação baseada em formulários não poderá, de forma alguma, aceitar ou enviar apenas o certificado para autenticação. O uso da autenticação baseada em formulários em qualquer ponto da cadeia (por exemplo, no servidor front-end protegido pelo ISA Server) invalidará a configuração do OWA habilitado para cartão inteligente. Se você habilitar a autenticação baseada em formulários, o diretório virtual do Exchange obrigatoriamente será definido como Autenticação básica e o mesmo acontecerá com a metabase do IIS.
Se você tiver uma mistura de usuários que possuem nome de usuário/senha e cartão inteligente, poderá habilitar a autenticação de retorno no ouvinte da Web ISA, de maneira que, quando um usuário pressionar a tecla ESC ao ser solicitado a inserir as credenciais baseadas em certificado, terá de inserir as credenciais padrão de nome de usuário/senha mesmo que a Autenticação integrada esteja habilitada no ISA Server do servidor Exchange. Além disso, o ISA Server pode esgotar o tempo limite da sessão SSL da mesma forma que as funções de autenticação baseadas em formulários.

Conclusão
O suporte a cartão inteligente para autenticação no OWA é um acréscimo bem-vindo tanto para o Exchange Server 2003 quanto para o Exchange Server 2007. Com a capacidade de fazer logon no OWA usando um certificado, os usuários não precisam mais se esforçar para se lembrar de senhas longas e complexas, e os administradores agora possuem uma ferramenta eficaz contra keyloggers e outras formas de malware que podem detectar as credenciais do usuário em um sistema infectado. Para obter mais informações, consulte a barra lateral "Recursos".
A configuração correta do ISA Server para autenticação de dois fatores com cartões inteligentes aumenta ainda mais a segurança geral, executando a filtragem no nível de aplicativo do OWA publicado. Além disso, o ISA Server 2006 possui suporte interno para publicar tanto o Exchange Server 2003 como o Exchange Server 2007 por meio de simples assistentes de publicação; por isso, o ISA Server ainda representa um ótimo investimento para as organizações na transição para o Exchange Server 2007.
Recursos
  • Como compartilhar arquivos removidos pelo recurso de filtragem "segura HTML" no Outlook Web Access para Exchange Server 2003
  • Solução de problemas da delegação de Kerberos
  • Serviço de atualização de metabase
  • Autenticação no ISA Server 2006
  • Transição de protocolos e delegação restrita de Kerberos
  • TechNet Webcast: implementando a autenticação de multifatores com o uso de cartões inteligentes

Victor Akinnagbe é engenheiro-chefe de campo da Microsoft e atua na região de Washington, D.C. Suas principais áreas de foco são segurança, infra-estrutura e sistema de mensagens.
Ted Dressel é consultor da Microsoft e atua na região de Washington, D.C. Suas principais áreas de foco são segurança e infra-estrutura.
Jason Opdycke é engenheiro-chefe de campo da Microsoft e atua na região de Charlotte. Suas principais áreas de foco são segurança e infra-estrutura.


 Administra&#231;&#227;o do Windows: O ActiveX Installer Service no Windows Vista
Administração do Windows Rob Campbell and Joel Yoker

O ActiveX Installer Service no Windows Vista
Visão geral:
  • Desafios comuns com controles ActiveX
  • Como os controles ActiveX são instalados
  • Permissões perigosas
  • Um processo mais seguro no Windows Vista

É sempre a mesma história. Para melhorar substancialmente sua segurança, você precisa abdicar de alguma liberdade ou flexibilidade. Se o seu ambiente é como a maioria das organizações, você tem um desejo muito forte de proteger o sistema operacional para oferecer um ambiente de computação com mais segurança
para seus usuários finais. Os administradores de TI normalmente resolvem a tarefa de proteger o desktop empregando uma combinação de configurações de diretiva de segurança, permissões de usuário, ACLs (listas de controle de acesso) a registro e arquivos, além de restrições a serviços do sistema.
Um obstáculo comum no desenvolvimento de um ambiente de desktop seguro é descobrir como atenuar as ameaças que envolvem controles ActiveX® maliciosos e, ao mesmo tempo, oferecer um nível apropriado de compatibilidade de aplicativos no seu ambiente. Isso tem sido um desafio com sistemas operacionais de desktop há muitos anos. Felizmente, o novo ActiveX Installer Service (AxIS) no Windows Vista™ resolve os problemas específicos de gerenciamento de controles ActiveX em ambientes corporativos. O AxIS oferece uma forma simples e gerencíável aos usuários padrão (que normalmente não teriam permissão para instalar controles ActiveX) de instalar controles a partir de sites aprovados. O controle de Diretiva de Grupo no AxIS possibilita que os administradores de TI determinem quais controles os usuários podem instalar, independentemente de quais permissões tenham.
Neste artigo, analisamos os desafios administrativos que cercam os controles ActiveX, como essas questões foram resolvidas nas versões anteriores do Windows®, e como o AxIS no Windows Vista oferece um modo único e eficiente de gerenciar a instalação de controles ActiveX.

O que é um controle ActiveX?
Um controle ActiveX é um trecho de código executável (em geral um arquivo OCX empacotado dentro de um arquivo de gabinete) que é instalado e invocado pelo usuário via Internet Explorer®. Os desenvolvedores da Web criam controles ActiveX para adicionar funcionalidade a suas aplicações na Web, que não poderiam ser obtidas facilmente com HTML padrão ou um simples script.
Uma característica importante dos controles ActiveX é seu modelo simples de implantação, do tipo "baixe e execute". Os controles ActiveX são instalados e invocados através da marca de objeto HTML, que tem um atributo chamado CODEBASE que informa ao Internet Explorer (usando uma URL) onde obter o controle, caso já não esteja instalado na máquina do usuário. Neste caso, o Internet Explorer baixa o pacote de instalação associado, realiza uma verificação de confiabilidade no objeto e solicita ao usuário a permissão de instalação por meio da barra de informações do Internet Explorer (mostrada na Figura 1). Durante a instalação, o controle é registrado e invocado pela página de processamento. Após a instalação, qualquer usuário padrão pode invocar o controle. Esse mecanismo simples de distribuição e execução foi feito para propiciar aos desenvolvedores uma forma fácil de distribuir seus componentes aos usuários de seu aplicativo Web. O problema com esse método de distribuição é que os usuários padrão não podem instalar diretamente os controles ActiveX porque são necessários privilégios administrativos para realizar a instalação.
Figura 1 Barra de informações de instalação do controle ActiveX
Figura 1 Barra de informações de instalação do controle ActiveX
Quando os controles ActiveX foram introduzidos no Internet Explorer 4.0, a Internet parecia ser um lugar muito mais amigável. Hoje, o código executável distribuído na Web pode representar uma ameaça significativa, então o Windows permite que somente os usuários com direitos de administrador local instalem controles ActiveX, que posteriormente somente serão instalados se houver aprovação de acordo com as configurações de diretiva. Depois que um controle ActiveX é instalado por um administrador, qualquer usuário do sistema pode invocá-lo. Esse comportamento é facilitado por um conjunto de ACLs de arquivo e registro no Windows. Apesar de isso impedir que os usuários padrão instalem controles ActiveX, os riscos para os administradores locais e usuários padrão (com permissões padrão modificadas) que os instalam não ficam reduzidos.
Ainda que a proteção padrão no Windows — permitindo que somente aqueles com privilégios administrativos realizem a instalação — atenda aos controles ActiveX no nível individual, não atende à forma de gerenciá-los em uma grande organização. Um desafio comum em ambientes corporativos é a forma de permitir o uso de controles ActiveX em que a organização de TI confia e, ao mesmo tempo, atenuar as ameaças potenciais trazidas por controles externos e não-confiáveis. No final das contas, a decisão de instalar um controle ActiveX em particular, bom ou ruim, é normalmente deixada para o usuário individual, dependendo de seus direitos. Para neutralizar as ameaças, algumas organizações bloqueiam todos os controles ActiveX, enquanto outras permitem a instalação pelo usuário final, mas tentam gerenciar todos os malware que forem instalados.
Uma outra forma de impedir a instalação de controles maliciosos é reforçar os direitos restritos do usuário padrão e fazer com que o administrador de TI pré-instale todos os controles exigidos na plataforma do desktop. Isso seria eficiente se os controles ActiveX em uso tivessem uma natureza relativamente estática, fossem modificados usando um processo de lançamento programado em conjunto com atualizações de desktop, ou se a organização usasse um mecanismo de distribuição de software, como o Systems Management Server. No entanto, o gerenciamento contínuo, as necessidades em constante mudança de desenvolvedores de aplicativos internos e as dependências de controles externos continuarão a ser um desafio nessas abordagens.
Em instâncias em que os usuários tenham privilégios administrativos, o problema é diferente, pois está relacionado a impedir que esses usuários instalem controles que não sejam aprovados. Nesses casos, o direito do usuário final de instalar controles ActiveX é assumido, já que o usuário tem privilégios administrativos. (Note que fazer com que os usuários finais executem como administradores local é uma condição que representa um alto risco para a organização e não é recomendada para a maioria dos ambientes corporativos.)
Uma solução é ter um servidor de download de componentes da Internet interno que armazene os controles aprovados. Essa solução requer a modificação da cadeia de caracteres CodeBaseSearchPath no registro do cliente. Em geral, quando uma marca de objeto contendo o atributo CODEBASE é encontrado na página HTML solicitada, os clientes Windows são direcionados para os locais especificados nos dados de CodeBaseSearchPath. Por padrão, essa cadeia de caracteres do registro contém a palavra-chave CODEBASE e URLs de Internet para a galeria de controles ActiveX. Para implementar um servidor de download de componentes da Internet, é preciso substituir os dados padrão em CodeBaseSearchPath pela URL do servidor interno onde você hospedará controles aprovados por sua organização. Assim como a abordagem anterior, essa solução requer um gerenciamento contínuo e traz o custo e a complexidade de hospedar um servidor interno de controles ActiveX.
Há outras soluções, tais como modificar a zona do Internet Explorer URLActions, especificando controles aprovados pelo administrador por meio de Diretiva de Grupo, e bloqueando a instalação de todos os controles no perímetro por meio de regras de firewall. Contudo, como você pode ver, todas essas abordagens têm seus problemas, e muitas são abandonadas devido à falta de flexibilidade. E o que é pior, algumas dessas soluções ainda exigem que o usuário tenha direitos administrativos. No final das contas, essas modificações tentam resolver partes do problema, tais como controlar (ou bloquear) de onde vêm os controles ActiveX, de onde podem ser invocados e assim por diante. No entanto, essas soluções não resolvem o problema fundamental de os usuários sem direitos administrativos não poderem instalar controles ActiveX.

O que o AxIS pode fazer por você?
O AxIS no Windows Vista possibilita que o administrador corporativo gerencie controles ActiveX e, ao mesmo tempo, mantenha uma condição de segurança forte, fazendo com que os usuários executem como usuários padrão, com configurações de sistema de arquivos padrão. O AxIS oferece opções de Diretiva de Grupo para configurar origens confiáveis de controles ActiveX e um processo de "agente" para instalar controles dessas origens confiáveis em nome de usuários padrão. A principal vantagem é que você pode manter uma postura de segurança não-administrativa em estações de trabalho de usuários, em conjunto com um controle administrativo centralizado. O AxIS depende do administrador de TI para identificar as origens confiáveis (normalmente URLs da Internet ou da intranet) de controles ActiveX. Quando uma marca de objeto direciona o Internet Explorer para invocar um controle, o AxIS realiza as seguintes etapas:
  1. Verifica se o controle está instalado. Se não estiver, deve ser instalado antes do uso.
  2. Verifica a configuração da diretiva AxIS para ver se o controle é de uma origem confiável. A verificação específica relaciona o nome do host da URL especificada no atributo CODEBASE da marca de objeto à lista de locais confiáveis especificada na diretiva.
  3. Baixa e instala o controle em nome do usuário.
Se o nome do host da URL de origem não estiver listado na configuração de diretiva AxIS, a solicitação normal de UAC (controle de conta de usuário) será invocada, exigindo direitos administrativos para concluir a instalação. Além disso, o AxIS irá registrar um evento com ID 4097 no log de eventos de aplicativo da origem AxInstallService, descrevendo a tentativa de instalação de controle ActiveX, juntamente com o caminho específico de download para o controle. Um exemplo do evento 4097 é ilustrado na Figura 2. Os dados dessa entrada de log de evento podem ser usados pelo administrador corporativo para modificar a Diretiva de Grupo, permitindo que o controle seja instalado pelo AxIS em visitas subseqüentes ao site.
Figura 2 Evento 4097 de AxInstallService
Figura 2 Evento 4097 de AxInstallService
AxIS é um componente opcional que vem com os SKUs de Business, Enterprise e Ultimate do Windows Vista, e pode ser habilitado por meio de uma opção autônoma ou pela caixa de diálogo do Painel de Controle (Programas | Programas e Recursos | Ativar e desativar recursos do Windows), conforme é mostrado na Figura 3. Depois de habilitado, o AxIS realiza as etapas descritas acima toda vez que um controle é solicitado pelo Internet Explorer.
Figura 3 Habilitando o AxIS no Painel de Controle
Figura 3 Habilitando o AxIS no Painel de Controle
A capacidade de anexar tarefas a eventos no Windows Vista representa uma maneira fácil de um administrador receber uma notificação do serviço AxIS, por exemplo, quando a instalação de um controle ActiveX é bloqueada. É importante notar que não se pode sempre assumir que o controle ActiveX será instalado a partir do mesmo nome de host de URL que o usuário final está acessando de seu site. Por esse motivo, as informações fornecidas pelo evento 4097 do AxInstallService (tentativa de instalação) podem se tornar extremamente úteis na identificação do host a partir do qual o controle tenta ser instalado.
Com as informações que você obtém do evento, pode configurar o local confiável na Diretiva de Grupo. As definições de AxIS na Diretiva de Grupo ou Local encontram-se nas definições de Configuração do Computador (como se observa na Figura 4). A definição da diretiva de sites de instalação aprovados para controles ActiveX possibilita que você especifique URLs de host de locais confiáveis (consulte a Figura 5). A definição de site aprovado requer dois tipos de informação: de onde o controle ActiveX pode ser instalado e o comportamento da instalação.
Figura 4 Definições no Editor de Objeto de Diretiva de Grupo
Figura 4 Definições no Editor de Objeto de Diretiva de Grupo
Figura 5 Sites de instalação aprovados pelo AxIS
Figura 5 Sites de instalação aprovados pelo AxIS
Primeiro, como já mencionado antes, é necessário uma URL de host para indicar o local confiável do controle. Ao contrário das soluções anteriores, que requerem o conhecimento do CLSID do controle (que normalmente muda quando os controles são revisados por seus desenvolvedores), o AxIS permite que qualquer controle seja instalado a partir do local confiável, reduzindo a carga administrativa geral. O segundo tipo de informação é uma cadeia de caracteres de quatro valores delimitada por vírgula, cada um dos valores ditando o comportamento da experiência de download do controle ActiveX. Os valores especificam quatro propriedades: TPSSignedControl, SignedControl, UnsignedControl e ServerCertificatePolicy. As duas primeiras propriedades (TPSSignedControl e SignedControl) podem ter um dos três valores: 0, 1 ou 2. Esses valores são similares aos valores encontrados nas definições URLAction. Um valor 0 impede que o controle seja instalado, um valor 1 faz com que o usuário receba uma solicitação de permissão para instalar, e um valor 2 faz com que o controle seja instalado silenciosamente em nome do usuário. Controles sem assinatura não podem ser instalados silenciosamente e, portanto, o valor de UnsignedControl só pode ser 0 ou 1. Note que, se não for especificada nenhuma diretiva, os valores padrão de 2, 1 e 0 serão usados.
A propriedade final especifica o comportamento da instalação com base nas configurações de certificado do controle de configurações assinado. Assim como a maioria dos sites SSL, os certificados devem passar por uma série de testes de segurança para garantir que o certificado seja válido. Propriedades de certificado inválidas às vezes são a realidade de uma implementação de controles ActiveX assinados do mundo real. Com sua configuração, o AxIS permite que os administradores reduzam as informações inválidas que às vezes são apresentadas por certificados, URL-a-URL. A propriedade final é representada como uma combinação de bitmask dos valores mostrados na Figura 6.
Figure 6 ServerCertificatePolicy (Close Figure 6)

Valor | Definição
0x00001000 | Ignorar um CN (nome canônico) inválido no certificado.
0x00000100 | Ignorar autoridades de certificação desconhecidas.
0x00002000 | Ignorar uma data de certificado inválida.
0x00000200 | Ignorar o uso de certificado errado.
A configuração padrão é 0, significando que deve passar por todas as verificações de segurança para que o AxIS complete a instalação. A combinação da configuração de host e esses quatro valores é especificada na definição de diretiva, conforme visto na Figura 7.
Figura 7 URLs de host AxIS aprovados
Figura 7 URLs de host AxIS aprovados

Conclusão
O AxIS possibilita que você configure a Diretiva de Grupo para controlar quais controles ActiveX os usuários podem instalar sem precisar de privilégios administrativos ou configurações complexas. O controle nesse nível poderia ser desafiador em versões anteriores do Windows, e as soluções disponíveis anteriormente costumavam apresentar limitações graves ou uma grande sobrecarga de gerenciamento. O AxIS oferece às organizações outra ferramenta voltada para uma abordagem de privilégios mínimos para direitos de usuários finais em sistemas de desktop, possibilitando a implementação de um modelo de usuário padrão em que os usuários finais não precisam ter privilégios administrativos. O Windows Vista coloca o administrador de TI de volta no banco de motorista ao ter o poder de escolher quais controles ActiveX são confiáveis dentro do ambiente corporativo, determinados pela organização, não pelo usuário final.

Rob Campbell é um especialista técnico sênior da equipe Microsoft Federal. Rob está concentrado no desenvolvimento e na implantação de soluções de segurança para clientes do governo federal dos Estados Unidos.
Joel Yoker é um consultor sênior da equipe Microsoft Federal. Joel está concentrado no desenvolvimento e na implantação de soluções de segurança para clientes do governo federal dos Estados Unidos.


 Do editor: Seis graus
Do editor
Seis graus
Joshua Trupin

Você já se sentiu um pouco desconectado? Já se sentou em sua mesa olhando para o infinito e pensando se há vida inteligente lá fora? Ou, ainda, se há realmente alguém lá fora? Talvez não — especialmente se a sua caixa de entrada está sempre tão lotada quanto a minha.
No entanto, recentemente passei por essa situação e decidi que precisava me conectar. Associei-me a um desses sites de rede de relacionamentos de negócios e comecei a adicionar pessoas — todos com quem eu trabalho e algumas pessoas de quem adquiri artigos ou com quem conversei em alguma conferência. Em uma semana, eu já tinha 58 contatos na minha lista. Ótimo!
Mas esse era somente o primeiro nível. No segundo nível — conhecidos de conhecidos — eu já tinha mais de 3.500 amigos. E, uma vez que esses 3.500 contatos tinham seus próprios contatos, passei a ter 277.000 contatos de terceiro grau em pouquíssimo tempo. Um cálculo rápido feito em uma planilha do Excel: suponha uma média de 50 contatos por pessoa — e passo a conhecer mais de 34 bilhões de pessoas como contatos de sexto grau. Te cuida, Kevin Bacon! Conheço mais gente do que toda a população do planeta Terra. Subitamente, havia uma luz no fim do túnel.
Entretanto, agora eu tinha um novo problema. Como é que eu poderia lidar com todos esses relacionamentos? Estou aberto a sugestões. Você faz parte de um site de relacionamentos de negócios/sociais? Como você separa as pessoas com quem deseja conversar daquelas que deseja evitar? Visite o blog da TechNet Magazine e diga para nós a sua opinião sobre esse assunto.
Se todo esse papo sobre rede de relacionamentos da Web 2.0 não for para você, não tema. A edição deste mês da TechNet Magazine o ajudará a aprimorar as suas comunicações ao mostrar como utilizar melhor o Exchange Server. Temos cinco artigos que oferecerão o conhecimento necessário para que você estenda o alcance das mensagens da sua organização.
O uso de autenticação de cartões inteligentes com o Outlook Web Access é um dos nossos destaques do mês. Sempre é uma boa idéia adquirir uma forma de autenticação física antes de conceder acesso aos recursos da sua empresa, e os cartões inteligentes tornam isso possível a partir de qualquer lugar. Veremos também a recuperação de desastres com o Exchange Server, como substituir pastas públicas com o SharePoint no Exchange Server 2007 e como aprimorar a segurança móvel com o Windows Mobile 6. E, é claro, temos a coluna Perguntas e respostas do Exchange, que deve ser a sua favorita, caso você não esteja familiarizado com o sistema de mensagens. Epa, mais três pessoas acabaram de entrar na minha rede. É melhor eu ir e ver se devo cumprimentar ou fingir que estou dormindo.
– Joshua Trupin

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Kristian Andaker, Chris Corio, Jim Harrison, Chad Jones, Michael Lee, Shawn McGrath, Michael Murgolo, Eric Perlin, Michelle Rutzer, Gavriella Schuster e Jim Truher.


 Toolbox: Novos produtos para profissionais de TI
Toolbox
Novos produtos para profissionais de TI
Greg Steen

Monitoramento de conexões remotas
RecordTS
www.tsfactory.com
Você já desejou poder observar as sessões do Terminal Server ou da Área de Trabalho Remota? Talvez você deseje saber o que aconteceu antes de a sessão da Área de Trabalho Remota desativar o seu site da Web. Talvez você tenha um problema no Terminal Server que simplesmente não consegue replicar. Talvez você esteja preocupado com segurança de propriedade intelectual. Ou talvez precise fazer um rápido registro ou apresentação de como configurou o servidor SharePoint® em um ambiente de teste. Se qualquer um desses cenários lhe parecer familiar, você deve experimentar o RecordTS do TSFactory. (O TSFactory foi organizado por Cláudio Rodrigues, MVP da Microsoft para Serviços de Terminal.)
O RecordTS está disponível em duas edições: Terminal Server e Área de Trabalho Remota. A edição correta no seu caso depende dos tipos de conexões que você deseja monitorar. Como atesta o site do produto, o RecordTS atua como uma "câmera de segurança" nas sessões do Terminal Server ou da Área de Trabalho Remota. Basicamente, o software funciona como um proxy entre os Serviços de Terminal e a sessão do usuário final, permitindo que ele grave cada momento e ação tomada em uma sessão.
A instalação intuitiva usa um assistente simples no qual você aponta o aplicativo para o diretório de dados em que gostaria de armazenar as sessões salvas. O aplicativo instala um snap-in MMC (que permite configurar o serviço), o serviço RecordTS e um utilitário de reprodução de sessão para observar as sessões gravadas. Depois de abrir o snap-in MMC, clique com o botão direito do mouse na pasta de serviço para abrir uma tela de propriedades em que você poderá definir configurações, como a porta na qual o serviço será executado. (Essa configuração é especialmente útil se você tiver deslocado as sessões dos Serviços de Terminal para uma portão não-padrão.) Na guia Storage (Armazenamento), é possível definir Default Storage Folder (Pasta de armazenamento padrão) como uma pasta local ou um caminho UNC.
Você também pode configurar a estrutura de diretórios das sessões armazenadas. Por exemplo, usar domínio, usuário e data e hora para organizar os dados salvos. E, talvez, a configuração mais importante, se você estiver armazenando sessões em um disco local, seja poder dizer ao serviço o que fazer se o disco ficar sem espaço. Você pode escolher entre não permitir novas conexões e desconectar as sessões atuais (uma opção para quem é extremamente preocupado com segurança) ou pode decidir desativar a gravação da sessão (a escolha certa se você não quiser interromper a produtividade).
Na guia Security (Segurança), é possível especificar se você deseja assinar digitalmente todas as sessões gravadas, selecionando um certificado existente ou criando um certificado auto-assinado. Isso é válido se você planeja usar a ferramenta para fins de auditoria ou responsabilidade. Na guia Users (Usuários), é possível especificar de quais usuários as sessões devem ou não ser gravadas.
No fim, RecordTS pode ser uma excelente ferramenta para segurança e auditoria, e suas aplicações podem ser muito mais amplas, como permitir que você grave uma apresentação de instrução. Sem dúvida, é mais um item útil para a minha caixa de ferramentas.

Preço: o RecordTS Remote Desktop Edition custa a partir de US$ 495. O RecordTS Terminal Services Edition custa a partir de US$ 995.

Monitoramento de host
Advanced Host Monitor
www.ks-soft.net
Se, um dia, você tiver de oferecer suporte operacional para uma infra-estrutura de missão crítica, existe um recurso que não pode deixar faltar: um bom e confiável monitor de host. Mesmo que você tenha um ótimo conjunto de hardware e uma pilha de aplicativos estável e confiável sem nenhum ponto de falha, irá desejar um monitor de host completo para dizer quando esse sistema redundante precisa participar.
O Advanced Host Monitor, da KS-Soft, diz ter 58 métodos de teste diferentes e 30 métodos de alerta. Você pode verificar itens como informações de processo, sessões de usuário, carga média e memória, entre outros. O aplicativo fornece testes específicos do Windows®, testes de Linux/UNIX e verificações independentes da plataforma. Diferentemente dos testes do Windows, os testes de Linux/UNIX exigem a instalação de um Agente de Monitoramento Remoto no cliente.
Também existe um teste de monitoramento WMI (Instrumentação de Gerenciamento do Windows). Você pode procurar a consulta correta com o WMI Explorer incorporado, que permite navegar facilmente e escolher o item apropriado, assim como executar a consulta para verificar se obterá os dados de que você precisa.
O Advanced Host Monitor também possui vários testes relacionados a banco de dados, como o teste de consulta ODBC, que verifica a disponibilidade de uma fonte de dados ODBC, executa uma consulta e verifica o resultado em relação a um valor conhecido. Você também pode verificar a capacidade de um host aceitar sessões de entrada para servidores de banco de dados SQL Server™, MySQL, Oracle, Postgres, Sybase e Interbase.
Há diversos testes relacionados a disco e arquivos para ajudá-lo a controlar o espaço livre, cotas, a disponibilidade de pastas ou arquivos e a disponibilidade de compartilhamentos UNC. Além disso, existem os testes padrão relacionados a rede: verificações gerais TCP/UDP, testes de email (para SMTP, POP3 e IMAP), verificações de retransmissão de email, testes de tempo e conteúdo HTTP, entre outros. Também é possível criar interdependências de teste de monitoramento para fazer as verificações em cascata, uma opção útil. Os testes também podem ser programados nos chamados intervalos regulares ou irregulares, permitindo que você seja bem detalhista em relação aos padrões de teste.
Alguns métodos de alerta incluem o envio de mensagens para SMS, ICQ, email, um log de eventos ou uma janela pop-up. Eles também podem disparar outros eventos, como iniciar ou interromper serviços, reiniciar o computador ou executar um programa externo.
Com as edições Professional e Enterprise do Advanced Host Monitor, você pode obter as ferramentas de IP da KS-Soft: um conjunto de 19 utilitários de rede relacionados a TCP/IP que incluem scanners de porta/protocolo e um observador de interceptação SNMP, que permite receber e processar mensagens de interceptação SNMP. Além disso, as duas versões possuem um componente de relatório e analisador de log que permite dirigir os dados de monitoramento histórico para os relatórios de tempo de atividade e as revisões de análise de desempenho.
A própria interface fornece uma ótima maneira de obter uma rápida visão geral de vários testes simultaneamente. Com ela, você pode examinar com facilidade os problemas nos hosts monitorados.
Preço: US$ 599 para Enterprise Edition. US$ 275 para Professional Edition.

Limpeza do disco:
WinDirStat
www.windirstat.info
Assim como a sua casa ou o seu apartamento, com o tempo, os locais de armazenamento costumam ficar abarrotados de material que foi útil um dia, mas agora apenas ocupa um espaço precioso. Uma pequena limpeza pode fazer um grande bem, mas, diferentemente da sua casa, uma estrutura de árvore de diretório não fornece pistas visuais óbvias, como por onde começar a arrumar a bagunça. Felizmente, existe uma ótima ferramenta de visualização que pode ajudá-lo a ver quais arquivos estão ocupando espaço no seu ambiente.
O programa GPL WinDirStat, uma ferramenta baseada no Windows e inspirada pelo kdirstat do KDE do Linux, mostra os arquivos na unidade selecionada como um conjunto de quadrados de cores diferentes. O tamanho dos quadrados representa o tamanho dos arquivos, permitindo determinar facilmente os arquivos ISO ou ZIP imensos, antigos e desnecessários.
Depois que você selecionar a unidade local (ou um conjunto de unidades locais), o programa examina a árvore de diretórios, criando um mapa dos arquivos na memória. A visualização é exibida no painel inferior da GUI. Clique em um quadrado colorido no painel inferior para navegar pelo painel superior, semelhante ao Windows Explorer, até o local do arquivo. O painel superior fornece estatísticas úteis como o tamanho do arquivo, a data de sua última alteração e outros atributos. Além disso, é exibida a porcentagem da subárvore que o arquivo ocupa.
Um ótimo detalhe é que as cores são específicas para cada arquivo e, se você clicar em um tipo de arquivo detectado na parte superior direita, todos os arquivos daquele tipo serão realçados no painel inferior. Isso poderá ser útil, por exemplo, quando você precisar identificar todos os arquivos MP3 ocultos que os usuários possuem no servidor de arquivos. Também é possível ver o percentual de bytes que esses arquivos ocupam na partição.
Preço: download gratuito.

Resenha de livro
Enemy at the Water Cooler
syngress.oreilly.com
Quase toda empresa precisa estar conectada à Internet, e a maioria conhece os perigos apresentados pelas constantes tentativas externas de comprometer os pontos de conexão que separam a parte "externa" da parte "interna" de sua infra-estrutura de informações. Entretanto, boa parte delas ignora uma ameaça potencialmente mais nociva que existe dentro da organização. O poder das ameaças internas é muito bem ilustrado no livro Enemy at the Water Cooler: Real-Life Stories of Insider Threats and Enterprise Security Management Countermeasures (Inimigo à vista: histórias reais de ameaças internas e medidas defensivas de gerenciamento de segurança empresarial; Syngress, 2006) de Brian Contos.
O autor oferece histórias reais de ataques que ocorreram e o impacto que tiveram nas empresas envolvidas. Ele alega que a segurança é um processo constante que consiste em uma "mistura de pessoas, processos e tecnologia". No livro, ele tenta ilustrar a capacidade potencial das soluções de software ESM (gerenciamento de segurança empresarial) para minimizar as ameaças internas.
Como CSO da ArcSight, Contos baseia-se na apresentação da solução de software ESM da própria empresa, o que não afeta o valor do livro como um todo. O livro não fornece muitos detalhes técnicos, mas dá uma boa idéia de como é possível aprimorar seu próprio processo de segurança na sua empresa, mostrando onde as outras organizações falharam e o que uma solução ESM implementada com eficiência pode fazer para reduzir a exposição a um ataque externo.
No capítulo sobre experiências, "Cyber Crime and Cyber Criminals 101" (Princípios dos crimes e criminosos cibernéticos), Contos oferece uma visão geral dos diferentes tipos de invasores, aos quais se deve estar atento, e suas motivações. Ele também faz uma breve sinopse de algumas técnicas, como estouro de buffer, atribuição de códigos e ameaças "warhol".
O capítulo seguinte investiga melhor as características das ameaças internas, incluindo as formas pelas quais um funcionário pode prejudicar uma empresa, o conceito de gerenciamento de risco e maneiras de tratar as ameaças da perspectiva técnica. A perspectiva técnica fornece uma breve visão geral de privilégio mínimo, autenticação forte, controle de acesso e detecção e gerenciamento de incidentes. Ele abre caminho para uma discussão sobre soluções de software ESM. Realmente, o livro trata apenas do produto da ArcSight, mas a análise dos recursos-chave é aplicável a qualquer sistema.
O livro oferece vários cenários de casos de um grupo representativo de setores e ambientes, detalhando os diferentes tipos de ameaças internas e como elas foram detectadas (e, às vezes, minimizadas). Esses estudos de caso podem lançar uma luz sobre algumas das suas práticas comerciais e, talvez, oferecer soluções para reduzir o risco de uma invasão interna em seu ambiente.
Preço: US$ 49,95.

Escreva para a Toolbox
Se você tiver uma ferramenta ou um utilitário favorito que queira apresentar aqui, escreva para o autor em tntools@microsoft.com.

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


 P&amp;R do SQL: Clusters internos, paradas misteriosas, a conta SA e muito mais
P&R do SQL
Clusters internos, paradas misteriosas, a conta SA e muito mais
Editado por Nancy Michell

P Preciso entender melhor como funcionam os clusters. Nosso ambiente consiste no Windows Server® 2003 de 64 bits executando SQL Server™ 2005, um Web farm SSRS (SQL Server Reporting Services) — implantação de escalonamento horizontal de servidores de relatórios —, um servidor de catálogo TempDB SSRS e um SQL Server que bombeia dados de um banco de dados de terceiros por meio de um servidor vinculado e armazena os dados para SSRS.
Queremos um cluster de 3 nós ativo/ativo/passivo. Node1 seria ativo e armazenaria os dados bombeados do banco de dados de terceiros. Node2 seria ativo e armazenaria o catálogo SSRS. Node3 seria passivo e funcionaria como um failover para Node1 ou Node2. Você pode nos ajudar?

R Infelizmente, muitas pessoas se enganam com os termos ativo/ativo e ativo/passivo em relação aos clusters do SQL Server. Elas pensam que os clusters SQL oferecem suporte ao escalonamento horizontal ("scale-out") de uma instância SQL ou banco de dados em vários servidores. Não é o caso. No SQL Server, não existe uma instância ou um banco de dados ativo/passivo. Uma "instância" é uma instalação de SQL Server com bancos de dados correspondentes. Nossa instância de cluster por SQL Server é ativa (1) para passiva (n) sempre (observe que o valor de n varia de 1 a 7, conforme a versão do SQL Server). É por isso que eles são chamados de clusters de failover.
Depois de entender isso, as pessoas podem começar a considerar a instalação de várias instâncias de clusters de failover em um conjunto de nós. Por exemplo, três servidores físicos usando discos compartilhados poderiam ter uma instância ativa por padrão no Node 1 e uma segunda instância ativa por padrão no Node 2, e as duas poderiam falhar no Node 3. As instâncias são totalmente separadas; elas não compartilham dados e não são ativas/ativas. Elas são ativas/passivas e compartilham a mesma instância failover. Se as duas instâncias falharem no Node 3, então o desafio com o tempo será saber se ele suportará a carga. Por design, o failover é criado para usar o mesmo poder de processamento para o failover. Se o pico de carga exigir dois nós para processamento sob condições de operação normais, dificilmente o Node 3 sobreviveria sob o pico de carga atribuído aos dois nós.
Dito isso, devido ao custo relativo de hardware capaz de executar um cluster, é compreensível que as pessoas considerem a possibilidade de os dois nós principais falharem simultaneamente e forçarem a carga inteira em um nó. Levando isso em conta, elas podem tomar a decisão mais econômica de assumir o risco, em vez de investir em uma capacidade de failover de 100%.
Felizmente, tenho uma boa notícia: o SQL Server 2005 oferece muito mais opções para alta disponibilidade, incluindo alternativas que possam falhar mais rapidamente do que um cluster e possam até mesmo significar cópias duplicadas de dados (os clusters contam com uma única SAN). As opções incluem espelhamento, replicação ponto a ponto e outras. Com essas novas alternativas, temos muito mais opções para satisfazer qualquer tipo de necessidade, incluindo algumas que combinem recursos de alta disponibilidade.
O Microsoft® Cluster Configuration Validation Wizard (ClusPrep), agora disponível para download, substitui o antigo teste HCL (lista de certificação de hardware), que poderia levar meses para validar uma configuração completa e considerá-la "com suporte" em clusters. Isso deixa a ferramenta de validação de hardware nas mãos do DBA, reduzindo o custo (em termos de dinheiro e tempo) de colocar um hardware certificado em funcionamento. Talvez até seja possível validar e implantar um hardware heterogêneo dentro de um conjunto de nós de cluster.

P Um procedimento de exclusão em um dos meus computadores parece estar parado depois de 12 horas. Não está bloqueado. O plano de consulta mais lento revela um disparador sendo executado por 87,327 segundos. Por isso, suponho que o procedimento tenha parado nesse disparador. Como saber exatamente qual declaração parou?

R É bem possível que um loop dentro do disparador não esteja saindo por diversos motivos. Se a parada for muito longa e você desejar saber qual instrução está em execução, execute o código da Figura 1. Ele dirá qual instrução está em execução no momento; provavelmente, é ela que está causando a parada do computador.
Figure 1 Localize a instrução atualmente em execução (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

P Preciso oferecer suporte à replicação transacional por meio de um firewall. O editor e o distribuidor estão fora do firewall e o assinante está dentro. O assinante está definido para escutar em 1433, e os nomes do meu computador são: Editor: PUBMACHINE; Distribuidor: DISTMACHINE; Assinante: SUBMACHINE. Que portas preciso abrir para permitir que a captura de tela inicial e o envio da inscrição sejam bem-sucedidos?

R Se você estiver usando uma inscrição de envio, abrir a porta (1433 no seu caso) do SQL Server deve ser suficiente, pois o agente de distribuição estará sendo executado no computador distribuidor (fora do firewall) e provavelmente terá acesso local aos arquivos de instantâneos gerados pelo Snapshot Agent. Mas, se você estiver usando uma inscrição de recebimento, o agente de distribuição no computador assinante precisará acessar os arquivos de instantâneos, de alguma forma, por meio do firewall. A seguir, veja as opções que você pode considerar.
Supondo que os arquivos de instantâneo já estejam acessíveis em um compartilhamento de arquivos fora do firewall, você pode abrir a(s) porta(s) de compartilhamento de arquivos do Windows® por meio do firewall para que o agente de distribuição executado dentro do firewall possa acessar os arquivos de instantâneos localizados fora (mas cuidado com implicações de segurança que isso pode acarretar para outras partes da sua infra-estrutura). Observe que, ao configurar um caminho local como o local de instantâneos padrão (SSMS padrão), será necessário usar a opção /AltSnapshotFolder do agente de distribuição para substituir o local de retirada de arquivos de instantâneo.
Você também pode configurar a replicação para que use FTP ao transferir arquivos de instantâneos (e, para isso, terá de abrir a porta 21).

P Gostaria de saber se existe alguma desvantagem em desabilitar a conta SA no SQL Server 2005 e se isso representa um ganho real em termos de segurança. Existe um white paper sobre essa questão?

R Em uma nova instalação do SQL Server 2005, quando o Modo Misto não está habilitado, a conta SA é desabilitada, por padrão, e uma senha aleatória é gerada para ela. Você também pode desabilitá-la manualmente. Não existe um white paper sobre isso, mas a questão de desabilitar e renomear logons é discutida em um documento de práticas recomendadas.
Para se proteger de tentativas de obtenção de acesso à conta SA, você também pode renomeá-la. Mas não se esqueça de que, se habilitar uma conta desabilitada, será necessário definir uma nova senha para ela.
Para responder à questão de representar um verdadeiro ganho de segurança, lembre-se de que a segurança adicional ao desabilitar a conta vem do fato de que é inútil tentar adivinhar a senha de uma conta desabilitada. Por mais tempo que um hacker ou vírus tenha, um ataque frontal contra uma conta bloqueada não terá êxito. O ato de renomear ou desabilitar a conta SA interromperá os aplicativos que dependem dela para sua conectividade. De qualquer forma, encontrar e corrigir ou eliminar esses aplicativos deveria ser considerado uma prioridade. Conforme mencionado, a conta não pode ser usada para se conectar ao banco de dados enquanto não for reabilitada. Além disso, como o processo de autenticação falha primeiro, uma tentativa fracassada exigirá menos do sistema atacado.

P Um de meus maiores bancos de dados OLTP (processamento de transações online) possui um arquivo de log com o dobro do tamanho do arquivo de dados. Tentei usar os seguintes comandos para que o arquivo de log tivesse um tamanho razoável, mas preciso reduzi-lo ainda mais:
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

R Você deve alterar o banco de dados de backup para uma instrução de log de backup. Se preferir, você pode colocar o banco de dados em um modo de recuperação simples e emitir a instrução shrinkfile. Depois de concluir a redução do log, defina o banco de dados com seu modelo de recuperação anterior e faça backup do banco de dados. Se ainda assim ele não for reduzido, verifique se não há alguma transação aberta (use dbcc opentran). O seguinte artigo da Base de Dados de Conhecimento fornece mais informações: support.microsoft.com/kb/907511.

P Se ocorrer um failover durante um trabalho programado do SQL Server Agent, o que acontecerá com esse trabalho depois? Precisarei reiniciá-lo manualmente?

R Sim, você terá de iniciá-lo manualmente se não tiver outro processo disponível. Para não precisar reiniciar os trabalhos manualmente, você pode escrever um script que atualize uma tabela após a conclusão do trabalho. Se o valor for = 1, o trabalho foi executado; qualquer outro valor indica que ele não foi concluído e um segundo trabalho acontecerá posteriormente e emitirá o comando start. Assim, embora os trabalhos devam ser executados novamente quando ocorre um failover durante sua aprovação, ao escrever um script, você pode aliviar a preocupação com aqueles trabalhos cruciais no meio da noite que, invariavelmente, precisam ser concluídos antes do próximo dia útil.
Dica: atualização e DBCC UPDATEUSAGE
Você está fazendo a atualização do SQL Server 2000 para o SQL Server 2005?
Nesse caso, não deixe de executar o DBCC UPDATEUSAGE assim que seus bancos de dados forem atualizados.
O DBCC UPDATEUSAGE relata e corrige imprecisões de contagem de páginas e de linhas nas exibições de catálogo. Essas imprecisões precisam ser corrigidas porque podem causar relatórios de uso de espaço incorretos a serem retornados pelo procedimento armazenado do sistema sp_spaceused. No SQL Server 2005, esses valores são sempre mantidos corretamente, de forma que esses bancos de dados nunca experimentem contagens incorretas. Entretanto, os bancos de dados atualizados para o SQL Server 2005 podem ter contagens inválidas e, por isso, você deve executar o DBCC UPDATEUSAGE após a atualização.
Veja como o DBCC UPDATEUSAGE funciona. Ele corrige as contagens de linhas, páginas usadas, páginas reservadas, páginas de folha e páginas de dados para cada partição em uma tabela ou em um índice. Se não houver imprecisões nas tabelas do sistema, o DBCC UPDATEUSAGE não retornará nenhum dado. Se imprecisões forem encontradas e corrigidas, mas você não usou WITH NO_INFOMSGS, o DBCC UPDATEUSAGE retornará as linhas e colunas que estão sendo atualizadas nas tabelas do sistema.
O DBCC UPDATEUSAGE também pode ser usado para sincronizar contadores de uso de espaço. Como o DBCC UPDATEUSAGE pode demorar algum tempo para ser executado em grandes tabelas ou bancos de dados, ele deve ser usado, em geral, quando você suspeitar que sp_spaceused está retornando valores incorretos. Observe que sp_spaceused aceita um parâmetro opcional para executar DBCC UPDATEUSAGE antes de retornar as informações de espaço para a tabela ou o índice.
O DBCC CHECKDB foi aprimorado no SQL Server 2005 para detectar quando a contagem de página ou de linha se torna negativa. Quando números negativos são detectados, o DBCC CHECKDB emite um aviso e uma recomendação para executar o DBCC UPDATEUSAGE a fim de sanar o problema. Embora possa parecer que a atualização do banco de dados para o SQL Server 2005 cause esse problema, saiba que as contagens inválidas já existiam antes do procedimento de atualização.
Por exemplo, veja como atualizar as contagens de página, de linha ou ambas para todos os objetos no banco de dados atual. O comando a seguir especifica 0 para o nome do banco de dados e o DBCC UPDATEUSAGE relata as informações atualizadas para o banco de dados atual:
DBCC UPDATEUSAGE (0);
GO
Para atualizar as contagens de página, de linha ou ambas para, digamos, AdventureWorks, e também suprimir mensagens informativas adicionais, execute um comando semelhante ao seguinte, que especifica AdventureWorks como o nome do banco de dados e, em seguida, suprime todas as mensagens informativas:
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
Para obter mais informações, pesquise DBCC UpdateUsage no SQL Server Books Online.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 Destaque de utilit&#225;rio: SMSMap
Destaque de utilitário
SMSMap
Jeff Tondt
Faça download do código deste artigo: UtilitySpotlight2007_07.exe (2477KB)

Uma imagem vale mais do que mil palavras. Esse provérbio comum refere-se à idéia de que histórias complexas podem ser contadas com apenas uma única imagem, ou que uma imagem pode influenciar mais do que uma grande quantidade de texto. O provérbio também caracteriza com habilidade os objetivos da visualização, em que grandes quantidades de dados devem ser absorvidas rapidamente.
Para um maluco por System Management Server (SMS) como eu, ver toda a hierarquia SMS em uma só imagem me ajuda a compreender como minha infra-estrutura está disposta. Você poderia usar uma imagem como essa, talvez, para mostrar o antes e o depois de um plano de migração SMS para gerenciamento. Em certos casos de solução de problemas, um diagrama como esse poderia ser muito útil para encontrar uma solução ou pelo menos para obter a ajuda de outras pessoas. E, é claro, como um administrador SMS responsável, você precisa documentar sua hierarquia de sistema por muitos outros tipos de motivos.

Criando a imagem
Não é que você não possa desenhar você mesmo o diagrama. Sem dúvida você pode arregaçar as mangas, desenhar manualmente a hierarquia SMS e documentar as configurações do local à mão. Se você tem o Microsoft® Operations Manager (MOM) para monitorar seus servidores SMS, pode fazer com que ele diagrame sua hierarquia — apesar de eu ter que fazer a ressalva de que o MOM não é dos mais habilidosos com imagens e, certamente, não documenta as configurações do seu local. Pode haver outros métodos ou ferramentas úteis, mas ainda não encontrei nada que criasse adequadamente imagens bonitas e ajudasse a documentar as configurações do local — pelo menos não para minha satisfação.
Então eu decidi criar o meu próprio software. Assim nasceu o SMSMap 1.0. O SMSMap é um aplicativo em Visual Basic® .NET que usa as bibliotecas gerenciadas SMS no SDK do SMS e automatiza o Microsoft Visio® via COM. O utilitário consulta um servidor de site SMS alvo e, com isso, cria um diagrama visualmente atraente no Visio e exporta as configurações do site para um arquivo XML. O XML foi escolhido por ser a forma mais compatível de documentar as configurações do site. Escolhi mostrar também as funções SMS, não só os servidores físicos relacionados a outros servidores SMS. Isso permite reformular o diagrama por meio das camadas do Visio para observar a hierarquia SMS de vários pontos de vista.
Figura 1 Formato radial
Figura 1 Formato radial
Atualmente, o programa possibilita que você selecione seis formatos diferentes para o diagrama Visio. Por exemplo, a Figura 1 mostra uma hierarquia SMS muito simples usando o formato radial, enquanto a Figura 2 mostra a mesma hierarquia usando o formato de fluxograma. O utilitário funciona bem com hierarquias muito maiores, mas eu não gostaria de criar dificuldade aqui.
Figura 2 Formato de fluxograma
Figura 2 Formato de fluxograma
Em algum momento, o SMSMap provavelmente irá evoluir para documentar todas as configurações do site. Atualmente, ele documenta apenas as funções do site SMS e todos os limites. Com um pouco de esforço, muitas outras configurações de site podem ser exportadas para o arquivo XML.

Usando o SMSMap
Os arquivos de instalação e código-fonte do SMSMap estão disponíveis no site da TechNet Magazine. Para instalá-lo, basta executar o SMSMapSetup.msi, que o orientará durante a instalação. Lembre-se de que o SMSMap usa o Visio, então você precisa também já tê-lo instalado. Após a instalação, execute C:\Arquivos de Programas\Microsoft\smsmap\smsmap.exe (a menos que você o tenha instalado em um local diferente do padrão).
Você pode executar o SMSMap em qualquer máquina, pois não precisa executá-lo no servidor do site (e é improvável que muitos servidores de site SMS tenham o Visio instalado). Insira o nome de servidor de site SMS em que você deseja que a consulta seja originada. Pode ser o site central, se você deseja consultar toda a hierarquia, ou pode ser qualquer servidor de site primário filho, mas nesse caso você obterá apenas a hierarquia a partir desse site primário filho e inferiores. Em seguida, digite a conta que tem permissão para consultar o SMS usando o formato domínio\nomedeusuário e a senha dessa conta. (A senha não será exibida, você pode executar o aplicativo na frente de outras pessoas.)
Seis botões de opção possibilitam que você selecione o layout, e é possível escolher se deseja permitir ou impedir que as funções SMS apareçam no desenho. Essas caixas de seleção estão localizadas na guia Options (Opções). Pressionar o botão Draw (Desenhar) dá início ao utilitário. Em primeiro lugar, ele verifica se o Visio está disponível, depois consulta o servidor do site primário SMS especificado e adiciona os objetos ao diagrama Visio. O diagrama do Visio pode parecer feio enquanto o SMSMap está agrupando os objetos, mas no final o utilitário os organiza no formato especificado no início.
Mergulhando mais fundo
Agora você viu por que e como documentar sua hierarquia SMS usando o SMSMap. Para aqueles que desejam flexionar seus músculos de desenvolvedor, vamos olhar mais em detalhes como o utilitário funciona.
O SMSMap utiliza interfaces do servidor de site SMS gerenciado para reunir as informações de SMS e os conjuntos de módulos de interoperabilidade primária do Visio para gerar um diagrama no Visio que disponha os dados em todas as formas necessárias. O SMS 2003 SDK versão 3.1 contém o lançamento mais recente das interfaces de servidor de site SMS gerenciado. Esse conjunto de interfaces gerenciadas possibilita que você conecte e configure um servidor de site SMS por meio de qualquer aplicativo ou linguagem habilitada para Microsoft .NET Framework.
Essas interfaces usam o namespace System.Management para interagir com um provedor SMS por meio de WMI (Instrumentação de Gerenciamento do Windows®). Para usar as interfaces, você deve desenvolver seu aplicativo com uma linguagem compatível com .NET (por exemplo, C#, Visual Basic .NET e assim por diante) e consultar o Microsoft.SystemsManagementServer.Automation.dll que o assembly .NET forneceu com o SDK do SMS.
As classes de gerenciamento do .NET resolvem muitas das idiossincrasias do modelo de objeto WMI para apresentar um modelo consistente e orientado a objetos. As tarefas básicas de conexão WMI, enumeração de objetos, execução de métodos, exclusão e recuperação de objetos e captura de eventos podem todas ser realizadas pelas classes de gerenciamento .NET.

Conjuntos de módulos de interoperabilidade primária do Visio
Um conjunto de módulos (assembly) de interoperabilidade primária possibilita que você use código gerenciado para controlar aplicativos COM como o Visio por meio de programação. Os conjuntos de módulos de interoperabilidade primária do Visio permitem que você integre e amplie a funcionalidade do Visio em aplicativos gerenciados.
Se você já tem o .NET Framework instalado no seu computador, quando instalar posteriormente o Visio, o instalador adicionará os conjuntos de módulos de interoperabilidade primária do Visio ao GAC (Global Assembly Cache) no seu computador. Você pode adicionar uma referência aos conjuntos de módulos de interoperabilidade primária do Visio a partir de seus aplicativos gerenciados.
Depois de adicionar uma referência ao projeto, você poderá começar a trabalhar com objetos Visio a partir de seus aplicativos gerenciados. O Visio tem um modelo de objeto abrangente, que oferece um conjunto de classes, interfaces e enumerações para que você possa criar diagramas por meio de programação.

Fluxo do programa
Agora que descrevi as principais interfaces de componente do Visio e do SMS, passarei para a explicação sobre o fluxo do utilitário em si.
O primeiro passo ao usar as interfaces gerenciadas é estabelecer conexão com o provedor SMS. Isso pode ser feito por meio da criação de uma nova instância da classe SMSProvider. Internamente, essa classe irá encontrar o provedor SMS para o servidor do site especificado e conectar-se a ele com um dado conjunto de credenciais. Se o provedor estiver na máquina local, as credenciais atualmente conectadas serão usadas em vez das credenciais fornecidas quando se conectar ao provedor. Apesar de você poder executar o SMSMap no servidor SMS, recomendo executá-lo em uma estação de trabalho separada, que tenha o Visio instalado. A maioria dos servidores de site SMS não possui o Visio instalado por motivos óbvios.
Quando você acessa os dados no site SMS por meio da classe SMSProvider, os direitos de segurança são tratados como se você estivesse usando o SMS Administrators Console. Isso significa, por exemplo, que se você tentar definir as configurações de um servidor de site por meio de um SMSProvider, a conta com que você se conecta ao provedor deverá ter o mesmo conjunto de direitos que se você estivesse usando o console do administrador.
A classe SMSProvider fornece um método GetSiteSettings que lhe permite entrar nas configurações do site atual (ao qual o provedor pertence) ou de qualquer outro site com um código de site específico. O trecho de código na Figura 3 mostra como o SMSMap conecta-se ao provedor do servidor de site alvo. Espera-se que as credenciais do usuário sejam passadas no formato Domínio\Usuário. Você pode também especificar "." para indicar a máquina atual. A Figura 3 também inclui código que ajuda a exibir os resultados na interface de usuário e para registro em log.
Figure 3 Trecho de GetSiteSettings (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
O próximo passo é definir o arquivo XML para reunir e gravar as informações SMS do servidor de site alvo, conforme mostrado na Figura 4.
Figure 4 Criando o arquivo XML (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
Em seguida, o site alvo precisa ser desenhado no diagrama do Visio e atualizado na interface e no registro em log, como você pode ver na Figura 5.
Figure 5 Desenhando o site no Visio (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
Para abranger toda a hierarquia contida no site alvo, é executado o mesmo código básico descrito acima, que consulta o SMS e desenha no Visio. Essa é uma função denominada Level, que é chamada recursivamente para garantir que todos os sites filhos sejam consultados, independentemente do tamanho da hierarquia. O Level reúne as informações do site SMS e as registra em XML, na interface do usuário e no log de cada site filho dentro do site alvo. Por fim, a Figura 6 mostra como o diagrama do Visio é formatado com o formato selecionado quando o utilitário é iniciado. Em seguida, os arquivos XML e de log são fechados.
Figure 6 Terminando (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

Somente o começo
É claro que isso é só o começo e há muitas possibilidades para melhorias. Os pontos de gerenciamento de dispositivos precisam ser investigados, pois não os vejo no SDK. Várias outras configurações de site poderiam ser adicionadas para documentar um site por completo. Talvez precise haver mais trabalho em relação à adição de uma variedade mais ampla de configurações de layout no Visio para ajudar a melhorar o aspecto de hierarquias pequenas e grandes. Cada tipo de layout possui suas próprias dificuldades quando se tenta criar modos de exibição eficientes. E, é claro, acrescentar suporte para o System Center Configuration Manager 2007 é uma próxima etapa muito importante. Mas mesmo essa primeira versão do SMSMap pode ajudar os administradores do SMS a exigir uma imagem geral e tentar alguns cenários de tentativa com as camadas e transparências do Visio.
Se você baixar o código-fonte, poderá ampliar o utilitário para atender às suas próprias necessidades. Testei o SMSMap no Windows XP SP2 com Visio 2003 e no Windows Vista™ Enterprise com Visio 2007. Se você tem sugestões sobre como melhorar esse utilitário, envie um email para mim no endereço jeff.tondt@microsoft.com.

Jeff Tondt é consultor sênior II da Microsoft Consulting Services. Ele está focado nas áreas de gerenciamento de sistemas, automação e gerenciamento de patches. Jeff é um especialista na área de SMS e para entrar em contato, use o endereço jeff.tondt@microsoft.com.


 Como funciona: Solucionando problemas de RPC
Como funciona
Solucionando problemas de RPC
Zubair Alexander

Se você trabalha com plataformas de servidor Windows há algum tempo, é provável que já tenha visto erros de RPC (chamada de procedimento remoto) uma vez ou outra. Eles dizem que o servidor RPC não está disponível ou que não há mais pontos de extremidade disponíveis ou oferecem algum outro aviso misterioso. Se essas mensagens o deixam confuso, continue a ler. Examinarei
alguns dos erros mais comuns, várias técnicas que podem ser usadas na identificação de erros de RPC exibidos e discutirei algumas soluções para problemas específicos. Mas antes de falar sobre erros e soluções específicos de RPC, vamos conhecer a sua terminologia.

O que é RPC?
O RPC é um método de IPC (comunicação entre processos) usado na comunicação entre clientes e servidores. Simplificando, o RPC é usado por programas, normalmente em um computador cliente, para executar um programa em um computador servidor. Por exemplo, os clientes Microsoft® Outlook® se comunicam com o Microsoft Exchange Server usando RPC. O computador cliente envia uma mensagem para o computador servidor com alguns argumentos. O servidor responde ao cliente com uma mensagem que contém os resultados do programa executado.
O ponto de extremidade integral neste processo — o nome, a porta ou o grupo de portas em um computador monitorado por um servidor para a entrada de solicitações de clientes. Mais especificamente, é um endereço de rede de um processo de servidor usado para RPCs.
O Mapeador de Pontos de Extremidade, parte do subsistema RPC, é o responsável por responder as solicitações dos clientes para a resolução de pontos de extremidade dinâmicos. Em algumas situações, ele também é o responsável pela atribuição dinâmica de pontos de extremidade a servidores.
Outro componente importante do RPC é o serviço localizador. Ele mantém uma lista de serviços e servidores RPC da rede. Um cliente Windows® se conecta ao controlador de domínio por meio de portas SMB (Bloco de Mensagens do Servidor) (TCP 139 e 445) e procura por serviços ou servidores RPC por meio do serviço localizador.
Quase todos os serviços internos do Windows se comunicam uns com os outros usando RPC. Por exemplo, os serviços de certificados, DCOM, FRS, MSMQ, MAPI, e o serviço de replicação do Active Directory® usam o RPC para a comunicação. Portanto, se o serviço RPC não estiver funcionando adequadamente em uma rede, você poderá ter alguns problemas de comunicação.

Erros de RPC
Agora vamos examinar alguns dos erros que você poderá encontrar quando o serviço RPC estiver com problemas (esta lista não constitui a relação completa dos problemas).
Quando o FRS (serviço de replicação de arquivos) falha, pode gerar o temível erro "RPC Indisponível" na rede. Se você tentar mapear uma unidade, obtém o erro "Acesso negado". Quando estiver usando o Usuários e Computadores do Active Directory, talvez você veja um erro que diz "O domínio especificado não existe ou não pôde ser contatado". A conexão no domínio pode gerar um erro que declara "O sistema não pode fazer logon neste domínio. A conta de computador do sistema no domínio primário não existe ou a senha da conta não está correta".
Quando o cliente Microsoft Outlook tenta se comunicar com o Exchange Server, as falhas de RPC podem confundir o cliente com erros como "As informações de logon fornecidas estavam incorretas" ou "Outlook não pode se conectar".
Além desses erros, é possível que você encontre outros problemas quando o serviço RPC não estiver disponível. Por exemplo, talvez você não consiga navegar pelo domínio em Meus locais de rede ou talvez não consiga abrir o snap-in Diretiva de Grupo.
Esses são apenas alguns dos exemplos em que talvez você não esperasse ter problemas com o RPC. Existem mais exemplos e, sempre que você estiver envolvido com processos remotos, os problemas de RPC poderão ser a principal causa das suas dificuldades. Dessa forma, como você pode ter certeza disso e, mais importante, como pode rastrear com precisão o erro? Vamos descobrir.

Solução de problemas
Se você suspeita do serviço RPC, existem diversas ferramentas que podem ser usadas no diagnóstico de problemas.
Uma opção é a ferramenta Repadmin. Esse programa é comumente usado para monitorar e solucionar problemas de replicação do Active Directory, mas também pode ser usado para solucionar problemas do Mapeador de Pontos de Extremidade RPC. Para executá-lo, no prompt de comando, digite repadmin /bind. Se houver problemas de RPC, talvez seja exibida uma mensagem como esta: "O Mapeador de Pontos de Extremidade não possui mais pontos finais disponíveis". Essa é a primeira pista que indica que o problema está relacionado ao RPC.
Outra opção é usar a ferramenta de diagnóstico do controlador de domínio (DCDiag), um programa de linha de comando para o diagnóstico de problemas com controladores de domínio. Se você encontrar o erro "Erro 1722: O servidor RPC não está disponível", saberá que há um problema de RPC que a ferramenta de diagnóstico do controlador de domínio acabou de descobrir.
Existem ocasiões em que você estará usando o Ntdsutil (uma ferramenta de linha de comando usada no gerenciamento do Active Directory e na execução de diversas tarefas de manutenção) e verá erros de RPC se tentar se conectar ao servidor. É mais provável que você veja um dos erros mais comuns, como "O Mapeador de Pontos de Extremidade não possui mais pontos finais disponíveis". Novamente, essa é uma pista que pode indicar a existência de problemas com o serviço RPC. A ferramenta Gpotool, que verifica a consistência de objetos de Diretiva de Grupo em controladores de domínio, também mostrará para você erros similares caso o RPC seja o culpado.
O Dcpromo.log gerado quando você promove um servidor Windows 2000 Server ou um Windows Server® 2003 para controlador de domínio usando a ferramenta Dcpromo também pode revelar problemas com o RPC. Por exemplo, se a promoção falhar, examine o log. Ele está localizado na pasta %windir%\debug. Os erros listados indicarão algo como o serviço de diretório tivesse falhado em replicar a partição ou falhado em criar o objeto. No final da mensagem haverá um código de erro. A seguir, um exemplo do tipo de mensagem de erro que pode ser exibida em Dcpromo.log:

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
Observe o código de erro 1722, que ocorre quatro vezes nessa mensagem e indica que o servidor RPC não está disponível. A Figura 1 lista alguns códigos de erros e suas descrições, mas você pode saber mais sobre eles no site msdn2.microsoft.com/ms681386.
Figure 1 Os códigos de erro e suas descrições (Close Figure 1)

Código de erro | Descrição
58 | O servidor especificado não pode executar a operação solicitada.
1721 | Os recursos são insuficientes para completar esta operação.
1722 | O servidor de RPC não está disponível.
1723 | O servidor de RPC está muito ocupado para completar esta operação.
1727 | A chamada de procedimento remoto falhou e não foi executada.
1753 | O mapeador de pontos finais não possui mais pontos finais disponíveis.

Solucionando erros de RPC
Agora que você já viu como alguns dos erros de RPC podem ser detectados, vamos examinar algumas das soluções.
Os clientes Microsoft se conectam ao Mapeador de Pontos de Extremidade RPC na porta 135. Em seguida, ele diz ao cliente em que porta o serviço solicitado está escutando. Os números de porta são atribuídos dinamicamente e podem ser qualquer número entre 1024 e 65.535. Quando erros forem exibidos, como o 1753, que dizem a você que não há mais pontos de extremidade disponíveis no Mapeador de Pontos de Extremidade, isso significa que ele foi incapaz de utilizar uma porta maior do que 1024 para um serviço. Explicarei esse tópico em mais detalhes um pouco mais adiante.
A primeira coisa que você deve fazer é verificar o status do serviço RPC no servidor. Dependendo do tipo da função de servidor, o serviço RPC e o Localizador RPC devem ter o status exibido na Figure 2. Se nenhum dos dois serviços estiver configurado como mostrado na figura, tente ajustar o status, reinicializar o seu servidor e verificar se isso resolveu o problema.
Figure 2 Status do serviço RPC (Close Figure 2)

Função de servidor | Serviço RPC | Serviço Localizador RPC
Windows Server 2003 — controlador de domínio | Iniciado, Automático | Parado, Manual
Windows Server 2003 — servidor membro | Iniciado, Automático | Parado, Manual
Windows Server 2003 — servidor autônomo | Iniciado, Automático | Parado, Manual
Windows 2000 Server — controlador de domínio | Iniciado, Automático | Parado, Automático
Windows 2000 Server — servidor membro | Iniciado, Automático | Iniciado, Manual
Windows 2000 Server — servidor autônomo | Iniciado, Automático | Parado, Manual
Verifique se o seu cliente pode fazer um ping bem-sucedido no servidor que estava com problemas de conectividade. Por exemplo, se você estiver tendo problemas de comunicação com um servidor chamado DC1, cujo endereço IP é 192.168.1.200, use o comando a seguir no prompt de comando para verificar se o DNS está resolvendo com sucesso o host DC1:
Ping –a 192.168.1.200
Não se esqueça de usar a opção –a com o endereço IP e não o nome do host.
Se tudo estiver funcionando, você obterá uma resposta de DC1 parecida com a resposta do ping mostrado na Figura 3. Observe que, em vez de simplesmente resolver o endereço IP 192.168.1.200, o Ping também resolveu o nome de host dc1.contoso.com. Isso confirma que a resolução de nomes DNS está funcionando corretamente e resolveu o nome do host dc1.contoso.com exatamente como esperado.
Figure 3 Resposta do ping (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
Você também deve verificar se o registro do seu cliente Windows XP ou Windows 2000 contém pelo menos os quatro ClientProtocols listados no painel direito da Figura 4.
Figura 4 ClientProtocols do RPC listados no registro
Figura 4 ClientProtocols do RPC listados no registro
Se qualquer uma das entradas estiver ausente, adicione um novo valor de cadeia de caracteres com o nome e o tipo de dados mostrados na Figura 4. Por padrão, existe uma quinta entrada chamada ncacn_nb_tcp, usada para identificar NetBIOS sobre TCP como a família de protocolos para o ponto de extremidade. Dependendo da sua configuração, talvez você não tenha essa entrada listada em ClientProtocols, podendo adicioná-la manualmente para resolver os erros de RPC.
Observe as chaves listadas na pasta Rpc do painel esquerdo da figura, ClientProtocols, NameService, NetBios e SecurityService. Se houver uma chave chamada Internet sem valores, tente removê-la e reiniciar o seu computador. Isso pode ajudar a resolver o seu problema. Como sempre, tome cuidado ao modificar o registro do Windows.
Como mencionado antes, o RPC pode usar portas entre 1024 e 65.535 e, portanto, você precisa verificar se essas portas não estão bloqueadas em um firewall. A forma mais simples de verificar se uma porta está aberta é usar a ferramenta Port Query. Ela possui dois tipos: uma versão de linha de comando (PortQry) e uma versão GUI (PortQueryUI).
PortQry está disponível para download no Centro de Download da Microsoft. Para obter informações adicionais, leia o artigo "Descrição do utilitário de linha de comando Portqry.exe". Ali, você encontrará breves descrições dos relatórios de status do PortQry e exemplos de comandos a serem usados na resolução de problemas. Lembre-se de que você também pode usar a versão GUI, que é muito mais simples e pode ser baixada em go.microsoft.com/fwlink/?LinkId=73740.
Quando usar o Port Query, não se esqueça de executá-lo em um computador que não esteja tendo erros de RPC e execute-o direcionado a um computador que esteja apresentando problemas com RPC. Por exemplo, se você quiser verificar se a porta 135 — usada pelo Mapeador de Pontos de Extremidade RPC — está aberta, use o PortQry no prompt de comando como mostrado a seguir:
portqry -n [servername] -e 135
Usando o PortQuery ou o PortQueryUI, você obteria resultados semelhantes a estes:
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
A última linha mostra que a porta 135 está aberta. Caso contrário, ela teria indicado NOT LISTENING.
Para verificar um intervalo de portas, insira o intervalo de números de porta separado por vírgulas, como em "135,1024-5000".

Soluções adicionais
Se você já tentou todos os truques listados até aqui e o problema ainda não foi resolvido, ainda existem algumas opções adicionais abertas. Dependendo dos problemas específicos do seu ambiente, talvez seja melhor tentar uma das seguintes modificações no registro (Espere! Antes de fazer qualquer alteração, é importante verificar se você fez backup do sistema, especialmente do registro, para que, se algo der errado, possa restaurar o computador ao seu estado anterior).
Uma opção é ajustar MaxUserPort para especificar o número mais alto de porta que o TCP poderá atribuir quando um aplicativo solicitar uma porta de usuário disponível para o sistema. Por padrão, o Windows Server 2003 define o valor de MaxUserPort como 5000, o que significa que ele está usando 5000 como o número mais alto de porta, mesmo se a entrada não existir. Dependendo da sua configuração, talvez você não tenha essa entrada no registro, podendo adicioná-la ao local mostrado na Figura 5.
Figura 5 Configuração de MaxUserPort no registro
Figura 5 Configuração de MaxUserPort no registro
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
Ao modificar o registro, você precisa estar atento a outros potenciais efeitos colaterais, o que nem sempre é fácil. A modificação dessa entrada pode causar impacto no Microsoft Exchange Server caso o valor seja definido como menor do que 50.000. Se o BPA (Best Practices Analyzer) do Exchange souber que o valor da chave do registro MaxUserPort é menor do que 50.000, exibirá um aviso. A Microsoft recomenda que você defina o valor como 60.000; caso contrário, isso poderá gerar avisos de proxy do NSPI (Interface de Provedor de Serviço de Nome), como o Evento 9040. Para obter mais informações, consulte o documento "O valor de MaxUserPort é muito baixo" da Microsoft.
Você também pode ajustar TcpMaxDataRetransmissions. Os pacotes TCP esperam uma confirmação da extremidade de recepção. Se não houver uma confirmação antes da expiração do tempo, então os pacotes serão retransmitidos, até o número de vezes estipulado em TcpMaxDataRetransmissions. O valor padrão desse parâmetro é 5, mas você pode experimentar um valor 4, ou até mesmo 3. Não utilize um valor abaixo de 3.
Se a entrada do registro TcpMaxDataRetransmissions não existir, adicione-a ao local mostrado como a seguir:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
Para obter mais informações sobre TcpMaxDataRetransmissions, leia o artigo 170359 da Base de Dados de Conhecimento Microsoft, "Como modificar o tempo de expiração de retransmissão máximo do TCP/IP".
Outro valor do registro que talvez você queira testar é TcpTimedWaitDelay. Se um cliente usar portas demais, é bem possível que ele fique sem portas antes de o TCP/IP liberar conexões encerradas. Isso acontece porque o TCP/IP não libera a conexão até que duas MSLs (vida útil máxima do segmento) tenham passado (nos referimos a isso como estado de espera de tempo). Além disso, já que cada MSL é definida como 120 segundos e o TCP/IP não libera a conexão até que duas MSLs tenham passado, o TCP/IP leva até 240 segundos (4 minutos) para liberar uma conexão encerrada. Observe que isso era um problema bem conhecido do Windows NT® e que foi corrigido em um service pack; como resultado, é bem menos provável que você tenha esse problema hoje. No entanto, a Microsoft recomenda o ajuste dessa configuração como uma das possíveis soluções de erros com o Mapeador de Pontos de Extremidade RPC, como explicado no artigo da Base de Dados de Conhecimento "Como solucionar problemas do Mapeador de Ponto de Extremidade RPC".
TcpTimedWaitDelay é adicionado ao registro no seguinte local:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
Para obter mais informações sobre TcpTimedWaitDelay, leia o artigo da Base de Dados de Conhecimento "Os clientes Windows NT ficam sem portas". Embora o artigo não recomende quaisquer números específicos, talvez seja bom tentar reduzir TcpTimedWaitDelay para 60 (segundos) em decimal, que é 3c em hexadecimal.

Conclusão
Os erros de RPC podem ser a principal causa de diversos erros de comunicação em sua rede. Felizmente, existem várias maneiras criativas de solucionar esses problemas enganosos. Algumas das ferramentas que sugeri aqui são internas, enquanto outras estão disponíveis no kit de recursos do Windows Server. Muitos estão listados na Figura 6. Você pode usar essas ferramentas para detectar a causa e o local dos erros de RPC e então usar uma das técnicas mostradas neste artigo para resolver os problemas.
Figure 6 Ferramentas de solução de problemas de RPC (Close Figure 6)

Ferramenta | Descrição
DCDiag | Analisa o estado de controladores de domínio.
Visualizar eventos | Exibe os eventos registrados.
Gpotool | Determina se as diretivas são válidas e consistentes.
NetDiag | Usado para testar a conectividade de rede.
Monitor de rede | Monitora e captura o tráfego na rede.
Ntdsutil | Oferece recursos de gerenciamento do Active Directory.
PortQry, PortQueryUI | Usado para testar a conectividade do TCP/IP.
Repadmin | Faz diagnósticos de problemas de replicação entre controladores de domínio do Windows.
RPCDump | Normalmente usado em conjunto com o Monitor de rede.
RPCPing | Usado para confirmar a conectividade RPC.

Zubair Alexander, MCSE, MCT e Microsoft MVP, é o proprietário da SeattlePro Enterprises, uma empresa de treinamento e consultoria em TI. Sua experiência abrange toda a gama de educação em TI: autor, professor universitário, consultor, engenheiro de rede, orador, arquiteto de segurança, administrador de sistemas, editor técnico e instrutor. Entre em contato com ele pelo email alexander@techgalaxy.net.


 The Cable Guy: Tr&#225;fego IPv6 em conex&#245;es VPN
The Cable Guy
Tráfego IPv6 em conexões VPN
Joseph Davies

Ao avaliar o papel do IPv6 (a versão 6 do protocolo de Internet) na intranet e começar a planejar sua implantação, é bom que você compreenda como o suporte ao tráfego do IPv6 funciona nas conexões VPN (rede virtual privada) no Windows. Com as conexões VPN, é possível estender a rede para incluir links em redes públicas
como a Internet. As conexões VPN são protegidas por fortes protocolos de autenticação, que validam as credenciais do usuário conectado, e métodos de criptografia, que fornecem a confidencialidade de dados.
O Windows® XP e o Windows Server® 2003 incluem uma pilha de protocolo sIPv6, mas muitos serviços essenciais e componentes de sistema de rede não oferecem suporte ao IPv6. O Windows Vista™ e o Windows Server 2008, anteriormente chamado "Longhorn", possuem suporte total para o IPv6, que é instalado e habilitado por padrão. Na verdade, quase todos os aplicativos e serviços de sistema de rede incluídos no Windows Vista e no Windows Server 2008 oferecem suporte ao IPv6. Este mês, examinarei o suporte no Windows Vista, Windows Server 2008, Windows XP e Windows Server 2003 para o tráfego IPv6 enviado em conexões VPN estabelecidas nas Internets IPv4 e IPv6.

Conexões VPN na Internet IPv4
Para a maioria das intranets atuais, as conexões VPN são criadas na Internet IPv4. A Figura 1 mostra os componentes baseados no Windows para conexões VPN desse tipo. Esses componentes consistem no seguinte:
Figura 1 Componentes baseados no Windows para conexões VPN na Internet IPv4
Figura 1 Componentes baseados no Windows para conexões VPN na Internet IPv4
Cliente VPN É um computador que inicia uma conexão VPN de acesso remoto com um servidor VPN e se comunica com recursos de intranet. A conexão VPN de acesso remoto permite que o cliente VPN aja como se estivesse diretamente conectado à intranet. O cliente VPN pode executar as versões cliente ou servidor do Windows.
Servidor VPN Esse computador ouve as tentativas da conexão VPN remota, impõe os requisitos de autenticação e conexão e roteia os pacotes entre os clientes VPN e os recursos da intranet. O servidor VPN normalmente executa uma versão servidor do Windows com o serviço de Roteamento e Acesso Remoto.
Roteador VPN O roteador VPN é um computador que inicia ou ouve as tentativas de conexão VPN de site para site. A conexão VPN de site para site é aquela que conecta duas partes de uma intranet. O roteador VPN executa uma versão servidor do Windows e o serviço de Roteamento e Acesso Remoto.
Conexão VPN A conexão VPN é o vínculo lógico entre o cliente e o servidor VPN, ou entre roteadores VPN, conforme definido pelo encapsulamento de um protocolo VPN.
Intranet habilitada para IPv6 Essa intranet pode encaminhar tráfego IPv6, tanto de forma nativa quanto encapsulada, como pacotes IPv4.
Host IPv6/IPv4 Esse nó de intranet envia e recebe tráfego IPv6, tanto de forma nativa quanto encapsulada, como pacotes IPv4.
Os clientes, servidores e roteadores VPN baseados no Windows podem usar os seguintes protocolos VPN para encapsular os pacotes enviados na conexão VPN: PPTP, L2TP sobre IPsec e SSTP. O SSTP só tem suporte no Windows Vista com Service Pack 1 (SP1, versão beta em fase teste) e no Windows Server 2008.
Para as conexões VPN na Internet IPv4, há dois métodos que são usados ao enviar IPv6: pacotes IPv6 encapsulados como pacotes IPv4, que chamarei de tráfego IPv6 via IPv4, e tráfego IPv6 nativo.
Nesta coluna, o suporte ao tráfego IPv6 em conexões VPN é mencionado em termos de protocolos VPN e versões do Windows. Para conexões VPN de acesso remoto, uma determinada combinação de protocolo VPN e versão do Windows implicam no suporte dos componentes cliente e servidor de acesso remoto do Windows.

Tráfego IPv6 via IPv4
Nesse método, um cliente de acesso remoto ou um host IPv6/IPv4 na intranet encapsula pacotes IPv6 com um cabeçalho IPv6 e envia o resultado como um pacote IPv4. Para intranets, a tecnologia de transição ISATAP (RFC 4214) IPv6 permite que nós IPv6/IPv4 troquem tráfego IPv6 em uma intranet somente IPv4. Com o ISATAP, é possível habilitar a conectividade IPv6 na intranet somente IPv4 sem ter de configurar ou atualizar os roteadores existentes para oferecerem suporte nativo a endereçamento e encaminhamento IPv6. Para obter mais informações sobre ISATAP, consulte "Tecnologias de transição IPv6" em microsoft.com/technet/network/ipv6/ipv6coexist.mspx.
A Figura 2 mostra a estrutura de pacotes geral para tráfego VPN ao enviar um pacote IPv4 usando uma conexão VPN na Internet IPv4. O pacote IPv4 é encapsulado pelo protocolo VPN com um cabeçalho e, dependendo do protocolo VPN, com as informações finais. O resultado é encapsulado com um cabeçalho IPv4, que permite encaminhamento na Internet IPv4.
Figura 2 Pacotes IPv4 usando uma conexão VPN na Internet IPv4
Figura 2 Pacotes IPv4 usando uma conexão VPN na Internet IPv4
Para tráfego IPv6 via IPv4, a carga do pacote IPv4 enviado na conexão VPN é um pacote IPv6. A Figura 3 mostra a estrutura de pacotes geral para tráfego VPN ao enviar um pacote IPv6 via IPv4 usando uma conexão VPN na Internet IPv4.
Figura 3 Pacotes IPv6 via IPv4 usando uma conexão VPN na Internet IPv4
Figura 3 Pacotes IPv6 via IPv4 usando uma conexão VPN na Internet IPv4
Para conexões VPN de acesso remoto, o tráfego IPv6 via IPv4 na Internet IPv4 possui suporte dos protocolos PPTP e L2TP/IPsec no Windows Vista, no Windows Server 2008, no Windows XP SP1 (ou superior) e no Windows Server 2003, e do protocolo SSTP no Windows Vista SP1 e no Windows Server 2008. Para conexões VPN de site para site, o tráfego IPv6 via IPv4 na Internet IPv4 possui suporte dos protocolos PPTP e L2TP/IPsec no Windows Server 2008 e no Windows Server 2003.

Tráfego IPv6 nativo
Para tráfego IPv6 nativo, o cliente, o servidor ou o roteador VPN envia pacotes IPv6 na conexão VPN sem o encapsulamento IPv4 inicial. Isso funciona para intranets que possuem conectividade IPv6 nativa e exigem que os clientes, servidores e roteadores VPN ofereçam suporte ao protocolo IPV6CP, RFC 2472, o que define a forma como os nós IPv6 negociam as opções de configuração IPv6 para conexões baseadas no protocolo PPP. O Windows Vista e o Windows Server 2008 oferecem suporte ao protocolo IPV6CP, enquanto o Windows XP e o Windows Server 2003 não oferecem. A Figura 4 mostra a estrutura geral de pacotes para tráfego VPN ao enviar um pacote IPv6 nativo usando uma conexão VPN na Internet IPv4.
Figura 4 Pacotes IPv6 nativos usando uma conexão VPN na Internet IPv4
Figura 4 Pacotes IPv6 nativos usando uma conexão VPN na Internet IPv4
Para conexões VPN de acesso remoto, o tráfego IPv6 nativo na Internet IPv4 possui suporte dos protocolos PPTP e L2TP/IPsec no Windows Vista e no Windows Server 2008, e do protocolo SSTP no Windows Vista SP1 e no Windows Server 2008. Para conexões VPN de site para site, o tráfego IPv6 nativo que viaja pela Internet IPv4 possui suporte dos protocolos PPTP e L2TP/IPsec no Windows Server 2008.

Conexões VPN na Internet IPv6
Também é possível estabelecer conexões VPN na Internet IPv6. Essas conexões VPN atualmente não são comuns, mas ganharão mais prestígio conforme os provedores de serviço da Internet oferecerem mais IPv6 aos seus clientes e mais organizações incluírem a conectividade da Internet IPv6 em suas redes de borda intranet.
Para oferecer suporte a conexões VPN na Internet IPv6, os protocolos VPN usados devem oferecer suporte a conexões em IPv6. No Windows Vista e no Windows Server 2008, os protocolos L2TP/IPsec e VPN SSTP oferecem suporte a conexões VPN de acesso remoto em IPv6. No Windows Server 2008, o protocolo L2TP/IPsec oferece suporte a conexões de site para site em IPv6. As conexões VPN na Internet IPv6 usam o mesmo conjunto de componentes usados na Internet IPv4 para conexões VPN de acesso remoto e de site para site.
Também existem duas maneiras de enviar pacotes IPv6 pela Internet IPv6: tráfego IPv6 via IPv4 e tráfego IPv6 nativo. A Figura 5 mostra a estrutura geral de pacotes IPv6 via IPv4 quando enviados por uma conexão VPN na Internet IPv6.
Figura 5 Pacotes IPv6 via IPv4 usando uma conexão VPN na Internet IPv6
Figura 5 Pacotes IPv6 via IPv4 usando uma conexão VPN na Internet IPv6
Para conexões VPN de acesso remoto, o tráfego IPv6 via IPv4 na Internet IPv6 possui suporte do protocolo L2TP/IPsec no Windows Vista e no Windows Server 2008, e do protocolo SSTP no Windows Vista SP1 e no Windows Server 2008. Para conexões VPN de site para site, o tráfego IPv6 via IPv4 na Internet IPv6 possui suporte do protocolo L2TP/IPsec no Windows Server 2008. Assim como na Internet IPv4, o tráfego IPv6 via IPv4 na Internet IPv6 requer a implantação de uma tecnologia de transição IPv6, como ISATAP, na intranet.
A Figura 6 mostra a estrutura geral de pacotes IPv6 nativos quando enviados por uma conexão VPN na Internet IPv6. Assim como na Internet IPv4, o tráfego IPv6 nativo na Internet IPv6 requer suporte ao protocolo IPv6CP e à implantação da conectividade IPv6 nativa na intranet.
Figura 6 Pacotes IPv6 nativos usando uma conexão VPN na Internet IPv6
Figura 6 Pacotes IPv6 nativos usando uma conexão VPN na Internet IPv6
Para conexões VPN de acesso remoto, o tráfego IPv6 nativo na Internet IPv6 possui suporte do protocolo L2TP/IPsec no Windows Vista e no Windows Server 2008, e do protocolo SSTP no Windows Vista SP1 e no Windows Server 2008. Para conexões VPN de site para site, o tráfego IPv6 nativo na Internet IPv6 possui suporte do protocolo L2TP/IPsec no Windows Server 2008.

Conclusão
A Figura 7 mostra os quatro métodos de envio de tráfego IPv6 em conexões VPN e o suporte no Windows para os dois tipos diferentes de conexões VPN. Em resumo, se você estiver usando uma tecnologia de transição IPv6 como ISATAP na sua intranet, poderá enviar tráfego IPv6 via IPv4 em conexões VPN nas Internets IPv4 e IPv6. Se a sua intranet oferecer suporte à conectividade IPv6 nativa, você poderá enviar tráfego IPv6 nativo em conexões VPN nas Internets IPv4 e IPv6 com o Windows Vista e o Windows Server 2008.
Figure 7 Suporte para tráfego IPv6 em conexões VPN no Windows (Close Figure 7)

Método de envio de tráfego IPv6 | Conexões VPN de acesso remoto | Conexões VPN de site para site
Tráfego IPv6 via IPv4 na Internet IPv4 | PPTP e L2TP/IPsec no Windows Vista, no Windows Server 2008, Windows XP SP1 (ou superior) e no Windows Server 2003; SSTP no Windows Vista SP1 e no Windows Server 2008 | PPTP e L2TP/IPsec no Windows Server 2008 e no Windows Server 2003
Tráfego IPv6 nativo na Internet IPv4 | PPTP e L2TP/IPsec no Windows Vista e no Windows Server 2008; SSTP no Windows Vista SP1 e no Windows Server 2008 | PPTP e L2TP/IPsec no Windows Server 2008
Tráfego IPv6 via IPv4 na Internet IPv6 | L2TP/IPsec no Windows Vista e no Windows Server 2008; SSTP no Windows Vista SP1 e no Windows Server 2008 | L2TP/IPsec no Windows Server 2008
Tráfego IPv6 nativo na Internet IPv6 | L2TP/IPsec no Windows Vista e no Windows Server 2008; SSTP no Windows Vista SP1 e no Windows Server 2008 | L2TP/IPsec no Windows Server 2008

Joseph Davies é redator técnico da Microsoft e vem ensinando e escrevendo sobre assuntos relacionados a sistemas de rede do Windows desde 1992. Ele escreveu cinco livros para a Microsoft Press e é autor da coluna mensal online Cable Guy da TechNet.


 Windows PowerShell: Repensando o pipeline
Windows PowerShell
Repensando o pipeline
Don Jones

Muito já se falou sobre o quanto o Windows PowerShell é diferente, novo e interessante, no entanto, ele se baseia em conceitos de interface de linha de comando que existem há décadas, basicamente em sistemas operacionais baseados no UNIX e no Linux. Na verdade, a terminologia comum que compartilha com seus antecedentes pode
esconder a real flexibilidade e exclusividade do Windows PowerShell™ e sua conhecida eficiência em um ambiente Windows®.
Um dos recursos mais discutidos do Windows PowerShell é seu pipeline, mas, infelizmente, ele também é um dos mais incompreendidos. Isso porque depende de uma terminologia definida no início da década de 70, que então representava uma funcionalidade totalmente diferente e menos eficiente.

A origem dos pipes
Um dos primeiros shells do UNIX já criados foi o Thompson, que era muito primitivo e apresentava apenas os elementos mais básicos de linguagem de script sem nenhuma variável. O shell tinha um design deliberadamente modesto, já que seu único propósito era executar programas. Entretanto, ele introduziu um conceito-chave que foi aprimorado em outros shells daquela época: os pipes. Usando os símbolos < e >, o shell podia ser instruído a redirecionar a entrada e a saída para diferentes comandos, e a partir deles. O usuário agora era capaz de, por exemplo, redirecionar a saída do comando para um arquivo.
Essa sintaxe foi posteriormente expandida de forma que a saída de um comando também pudesse ser transportada via pipe para a entrada de outro comando, permitindo que longas seqüências de comandos fossem encadeadas para realizar tarefas mais complicadas. Na versão 4 do shell, o caractere de linha vertical "|" foi adotado em pipes e, assim, tornou-se conhecido como o caractere de pipe. Mesmo as primeiras versões do MS-DOS® implementavam pipes básicos por meio desses caracteres, permitindo ao usuário, por exemplo, transportar via pipe a saída do comando type para a entrada do comando more, criando uma exibição de uma página por vez para arquivos de texto longo.
Embora o shell Thompson fosse considerado totalmente inadequado na época do lançamento da versão 6 do UNIX em 1975, o conceito de pipes foi muito bem assimilado pelos desenvolvedores e usuários de shell e transmitido para diversas tecnologias empregadas atualmente.

Pipes de texto
Uma limitação de quase todos os shells é sua natureza essencialmente baseada em texto. Nos sistemas operacionais baseados em UNIX, isso não representa uma limitação, mas um reflexo do funcionamento do sistema. Quase todos os recursos no UNIX podem ser traduzidos como algum tipo um arquivo e, por isso, a possibilidade de transportar texto via pipe de um comando para outro proporciona uma grande capacidade e flexibilidade.
O texto, porém, é realmente uma limitação quando se trata de informações de gerenciamento. Por exemplo, se eu lhe apresentasse uma lista de serviços executados em um computador Windows, certamente você entenderia. Eu poderia colocar o nome do serviço na primeira coluna e seu modo de inicialização na segunda. Seu poderoso cérebro entenderia ou traduziria, com transparência e rapidez, a exibição do texto como informações importantes com as quais você poderia trabalhar. Entretanto, os computadores não são tão inteligentes assim; para que um computador fizesse algo significativo com essa lista, seria necessário dizer-lhe, talvez, que a primeira coluna consiste nos caracteres de 1 a 20, que os caracteres de 22 a 40 formam a segunda coluna e assim por diante.
Há séculos, esse tipo de análise de arquivo de texto era o único meio que os administradores tinham de encadear vários comandos. Na verdade, linguagens de script como VBScript e Perl são excelentes na manipulação de cadeia de caracteres, basicamente porque precisam aceitar a saída de texto de um programa ou comando e depois analisá-la como algum tipo de dado útil que possa ser usado em uma tarefa subseqüente. Já escrevi trabalhos em VBScript, por exemplo, que aceitavam a saída de texto do comando Dir, analisavam a saída de nomes e datas de arquivo e movia os arquivos antigos, não utilizados, para um local de arquivo morto. A análise de cadeias de caracteres é bastante perigosa, pois quase sempre ocorrem exceções, ou variações nos dados de entrada, que exigem uma correção na lógica para resolver todas as possíveis permutações.
Como forma de automação ou script administrativo em um ambiente Windows, a análise de cadeia de caracteres não é muito útil. Isso porque o Windows em si não armazena muita informação em um formato de texto de fácil acesso. Em vez disso, ele usa armazenamentos datacêntricos, como o Active Directory®, o registro do Windows e o armazenamento de certificados, de forma que os criadores de script tenham de usar primeiro uma ferramenta para gerar algum tipo de saída de texto e, em seguida, um script para analisar o texto e fazer algo com ele.

Os objetos são mais fáceis
Os desenvolvedores de software do Windows sempre facilitaram um pouco as coisas. A princípio, a Microsoft desenvolveu o COM especificamente para representar o complexo funcionamento do Windows de forma mais fácil. Hoje, o Microsoft® .NET Framework realiza a mesma tarefa: ele representa o funcionamento interno do software de maneira padronizada.
Em geral, tanto o COM quanto o .NET expõem os itens como objetos. (Um desenvolvedor de software poderia protestar contra essa simplificação, mas, em nome de nossa discussão, um termo simples é o suficiente.) Todos esses objetos possuem vários tipos de membros. Para o nosso propósito, as propriedades e os métodos dos objetos são o que mais interessa. Basicamente, uma propriedade descreve de alguma forma um objeto, modifica-o ou altera seu comportamento. Por exemplo, um objeto de serviço possui uma propriedade que contém o nome do serviço e outra que contém seu modo de inicialização. Os métodos fazem o objeto realizar uma ação. Um objeto de serviço possui métodos chamados Stop, Start, Pause e Resume, por exemplo, representando as diversas ações que você pode executar em um serviço.
Da perspectiva da programação, ou criação de scripts, os membros de um objeto são referenciados por meio de uma notação pontuada. Os objetos são, em geral, atribuídos a variáveis, que fornecem uma maneira de manipulá-los fisicamente. Por exemplo, se um serviço estiver atribuído à variável $service, poderei interrompê-lo usando a sintaxe $service.Stop. Ou poderei recuperar o nome de exibição do serviço usando $service.Name.

Objetos no pipe
Como o Windows é um sistema operacional amplo e complexo, e como não armazena seus dados de gerenciamento em representações ao estilo de texto, as técnicas de shell mais antigas, infelizmente, não são adequadas. Por exemplo, suponha que eu tenha uma ferramenta de linha de comando chamada SvcList.exe, que produz uma lista formatada de serviços e seus modos de inicialização. No shell de linha de comando do Windows, que seguramente nasceu do antigo shell do MS-DOS, eu poderia executar algo como:
SvcList.exe | MyScript.vbs
Essa instrução recupera uma lista de serviços e a transporta via pipe para um arquivo VBScript. Eu teria de escrever o arquivo VBScript de forma que analisasse a lista formatada e fizesse o pretendido, por exemplo, definir a saída de qualquer serviço com um modo de inicialização Disabled. Essa tarefa levaria muito tempo. Na verdade, o problema é que SvcList.exe possui uma saída exclusiva; ela não compartilha um formato comum que outros comandos possam consumir facilmente ao usar sua saída.
Os objetos, porém, podem fornecer esse formato comum, e é por isso que o pipeline do Windows PowerShell funciona com objetos inteiros, e não apenas texto. Ao executar um cmdlet como Get-WMIObject, você produz um grupo (ou coleção, na linguagem de programador) de objetos. Cada objeto vem completo com propriedades e métodos que permitem manipulá-lo. Se eu transportar via pipe objetos para o cmdlet Where-Object, poderei filtrá-los de forma que apenas os objetos que eu desejar sejam exibidos. Where-Object não precisa analisar nenhum texto porque não é texto que ele está recebendo, mas objetos. Por exemplo:
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
Ou, se você preferir encurtar a sintaxe disponível por meio de aliases:
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
O interessante é que o Windows PowerShell sempre passa objetos pelo pipeline. Somente no fim do pipeline, quando não restam mais lugares para os quais passar objetos, o shell gera uma representação de texto dos objetos usando regras de formatação internas. Por exemplo, considere o seguinte:
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
Esse conjunto de três cmdlets recupera todos os serviços do meu computador local, filtra os que não usam a conta LocalSystem para fazer logon e passa o restante para o cmdlet Select-Object, que emite apenas as duas propriedades, Name e StartMode, que eu o instruí a selecionar. O resultado é um relatório simples de serviços que fazem logon como LocalSystem (talvez para fins de auditoria de segurança).
Como possuem o mesmo formato de dados — objetos —, todos os cdmlets podem compartilhar dados entre si sem qualquer análise complicada de cadeia de caracteres. E como o Windows PowerShell possui uma capacidade nativa de criar uma representação de texto de um objeto, o fim desse pipe, certamente, será uma saída de texto legível. A Figura 1 mostra um exemplo da saída gerada.
Figura 1 Saída de texto gerada por uma série de cmdlets em pipe que passam pelos objetos
Figura 1 Saída de texto gerada por uma série de cmdlets em pipe que passam pelos objetos

O atrativo dos pipes
O que torna os pipes tão incríveis no Windows PowerShell é que tudo no Windows PowerShell é um objeto completo, com propriedades e métodos que podem ser usados. Mesmo um arquivo de texto é, tecnicamente, uma coleção de objetos de cadeia de caracteres, em que cada linha do arquivo funciona como um objeto de cadeia de caracteres exclusivo e independente. Por exemplo, crie um arquivo de texto (usando o Bloco de Notas) chamado C:\Computers.txt. Preencha o arquivo com texto e execute o seguinte no Windows PowerShell:
Get-Content C:\Computers.txt | Select-Object Length | Format-List
Ou, novamente, se preferir menos digitação, use aliases:
gc C:\Computers.txt | select Length | fl
Esse código fornece uma lista que indica o comprimento de cada linha do arquivo de texto, em caracteres. Get-Content recupera os objetos da cadeia de caracteres do arquivo, Select-Object captura a propriedade Length de cada um deles e Format-List cria uma saída de texto boa e legível. Embora talvez não seja muito prática, essa ferramenta administrativa ilustra que mesmo as coisas mais simples, como uma linha de texto, são objetos no Windows PowerShell.
A capacidade de transportar objetos via pipe de um cmdlet para outro, ou para um script, confere à criação todo o poder que uma linha pode ter. São cadeias de caracteres simples de cmdlets anexadas a um longo pipeline, que refina ainda mais um conjunto de objetos para produzir exatamente o que você deseja. Praticamente sem nenhum tipo de script ou programação, os cmdlets do Windows PowerShell, encadeados em um pipeline apropriado, podem obter resultados incríveis.

Oferecendo suporte às gerações futuras
O fato de que os futuros produtos de servidor da Microsoft também estejam sendo criados no Windows PowerShell amplia essa funcionalidade. Ao implementar um novo computador com Exchange Server 2007, por exemplo, você pode usar o Windows PowerShell para recuperar todas as caixas de correio, separar todas as que não forem do escritório em que o novo servidor de email estará localizado e mover as outras para o novo servidor, tudo em uma única linha de texto sem scripts. A equipe do Exchange Server 2007 publicou uma longa lista dessas poderosas linhas. Isso mostra o verdadeiro poder do pipeline e as tarefas administrativas que ele é capaz de realizar.
O truque com o Windows PowerShell é entender que, embora ele se baseie em filosofias e princípios antigos do universo do UNIX, essa nova ferramenta é especialmente adequada para a administração do Windows. Não se deixe enganar pela trivialidade da terminologia achando que o Windows PowerShell é apenas uma cópia do shell do UNIX para o Windows. O Windows PowerShell contém conceitos inteiramente novos que tiram proveito da plataforma Windows e está intimamente ligado ao jeito Windows de fazer as coisas.

Don Jones é MVP do Windows PowerShell e autor de Windows PowerShell 101 (ScriptingTraining.com). Você pode entrar em contato com Don em www.ScriptingAnswers.com.


 Ei, Equipe de Scripts!: Nos scripts, assim como na vida, a apar&#234;ncia &#233; muito importante
Ei, Equipe de Scripts!
Nos scripts, assim como na vida, a aparência é muito importante
A Equipe de Scripts da Microsoft

Por centenas, e talvez milhares, de anos, filósofos e sábios vêm nos dizendo que devemos observar além da aparência física quando julgamos algo ou alguém (não que devamos julgar as pessoas, imagine; afinal de contas, a beleza está nos olhos de quem a vê). Você sabe o que dizem por aí: a verdadeira beleza vem de dentro e o seu caráter é muito mais importante do que a sua beleza.
A Equipe de Scripts só tem uma coisa a adicionar: besteira.
É isso mesmo: besteira. A Equipe de Scripts é a primeira a admitir que, em um mundo perfeito, a aparência física não faria a menor diferença. No entanto, nós não vivemos em um mundo perfeito. Se vivêssemos, as batatas fritas e os sundaes com calda de chocolate quente estariam entre os principais grupos alimentares. Queira você ou não, a aparência é importante. E isso se aplica tanto à criação de scripts quanto a qualquer outra coisa.
A Equipe de Scripts sabe que algumas pessoas são levadas às lágrimas por causa da beleza simples de um script VBScript executado em uma janela de comando (bem, talvez isso aconteça com um de nossos membros, Guy Dean Tsaltas, mas ele é o único de quem nos lembramos).
Por outro lado, também é verdade que, neste nosso mundo de alta tecnologia, os autores de scripts não estão mais limitados a escrevê-los para execução em uma janela de comando. Graças aos HTAs (Aplicativos HTML), os autores de scripts podem chamar o poder do DHTML para criar GUIs para seus scripts. Essas mesmas habilidades do HTML podem ser usadas na criação de gadgets do Windows Vista™, algo novo que tem o potencial de revolucionar os scripts de administração do sistema como o conhecemos hoje. Mas sabe de uma coisa? Assim que você começa a falar sobre GUIs, algumas noções antigas e ultrapassadas sobre beleza superficial aparecem imediatamente. Para scripts executados em um ambiente gráfico, a aparência é tão importante quando a função e o desempenho.
E esse é o problema. Afinal, nós escrevemos scripts, o que sabemos sobre a criação de interfaces gráficas de usuário? Parece que não estamos com sorte, não é?
Talvez. Ou, quem sabe, talvez não. Será que ouvimos alguém dizer: "Meu Deus, obrigado pela Equipe de Scripts?"
Fala sério. Será que não acabamos de ouvir alguém dizendo isso? Talvez tenham balbuciado ou dito um pouco baixo...
Bem, não importa. Alguém deve ter dito isso, já que a Equipe de Scripts está aqui para ajudar (queira você a nossa ajuda ou não).
Para apresentar o magnífico mundo das GUIs para você, vamos dar uma olhada nos primórdios de um HTA pequeno e simples (se quiser obter mais informações sobre a criação de HTAs, consulte o Centro de desenvolvedores de HTA).
O que temos na Figura 1 é a primeira parte de um belo sistema de informações de desktop. Como você pode ver, começamos pela colocação de um pequeno gráfico interessante no canto superior direito da janela do HTA. A idéia é que, na primeira vez em que o HTA é carregado, ele irá recuperar o nome do usuário conectado e o exibirá, além do nome do computador, acima dessa imagem. Mais adiante, adicionaremos outros tipos de recursos bacanas ao HTA mas, como dizem, primeiro o mais importante.
Figura 1 O início da nossa interface gráfica adorável para o HTA
Figura 1 O início da nossa interface gráfica adorável para o HTA
Não, não temos muita certeza de quem está por trás do "dizem". Provavelmente outro daqueles filósofos. Voltaire, provavelmente. Isso se parece com algo que Voltaire poderia ter dito.
Certo, esse é somente um pequeno aplicativo simples e a sua... beleza... pode não comover nem mesmo o Dean da Equipe de Scripts. Mas ele serve como uma ferramenta de demonstração muito útil, com um conceito básico que pode ser aplicado em muitas situações diferentes. Afinal, muitos daqueles gadgets superestimados do Windows Vista funcionam de acordo com um princípio similar; eles simplesmente exibem gráficos bonitos (digamos, um medidor ou um mostrador de relógio) e então escrevem um texto sobre esse gráfico. Com isso, parece que você tem um pequeno medidor bacana que exibe o espaço disponível em disco, quando, na verdade, tudo o que tem é um gráfico genérico com um texto dinâmico por cima.
Tudo bem, para dizer a verdade, isso também não faz muito sentido para nós. Mas tudo deve ficar mais claro à medida que formos avançando nesta coluna.
Só existe um problema com a noção de que podemos exibir um gráfico e escrever um texto sobre ele: não funciona. Em vez disso, com a marcação HTML básica, podemos obter algo como a Figura 2. Não é exatamente isso que tínhamos em mente. Talvez Nietzsche, quando disse "não há esperança para os humanos que desejam colocar texto sobre um gráfico, pelo menos não em um HTA", estivesse certo.
Figura 2 Uma primeira tentativa de sobrepor o texto
Figura 2 Uma primeira tentativa de sobrepor o texto
Ou talvez Nietzsche estivesse errado: nós não acabamos de ouvir alguém dizendo... Bem, deixa para lá. Acontece que não conseguimos fazer o que queremos usando o HTML simples; simplesmente não funciona dessa forma. É claro que, teoricamente, poderíamos transformar o nosso gráfico em um gráfico de plano de fundo e então usar tabelas e espaços sem quebra e todos os tipos de pequenos truques para tentar colocar o texto sobre a imagem. Mas dissemos "teoricamente" por um bom motivo; exceto no mais simples dos casos, essa estratégia nunca funciona.
Existe uma forma muito melhor de criar layouts bonitos em um HTA ou em um gadget do Windows Vista: Cascading Style Sheets, também conhecidas como CSS.
As CSS são usadas na definição das fontes, das margens e alinhamentos, das cores e de outros aspectos da apresentação de um documento (particularmente, isso se aplica a páginas da Web. No entanto, como os HTAs e os gadgets no fundo são nada mais do que páginas da Web, as CSS também se aplicam bem a eles). Não podemos nem começar a discutir tudo o que podemos fazer com CSS e, portanto, para obter mais informações, talvez seja melhor consultar a documentação de referência das CSS no MSDN®, muito útil e completa. Por ora, é suficiente dizer que podemos usar as CSS para controlar minuciosamente o layout do HTA, incluindo a capacidade de colocar um item (o nosso texto) sobre outro (o nosso gráfico).
Explicaremos como fazemos tudo isso. Mas antes da explicação, vamos examinar o código de um HTA simples, mostrado na Figura 3.
Figure 3 Finalmente, chegamos ao script... (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
Como você pode ver, não há mesmo nada complicado. Temos uma sub-rotina Window_Onload que (como seu nome já diz) é automaticamente executada sempre que o HTA é iniciado ou atualizado. Falaremos sobre essa sub-rotina em um minuto. Além disso, temos dois elementos HTML: o nosso gráfico e uma marca span. Como você já deve saber, usamos um pouco de marcação para inserir o gráfico, usando o atributo align para garantir que a imagem apareça no lado direito da tela:
<img src=”test2.jpg” align=”right”>
Isso nos traz até a marcação HTML para uma marca span:
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
Tá, então usamos uma marca span aqui. Mas que diabos é uma marca span? Bem, para todos os efeitos, uma marca span é simplesmente uma área nomeada do seu HTA; é uma seção "marcada" da janela do HTA que podemos identificar por meio de programação (principalmente porque demos a ela a identificação UserData). Depois da configuração da marca span, podemos escrever uma sub-rotina para atribuir o texto ou a codificação HTML a ele. Na verdade, não só podemos fazer isso como já o fizemos em nosso HTA.
Mas, como dissemos, falaremos sobre isso mais tarde. Antes, precisamos verificar o parâmetro style adicionado à marca span:
style=”position:absolute;left:770px;top:150px”
Esse parâmetro, como você poderia suspeitar, é a chave para o posicionamento bem-sucedido do nosso texto dinâmico sobre o gráfico. Na verdade, estamos especificando três atributos style separados aqui.
Position Dissemos ao nosso HTA que queremos que a posição do nossa marca span seja, bem, absoluta. Essencialmente, isso quer dizer que queremos que a marca span fique sempre no mesmo lugar, mesmo que isso signifique — e, neste caso, significa — que o texto tenha de ser escrito sobre outro item (como, por exemplo, outro gráfico).
Left Simplesmente especifica a posição da marca span relativa à extremidade esquerda da janela do HTA. Neste caso, queremos que a marca span comece em 770 pixels (770px) a partir da esquerda.
Top Essa configuração é muito similar ao atributo Left, exceto pelo fato de que, desta vez, estamos especificando a posição da marca span relativa à extremidade superior da janela do HTA. Neste caso, queremos começar no topo da janela e contar 150 pixels (150px) para baixo antes de começar a marca span.
Como sabíamos que devíamos definir o lado esquerdo da nossa marca span como 770 pixels e o lado superior como 150 pixels? Para falar a verdade, não sabíamos. Em vez disso, nós fizemos uma suposição; colocamos o gráfico na página e atribuímos valores aos atributos Left e Top da marca span. Em seguida, abrimos o HTA e verificamos os resultados. Como você poderia esperar, erramos por pouco e, portanto, ajustamos os valores, atualizamos o HTA e verificamos novamente. Fizemos isso algumas vezes até que, assim como Cachinhos Dourados, encontramos algo que nos servia.
Observação: claro que você conhece Cachinhos Dourados e os três ursos, suas camas e cadeiras, o mingau que estava muito quente ou o que estava muito frio e assim por diante. E não, não temos certeza se Cachinhos Dourados poderia ser considerada uma grande filósofa. Mas você poderia argumentar que, vendo como ela não teve problema algum para invadir a casa de outra pessoa, comer seu mingau, sentar em suas cadeiras e dormir em suas camas, ela definitivamente tinha uma filosofia própria.
Seja como for, a Figura 4 mostra a aparência atual do HTA. Certo, talvez não seja uma obra de arte, mas gostaríamos de ver Picasso exibir informações programaticamente sobre um gráfico.
Figura 4 Observe o poder do estilo
Figura 4 Observe o poder do estilo
Falando nisso, como podemos exibir informações programaticamente sobre um gráfico? Bem, temos boas notícias para você: finalmente chegou a hora de falarmos sobre a nossa sub-rotina Window_OnLoad, mostrada na Figura 5.
Figure 5 A sub-rotina Window_OnLoad (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub
Você sabe, agora que olhamos para essa sub-rotina um pouco mais de perto, vemos que não há muito que falar sobre ela, não é mesmo? Como você pode ver, começamos pela criação de uma instância do objeto Wscript.Network. Em seguida, usamos essas linhas de código para recuperarmos o nome de usuário, o domínio e o nome do computador:
strUser = objNetwork.UserDomain & “\” & _
 objNetwork.UserName
strComputer= objNetwork.ComputerName
É claro que essas informações são aquelas que queremos exibir na janela do nosso HTA. Tudo o que precisamos fazer é combinar as variáveis strUser e strComputer a um pouco de marcação HTML e depois atribuir a cadeia de caracteres resultante à propriedade InnerHTML da sua marca span:
UserData.InnerHTML = _
 “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” _
 & strUser & “<br>” & strComputer & _
 “</font></p>”
Sim, sabemos que esse código parece complicado. Mas, na verdade, não é tão ruim assim. Parece complicado porque estamos combinando vários itens em uma única cadeia de caracteres. Começamos pela marca de parágrafo de abertura, que especifica que queremos centralizar o texto no parágrafo.
“<p align = ‘center’> “
Em seguida, temos uma marca font de abertura, que especifica a utilização de texto de 18 pontos branco:
“<font style=’font-size:18pt;color:white’>”
strUser é a variável que armazena o nosso nome de usuário, no formato Domínio\NomedeUsuário. "<br>" insere uma quebra de linha. Nós o inserimos para que o nome de usuário seja exibido em uma linha e o nome do computador em outra. strComputer é a variável que armazena o nome do nosso computador. Finalmente, adicionamos as marcas font e paragraph de fechamento:
“</font></p>”
Quando examinamos as partes individualmente, podemos ver que o código não é nem um pouco complicado, como você poderia esperar.
Casualmente, você pode posicionar quase todos os elementos HTML que quiser. Por exemplo, suponha que você queira centralizar um botão abaixo do gráfico. Para isso, basta adicionar este código ao seu HTA:
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
O resultado deve ser um HTA como o da Figura 6.
Figura 6 Que botão adorável
Figura 6 Que botão adorável
Novamente, você terá de brincar um pouco para fazer com que o botão seja posicionado no lugar certo, mas isso não deve demorar muito. Na verdade, se você estiver disposto a fazer os cálculos, provavelmente conseguirá determinar o posicionamento correto antes do tempo. Você só precisa conhecer a largura e a altura de cada objeto — algo que você consegue especificar usando o parâmetro style — e a largura e a altura da janela do HTA. Por padrão, pelo menos no computador de testes da Equipe de Scripts, os HTAs têm, aproximadamente, 1020 pixels de largura por 685 pixels de altura (é claro que os resultados podem variar). No mínimo, você pode começar com aqueles números e, em seguida, ajustá-los para que atendam às suas necessidades.
Obviamente, essa é uma introdução muito breve às CSS, mas deve ajudá-lo a começar a trilhar o caminho para scripts mais bonitos. Os filósofos podem desprezar esse trabalho e dizer a você que a verdadeira beleza de um script vem de dentro e não de fora. Mas veja desta forma: quem são os maiores filósofos de todos os tempos? É isso mesmo: Platão, Sócrates, Aristóteles, esses caras. Com isso em mente, gostaríamos de fazer uma pergunta: você já viu alguma fotografia de qualquer um desses filósofos? Você não acha interessante o fato de que não há fotos das pessoas que dizem que a beleza não importa? Isso não lhe parece estranho? Algo em que devemos pensar.

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


 Perguntas e respostas do Exchange: Fun&#231;&#245;es de Transporte de Borda e Transporte de Hub, m&#225;quinas virtuais e muito mais
Perguntas e respostas do Exchange
Funções de Transporte de Borda e Transporte de Hub, máquinas virtuais e muito mais
KC Lemson and Nino Bilic

Na edição de maio de 2007 do Perguntas e respostas do Exchange, falamos sobre os problemas de armazenamento de arquivos .pst em compartilhamentos de rede. A equipe de desempenho do Windows Server acabou de criar um blog para discutir
esse tópico em seus mais variados detalhes técnicos e, portanto, gostaríamos de repassar o link. E, agora, vamos às perguntas.

P Sou obrigado a implantar a função de servidor de Borda se quiser implantar o Microsoft Exchange Server 2007?

R Não, você não é obrigado a implantar a função de servidor de Borda para implantar o Exchange Server 2007. É possível haver uma única máquina executando as principais funções de servidor (como a caixa de correio, o acesso para cliente e o transporte de hub), aceitando emails vindos da Internet para o seu domínio e executando programas anti-spam e antivírus.

P Quais são as diferenças entre as funções de servidor de Borda e de Hub? O que vou perder se não implantar a função de Borda?

R A principal finalidade da função de Hub é rotear a correspondência dentro da organização e aplicar diretivas de negócios a essas mensagens. Com ela, as regras de transporte se baseiam em objetos do Active Directory® — usuários, listas de distribuição e assim por diante. A função de Hub também permite que você adicione avisos de isenção a mensagens ou registre mensagens enviadas a grupos de usuários, uma vez que, provavelmente, as regras se basearão na associação ao Active Directory. Por exemplo, talvez você queira registrar todas as mensagens enviadas para DLOfUsersOnLitigationHold ou adicionar avisos de isenção à correspondência de saída enviada por DLOfMembersOfLegalTeam. Embora seja possível executar agentes anti-spam no servidor de Hub, eles não são ativados por padrão e, portanto, você precisará instalá-los manualmente ao executar o script install-antispamagents, disponível no diretório \scripts do servidor.
A principal finalidade da função de Borda é rotear correspondências para dentro e para fora da organização, além de executar a higienização das mensagens (anti-spam, antivírus, filtragem de conteúdo ou de anexos, entre outros). A funcionalidade anti-spam é ativada na instalação de um servidor de Borda. Um dos recursos exclusivos da função de Borda é que não há requisitos para incorporá-la a um domínio do Windows® — ela pode ser executada em uma instalação autônoma do Windows Server® que não faça parte de um domínio do Windows e, ainda assim, ser gerenciada como parte da organização do Exchange 2007 em sua floresta corporativa.
Isso é particularmente vantajoso em uma rede de perímetro onde talvez você queira que o servidor esteja em um grupo de trabalho ou onde talvez haja uma floresta explicitamente separada para máquinas da rede de perímetro. Convenientemente, os servidores de Borda implantados nessa situação podem executar toda a higienização e roteamento de mensagens entre a rede corporativa e a Internet e, ainda assim, ser gerenciados de uma forma consistente com a administração dos outros sistemas do Exchange 2007.
Em um servidor de Borda, as regras de transporte se baseiam em endereços SMTP e não em objetos do Active Directory — mas é claro que você poderá usar os endereços SMTP de DLs ou de usuários do seu Active Directory. Em sua grande maioria, as regras de transporte de Borda são um subconjunto das regras de transporte de Hub, exceto pela ação de quarentena, que só está disponível nos servidores de Borda.
Os servidores de Borda também têm alguma funcionalidade exposta por meio de agentes não disponíveis no servidor de transporte de Hub: a remoção de anexos e a regravação de endereço. A remoção de anexos é a capacidade de remoção seletiva de anexos potencialmente perigosos, com extensões como .exe e .com. O agente de regravação de endereço permite que você reescreva os cabeçalhos de emails para que, embora os endereços do seu domínio e do proxy SMTP padrão de contas de usuário sejam @contoso.com, por exemplo, as mensagens de saída para a Internet exibam @northwindtraders.com. Além disso, os servidores de Borda só executam o roteamento com base em espaço de domínio ou de endereço e, se você compartilha o mesmo espaço de endereço SMTP entre o Exchange e outro sistema de email, precisará executar esse roteamento no servidor de Hub ou fazê-lo em conjunto com o agente de regravação de endereço no servidor de Borda.
Outra consideração importante é se o servidor Exchange 2007 terá ou não acesso direto à Internet (tenha ele a função de servidor de Hub ou de Borda). Em outras palavras, as conexões à porta 25 do registro MX do seu domínio estão ligadas ao Exchange 2007 de alguma forma? Talvez você já tenha um gateway SMTP, um antivírus ou outra solução na Internet que esteja aceitando correspondência para o seu domínio e repassando-a para o Exchange em sua rede corporativa interna. Se você implantar os servidores de Borda ou de Hub com acesso direto à Internet, poderá aproveitar um dos recursos mais interessantes do Exchange 2007: a agregação de lista segura. Com a agregação de lista segura, os usuários que adicionarem remetentes às suas listas seguras no Microsoft Outlook® (o que normalmente fazem para boletins informativos da Internet ou para emails de fornecedores) terão suas listas propagadas com segurança para as funções de Borda e de Hub, de forma que as mensagens desses remetentes ignorem a filtragem de conteúdo. É claro que o que é spam para um usuário pode ser um boletim informativo para outro e, portanto, a agregação de lista segura é feita com base no usuário. Leia mais sobre como isso funciona na documentação do Exchange 2007.
Se você terminou com uma implantação em que um servidor com a função de Hub está aceitando emails da Internet para o seu domínio, existem algumas coisas que deve saber. É claro que primeiro você deve possuir um bom firewall ou uma solução de filtragem de portas para que o servidor só esteja recebendo conexões nas portas necessárias, como a 25. Lembre-se também de que é necessário instalar os agentes anti-spam, uma vez que eles não são instalados ou ativados por padrão. Como o cenário de implantação mais comum para o servidor de Hub é a rede corporativa, ele não permite conexões anônimas por padrão — será preciso marcar o grupo de permissões AnonymousUsers no conector de recepção da porta 25. Também será necessário garantir a ativação da agregação de lista segura e a programação de sua execução periódica, para que quando os usuários atualizarem as listas seguras em suas caixas de correio, as mensagens enviadas aos usuários de sua lista de remetentes seguros ignorem a filtragem de conteúdo. Obtenha mais detalhes em nosso blog.
O código a seguir mostra um comando AT que atualiza todas as caixas de correio de todos os servidores diariamente, às 23:00h, usando um arquivo em lotes chamado SafeList.bat:
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
Este código mostra o conteúdo do arquivo SafeList.bat:
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
Caso seja necessário verificar se as suas configurações estão funcionando adequadamente, obtenha mais informações na documentação do Exchange 2007.

P Depois de reinicializar a imagem do meu Virtual PC que contém o Exchange, tenho tido problemas em entrar em contato com o diretório ou o servidor LDAP. O Telnet na porta 389 funciona e todos os serviços estão em execução. Por que isso acontece?

R Tive o mesmo problema na Tech•Ed do ano passado. Eu tinha uma cópia de um Virtual PC em meu laptop, feita de uma máquina no trabalho, e estava planejando usá-la em demonstrações para membros da imprensa que estivessem publicando artigos sobre o lançamento do Exchange 2007 Beta 2, no mês seguinte.
Fiz milhões de demonstrações do produto e sabia que a compilação estava sólida e, portanto, não me preparei muito. Você pode imaginar o meu nervosismo quando eu reiniciei o meu Virtual PC na segunda pela manhã, algumas horas antes da primeira reunião, e todas as partes da minha compilação insistiam em dizer que não podiam entrar em contato com um controlador de domínio. Graças ao alto poder de concentração de técnicos muito bem preparados, fomos capazes de descobrir com rapidez o que estava errado.
O problema que tive no desastre da Tech•Ed foi resultado da execução do Virtual PC em meu laptop superlento. Acima de tudo, havia uma condição de concorrência entre o DNS e o Active Directory. O servidor DNS da imagem estava configurado para se integrar ao Active Directory, mas, devido à seqüência em que os servidos da imagens eram carregados (e à, digamos, falta de potência do meu laptop), os serviços de diretório necessários ainda não haviam iniciado quando o servidor DNS tentava entrar em contato com o Active Directory.
Essa situação pode acontecer em qualquer servidor que possua um DC e o Exchange na mesma máquina (não precisa ser uma imagem virtual), mas é muito mais provável que ocorra em um ambiente virtual onde haja uma lentidão extra — particularmente em um laptop não tão robusto quanto o meu.
Também tive um problema similar com imagens do Virtual PC copiadas entre duas máquinas, especialmente quando uma das máquinas estava em uma rede diferente. Se isso acontecer com você, verifique o endereço IP do sistema operacional da imagem; o sistema operacional pode ter mantido o endereço IP da antiga rede. Atualize-o para obter um IP da nova rede e veja se isso ajuda.
Para evitar esses tipos de problemas no futuro, uma opção seria fazer com que o servidor DNS no convidado não estivesse integrado ao Active Directory, assim como instalar o DNS tanto no host como no convidado. Faça com que o convidado encaminhe para o host os registros desconhecidos e com que o host também os encaminhe para seu servidor DNS apropriado. Quando a sua imagem for reinicializada e tentar atualizar os registros de DNS, estará menos propensa a falhas.

P Parece que a instalação do Exchange 2007 é um pouco diferente da instalação das versões anteriores do Exchange. Como ela funciona?

R Sim, existem vários estágios de instalação do Exchange 2007. Mostraremos aqui uma visão geral de todo o processo.

Quando você executa o setup.exe pela primeira vez, inicia um processo que mostrará os links para a maioria dos pré-requisitos necessários para a instalação antes que comece a instalar as funções de servidor propriamente ditas. Depois de instalar todos os pré-requisitos, você poderá clicar no link Instalar o Microsoft Exchange (consulte a Figura 1).
Figura 1 Link de instalação disponível depois que todos os pré-requisitos gerais foram atendidos
Figura 1 Link de instalação disponível depois que todos os pré-requisitos gerais foram atendidos
Se você executou o setup.exe a partir da rede e se clicou no link Instalar, os principais arquivos de instalação terão sido copiados para a pasta %TEMP%\ExchangeServerSetup\ de sua máquina local. O assistente para instalação é iniciado.
O assistente para instalação o conduzirá pelas diversas opções, como contrato de licença, relatório de erros e tipo de instalação (onde você escolherá as funções de servidor que deseja instalar). As páginas do assistente variam com base na presença e no estado da organização atual do Exchange (se houver).
Em seguida, a instalação executará uma verificação de preparação — na verdade, uma versão ajustada do BPA (Best Practices Analyzer) do Microsoft Exchange Server que, por padrão, se conectará à Internet para baixar o arquivo XML de pré-requisitos mais recente. Assim, você terá a oportunidade de atualizar os pré-requisitos periodicamente ou de solucionar problemas descobertos pela equipe do Exchange desde o lançamento do produto. Quando a verificação de pré-requisitos estiver completa, você poderá revisar os resultados e continuar; caso contrário, verá os erros que talvez tenham de ser solucionados antes de a instalação prosseguir. Se o seu servidor falhar na verificação de pré-requisitos, na maioria dos casos o assistente permitirá que você a refaça.
Após a verificação dos pré-requisitos, você obterá o botão Instalar para iniciar a instalação das funções escolhidas anteriormente. Somente os arquivos das funções selecionadas serão copiados e instalados.
No final da instalação, você terá a chance de iniciar o Console de Gerenciamento do Exchange e de aplicar quaisquer atualizações que possam estar disponíveis para o Exchange 2007.

KC Lemson é gerente de experiência do usuário do Exchange Server. Sua conta bancária online foi temporariamente suspensa.
Nino Bilic é gerente de programa de suporte para o Exchange Server. Recentemente, ele adicionou um endereço de email secundário ao seu cartão de crédito.


 Security Watch: Ferramentas para gerenciar ACLs
Security Watch
Ferramentas para gerenciar ACLs
Jesper M. Johansson

No Windows, as ACLs (listas de controle de acesso) fornecem um ótimo controle sobre a capacidade de os usuários e os processos usarem recursos como arquivos e pastas. O gerenciamento de ACLs pode ser uma das tarefas mais complicadas relacionadas à proteção da segurança dos sistemas dos usuários. Felizmente, há vários utilitários interessantes
que ajudam a automatizar e simplificar as tarefas envolvidas nas permissões e ACLs.
A maioria dos leitores conhece a antiga ferramenta cacls.exe incluída em todas as versões do Windows NT® desde seu lançamento. Ao executar o cacls.exe no Windows Vista™, você receberá a seguinte mensagem:
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
Além das atualizações para ACLs no Windows Vista (que apresentei na edição de junho de 2007 da TechNet Magazine; consulte technetmagazine.com/issues/ 2007/06), a Microsoft também atualizou algumas ferramentas que são usadas para gerenciar ACLs. Curiosamente, as atualizações mais importantes são ferramentas de linha de comando.
O Icacls.exe é uma novidade no Windows Vista (e também no Windows Server® 2003 Service Pack 2). Ele substituirá o cacls.exe, que, como você deve saber, nunca foi totalmente atualizado para oferecer suporte às permissões mais granulares introduzidas pelo Windows® 2000, o que significa que essa atualização vem com sete anos de atraso.
Excepcionalmente, apesar de ser depreciado, na verdade, o cacls.exe inclui alguns recursos novos. Primeiro, ele reconhece pontos de junção e links simbólicos, e sabe atravessar os dois. Em segundo lugar, pode imprimir e definir uma ACL usando uma cadeia de caracteres SDDL (Security Description Definition Language).
Entretanto, apesar das atualizações do cacls.exe, essa funcionalidade é realmente útil no icacls.exe.

Salvando e restaurando ACLs
Uma funcionalidade muito almejada, pelo menos por mim há 10 anos, é a de salvar uma ACL de forma que seja possível restaurá-la posteriormente. Essa é uma das operações mais complicadas que se pode realizar em ACLs. À exceção de alguns casos, dificilmente se consegue voltar exatamente ao estado em que as ACLs se encontravam antes de serem danificadas. Contudo, essa funcionalidade pode ser bastante útil.
Antes de mostrar como salvar ou restaurar ACLs, primeiro, deixe-me explicar por que isso é tão difícil. Digamos que exista uma hierarquia contendo dados de usuário para alunos de uma faculdade local. Você salva a ACL no dia 1º de fevereiro, mas, no dia 17 de abril, descobre que ela foi corrompida de alguma forma e tenta restaurá-la usando a cópia salva. Quais seriam as complicações dessa operação?
Primeiro, há um novo trimestre que iniciou no dia 2 de abril. Isso significa que aproximadamente 15% dos alunos se formaram e seus diretórios não existem mais. Portanto, existem ACLs no arquivo de backup que são inválidas. Também existe um lote de novos alunos, ou seja, mais 15%, que entraram no novo trimestre. Agora, eles possuem diretórios base (mas não ACLs) no arquivo de backup. Quais seriam suas ACLs? Além disso, é claro, restam os 70% que continuam lá, mas criaram e excluíram arquivos e pastas. Você pode ignorar o que foi excluído, mas como configurar as novas pastas que eles criaram? E se um aluno decidiu compartilhar uma pasta com seus amigos no dia 4 de março? Isso será perdido quando você restaurar a ACL?
Salvar e restaurar ACLs não é uma operação tão simples quanto se imagina. É preciso ter muito cuidado ao trilhar esse caminho. É bem possível, e até muito provável, que você encontre um comportamento inesperado com resultado. Restaurar ACLs, sem dúvida, é o último recurso; quanto mais antigo for o seu backup, maior é a chance de que algo seja perdido na restauração.
No entanto, se você estiver disposto a experimentar esta funcionalidade, execute o icacls.exe com a opção /save:
icacls <target> /save acls.bin /t
Isso salvará as ACLs em um arquivo chamado acls.bin. O arquivo terá uma linha para cada objeto, com uma ACL seguida de uma linha especificando-a no SDDL. Usando a opção /t, o comando funcionará no objeto especificado e em todos os objetos e contêineres abaixo dele.
A funcionalidade save é um acréscimo bem-vindo ao kit de ferramentas, mas possui algumas falhas. Por exemplo, ela salva apenas a DACL (lista de controle de acesso discricionário), e não a SACL (lista de controle de acesso do sistema). Na verdade, se existir uma SACL, ela salvará um valor fictício indicando sua existência, mas não salvará realmente nenhuma parte da SACL.
Além disso, a forma como a ACL é salva cria um problema interessante. Antes de abrir a ACL salva no seu editor de texto favorito, lembre-se:
não edite a ACL salva!
Se tivesse de abrir o arquivo contendo sua ACL salva em um editor de texto, você veria que ela se parece com um UTF-16 (arquivo Unicode de texto formatado). Na verdade, ela é quase isso. Você pode, então, pensar que é possível editá-la e salvá-la em um editor de texto. Mas não faça isso!
Se você abrir o arquivo que contém a ACL salva em um editor de texto e salvá-la, não poderá restaurá-la a partir desse arquivo. Acontece que não se trata realmente de um arquivo de texto Unicode. Esse arquivo deve começar com 0xfffe de 2 bytes. Se você salvar o arquivo com um editor de texto, como o Bloco de Notas, ele colocará esse sinalizador no arquivo, nos primeiros 2 bytes. Entretanto, a ferramenta icacls.exe espera que os dados ACL comecem com 0 byte no arquivo. Conseqüentemente, a ferramenta não poderá analisar as ACLs no arquivo, já que espera que os primeiros dois bytes façam parte da cadeia de caracteres que especifica o objeto a ser operado. Seu arquivo de backup será inútil.
A Microsoft está ciente desse problema, mas, como ele só foi relatado no fim do ciclo beta do Windows Vista, a falha não foi corrigida antes do lançamento. No momento, não sabemos quando, nem se, ela será corrigida. Assim, por enquanto, o melhor conselho é não editar as ACLs salvas. Se precisar fazê-lo, salve o arquivo como .bin e use um editor hexadecimal, como seu ambiente de desenvolvimento favorito.
Depois de salvar uma ACL usando a opção /save, você poderá restaurá-la usando icacls.exe com a opção /restore. O comando restore, em sua forma mais simples, usa esta sintaxe:
icacls <directory> /restore acls.bin
O procedimento restore não funciona em arquivos. Para ver isso, observe a seqüência de comandos mostrada na Figura 1. Nela, criei um arquivo salvo apontando icacls.exe para um arquivo. Depois, tentei restaurá-lo simplesmente substituindo /restore por /save. Isso não deu certo porque o comando restore só funciona em diretórios. Os arquivos que ele deveria modificar já estão especificados no arquivo acls.bin. Para restaurar a ACL, apontei-o para o diretório, em vez do arquivo. Fiz isso no último comando em que especifiquei "." como o objeto a ser operado.
Figure 1 Salvando e restaurando ACLs (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Observe também que o comando restore deve ter execução privilegiada! Você pode executar o comando save de um prompt de comando como administrador com privilégios restritos ou mesmo usuário padrão, contanto que tenha o direito de ler a ACL. Entretanto, para restaurar a ACL, é necessário ter um token administrativo completo, não adulterado.

Substituindo SIDs
Outro recurso que é muito útil no icacls.exe é a capacidade de substituir as permissões de um usuário por outro. Isso é feito durante o restore usando a opção /substitute. A documentação para a opção substitute diz que é preciso um SID, mas depois explica que também pode ser um nome de usuário comum. Portanto, a seqüência mostrada na Figura 2 funciona.
Figure 2 Substituindo SIDs durante a restauração (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
Como você pode ver, terminei com a mesma ACL do início, mas a ACE que antes especificava permissões para foo, agora as especifica para bar.

Alterar proprietário
A ferramenta chown faz parte dos sistemas UNIX há anos. Originalmente, o Windows não possuía um recurso interno para alterar o proprietário de um objeto. Então, apareceu a ferramenta setowner no Resource Kit. Em seguida, introduziu-se a ferramenta takeown.exe no Windows NT 4.0, mas esse utilitário só permitia a apropriação, e não a concessão de propriedade para os outros, a não ser que você tivesse suas senhas. Agora o icacls.exe fornece a capacidade interna de definir o proprietário dos objetos para os quais você tem essa permissão:
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Infelizmente, o icacls.exe não pode mostrar quem é o proprietário de um objeto. Realmente não há como saber, na linha de comando, quem é o proprietário de um objeto. Além disso, se você salva a ACL de um objeto, seu proprietário não é salvo.
Também existe um bug em icacls.exe em que ele não invoca SeTakeOwnershipPrivilege para alterar o proprietário. Se você tiver o direito de alterar o proprietário de um objeto com base na ACL, então icacls.exe funcionará conforme o esperado. Entretanto, se você for administrador, mas não tiver permissão para alterar o proprietário com base na ACL do objeto, não poderá usar icacls.exe para isso por causa desse bug. Neste caso, terá de usar a ferramenta takeown.exe, que invoca SeTakeOwnershipPrivilege, mas poderá alterar apenas o proprietário para a sua conta ou o grupo Administrators, e não uma conta arbitrária:
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Obviamente, deve-se observar que a ferramenta subinacl, que pode ser baixada no Centro de Download da Microsoft, também possui uma opção setowner. A ferramenta subinacl, na verdade, funciona mais intuitivamente do que icacls em muitos casos, mas também é muito mais complicada de usar.

Localizar arquivos para um usuário específico
O Icacls possui outra função útil: ele pode localizar arquivos que possuem permissões para usuários específicos. Por exemplo:
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Isso pode ser útil se você estiver tentando descobrir qual acesso um usuário específico possui.

Redefinindo e alterando ACLs
Se uma ACL for corrompida ou destruída, o icacls.exe possui uma maneira de redefini-la para que seja herdeira de seu pai. Isso deve ser extremamente útil durante um problema de segurança do dia zero, como o que aconteceu no final de 2006. Um método usado para minimizar o problema em um componente do Windows era negar acesso ao objeto para Everyone. Essa parte era fácil, mas remover a ACE (entrada de controle de acesso) era quase impossível usando as ferramentas internas do Windows XP e do Windows Server 2003. Entretanto, no Windows Vista, basta executar este comando:
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
Obviamente, o icacls.exe possui todas as operações padrão grant/deny/remove. O único item realmente novo nessa lista é remove. Usando essa opção, você pode remover todas as ACEs de permissão e todas as ACEs de rejeição para um determinado usuário em uma hierarquia ou em um objeto específico. A Figura 3 mostra exemplos de algumas operações grant, remove e deny diferentes.
Figure 3 Operações grant, deny e remove (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
A capacidade de remover apenas as ACEs de negação pode ser útil se você deseja conceder acesso a um objeto para um grupo ou usuário em particular.

Definindo níveis de integridade
O icacls.exe também possui a capacidade de exibir e definir níveis de integridade. O Windows Vista oferece suporte à rotulagem de níveis de integridade em objetos. O icacls.exe é a ferramenta de linha de comando utilizada para isso:
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
Observe que o icacls.exe só exibirá um rótulo de integridade se um objeto tiver uma definição explícita. A maioria dos arquivos não possui, por isso é raro encontrar um.
Finalmente, o icacls.exe pode verificar se um objeto possui uma ACL canônica. Conforme mencionado anteriormente, em geral, as ferramentas de terceiros colocam as ACEs na ordem errada nas ACLs. O icacls.exe pode verificar e corrigir esse tipo de problema, conforme mostrado aqui:
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

Interface do usuário ACL
A interface do usuário ACL, ou interface ACL, foi ligeiramente modificada após o Windows XP. As Figuras 4 e 5 mostram caixas de diálogo da interface ACL do Windows XP e do Windows Vista, respectivamente.
Figura 4 Caixa de diálogo da interface ACL no Windows XP
Figura 4 Caixa de diálogo da interface ACL no Windows XP
Figura 5 Caixa de diálogo da interface ACL no Windows Vista
Figura 5 Caixa de diálogo da interface ACL no Windows Vista
Como vemos, há poucas alterações. Primeiro, a caixa de diálogo finalmente mostra com clareza em qual objeto você está trabalhando, o que pode ser útil para se trabalhar em vários objetos ao mesmo tempo. Em segundo lugar, existe um hiperlink de ajuda na parte inferior. No entanto, a alteração mais notável é a remoção dos botões Adicionar e Remover, substituídos por um botão Editar que está amplamente presente no suporte do UAC (controle de acesso do usuário) no Windows Vista. Como você pode ver pela blindagem no botão, o usuário que iniciou esse diálogo não possui permissão para editar a ACL e, portanto, requer uma elevação de privilégio para fazê-lo. Observe que isso não seria padrão se você criasse uma pasta na raiz da unidade C: e imediatamente verificasse suas propriedades. Como proprietário da pasta, você teria permissões implícitas para editar a ACL e a blindagem não existiria. A blindagem é um COM Moniker, um mecanismo usado para iniciar um prompt de elevação de privilégio para parte de um processo em execução. Se você clicar no botão Editar, obterá a conhecida caixa de diálogo de elevação de privilégio e, se clicar em Continuar nessa caixa, obterá outra quase idêntica à que é obtida no Windows XP ao clicar no botão Adicionar. A interface ACL segue esse conceito de diálogo duplo em vários lugares; você obtém uma caixa diálogo antes da elevação e, depois dela, obtém a antiga caixa de diálogo das versões anteriores do Windows.
Se você clicar no botão Avançado e, em seguida, na guia Auditoria, sempre obterá um botão de elevação de privilégio, como mostra a Figura 6. Não é possível modificar a auditoria sem a elevação de privilégio, mesmo que você tenha total controle sobre o objeto e seja o proprietário. Isso porque a capacidade de modificar um objeto SACL é controlada pelo privilégio SE_SECURITY_NAME , conhecido como "Gerenciar auditoria e log de segurança" nas ferramentas da GUI. Somente os administradores possuem esse direito por padrão. Entretanto, o privilégio de administrador é removido no modo de aprovação de administrador (quando o UAC está habilitado), o que exige a elevação de privilégio mesmo que você seja administrador.
Figura 6 A modificação das configurações de auditoria no Windows Vista sempre exige elevação de privilégio
Figura 6 A modificação das configurações de auditoria no Windows Vista sempre exige elevação de privilégio
Uma última observação sobre elevação ao modificar ACLs: todas essas instruções são válidas se você não desabilitar o UAC. Se desabilitar o UAC, todo comportamento volta a ser como era no Windows XP, à exceção da aparência das caixas de diálogo que é diferente. Contudo, nenhuma elevação de privilégio será necessária, desde que você faça logon como administrador, pois agora seu token terá o SID Administradores o tempo todo.

Outras ferramentas
O icacls.exe é uma ferramenta muito útil e um grande avanço sobre o cacls.exe, mas ainda possui algumas limitações. Talvez a mais notável delas seja o fato de não poder gerenciar o acesso a quaisquer objetos que não sejam arquivos e diretórios. O Windows Vista fez poucas alterações nas ACLs de outros objetos comparado ao Windows XP, mas ainda haverá ocasiões em que você desejará gerenciar ACLs em um serviço, em uma chave de registro ou mesmo em um objeto do Active Directory®.
.
Devo adverti-lo, porém, de que não é fácil usar o subnacl.exe. Na verdade, ele é bastante obtuso às vezes. Entretanto, o subinad.exe é uma ferramenta incrivelmente eficiente para gerenciar controle de acesso. Todo bom administrador precisa dessa ferramenta.

ACLs de registro
As ACLs de registro também sofreram alterações, assim como as ACLs de sistema de arquivos. Contudo, essas alterações foram bem menores em escopo do que as outras. A diferença mais óbvia das versões anteriores do Windows é que, devido à remoção de Usuários Avançados, quase todas as ACEs de Usuários Avançados foram excluídas. Os Usuários Avançados não devem ter mais poderes do que qualquer outro usuário. No entanto, uma prova do quanto as ACLs são complicadas é não terem sido completamente eliminadas para Usuários Avançados. Infelizmente, restaram algumas.
Embora as ACLs estejam no registro, em alguns lugares, a ACE para um SID é chamada de RESTRICTED. Isso não é novidade no Windows Vista, mas é um SID interessante e pouco compreendido. O RESTRICTED SID denota qualquer processo que apresente um token restrito. Um token restrito é criado ao usar um recurso especial da API CreateRestrictedToken. Esse token possui um ou mais SIDs restritos, ou seja, SIDs que são usados em uma verificação de acesso separada. Digamos que exista um processo sendo executado com um token restrito. Se esse processo tentar acessar um objeto com uma ACE para o RESTRICTED SID, o Windows executará duas verificações de acesso. A primeira é a verificação de acesso normal. A segunda funciona exatamente como a primeira, mas só acontece em relação aos SIDs restritos no token. As duas verificações de acesso devem ser aprovadas.
Atualmente, há várias ACLs que usam o RESTRICTED SID, principalmente no registro. Uma captura de tela desse tipo de ACL é mostrada na Figura 7.
Figura 7 As ACLs de Registro incluem uma ACE para RESTRICTED em vários lugares
Figura 7 As ACLs de Registro incluem uma ACE para RESTRICTED em vários lugares
No momento, alguns processos utilizam a funcionalidade de token restrito, particularmente com respeito aos SIDs restritos. Um exemplo de um processo que faz isso é o processo de serviço que hospeda o Firewall do Windows, o Mecanismo de Filtragem Base e o Serviço de Diretiva de Diagnóstico. Ele também usa um token de gravação restrita. Pelo que pude descobrir, apenas nove serviços atualmente usam RESTRICTED e tokens de gravação restrita no Windows Vista.
Quanto às versões anteriores mais recentes do Windows, a melhor prática com respeito às permissões de registro é ter muito cuidado. Exceto em circunstâncias excepcionais, e extremamente específicas, não modifique as permissões no registro. Dado o complicado modelo de herança e as perigosas operações executadas no registro, você corre um risco relativamente alto de obter uma falha fatal se modificar as ACLs no registro de forma impensada.

Resumo
Como acontece com a maioria das versões do Windows, há algumas alterações sutis no controle de acesso do Windows Vista. Entretanto, diferentemente das versões mais recentes, pequenas alterações causam uma grande mudança de comportamento. O UAC, em particular, exigiu várias alterações, como rótulos de integridade e modificações na interface do usuário ACL. Além disso, houve a primeira grande limpeza de ACLs da história.
De muitas formas, as ACLs padrão do Windows ficaram realmente mais simples no Windows Vista, algo que nunca havia acontecido antes. Como nas versões anteriores, porém, você deve ter muito cuidado ao manipular o controle de acesso até entendê-lo de forma completa. Isso é válido especialmente para as novas versões do sistema operacional. Felizmente, usando as ferramentas descritas neste artigo, você poderá explorar as ACLs com muito mais tranqüilidade.

Jesper M. Johansson é engenheiro-chefe de segurança que trabalha com questões de segurança de software e é editor-colaborador da TechNet Magazine. Ele possui Ph.D em MIS (sistemas de informação de gerenciamento) e mais de 20 anos de experiência em segurança computacional. Esta coluna foi adaptada do novo livro de Roger Grimes e Jesper Johansson, Windows Vista Security: Securing Vista Against Malicious Attacks (Segurança do Windows Vista: protegendo o Vista contra ataques mal-intencionados; Wiley, 2007).


 Os arquivos da &#225;rea de trabalho: O Microsoft Desktop Optimization Pack
Os arquivos da área de trabalho
O Microsoft Desktop Optimization Pack
Wes Miller
Esta coluna se baseia em elementos de pré-lançamento do Microsoft Desktop Optimization Pack. Todas as informações deste artigo estão sujeitas a alterações.

Desde o início do programa de licenciamento SA (Software Assurance), há vários anos, a Microsoft tem buscado adicionar recursos ao SA para que os clientes percebam um aumento de valor com o tempo. Além de oferecer atualizações para produtos Microsoft incluídos na licença, a empresa procurou oferecer
produtos e tecnologias (o Windows® PE foi um dos primeiros, por exemplo) que possam ajudar as empresas a aumentarem suas experiências com o Windows, com o Office e com outros aplicativos da Microsoft.
Para a Microsoft, o foco de muitas dessas ferramentas e programas tem sido oferecer recursos adicionais para reduzir o custo total de propriedade do Windows, do Office e de outros aplicativos da Microsoft incluídos na cobertura SA da empresa.
A Microsoft adquiriu diversas empresas em 2006 e todas elas tinham objetivos similares: reduzir o custo de propriedade e a complexidade associados ao gerenciamento e à correção do Windows e de aplicativos baseados em Windows. A Microsoft combinou algumas dessas tecnologias recém-adquiridas em um novo produto, disponível como um valor agregado aos clientes que possuem SA. As tecnologias Softricity, DesktopStandard, AssetMetrix e Winternals Software estarão disponíveis no decorrer do próximo ano como componentes do MDOP (Microsoft® Desktop Optimization Pack). Além disso, o MDOP incluirá um componente criado internamente na Microsoft, chamado Microsoft System Center Desktop Error Monitoring.
Quanto à economia, a Microsoft estima que o MDOP poderá ajudar a sua empresa a economizar algo em torno de US$ 100 a US$ 500 ao ano por desktop, dependendo das práticas recomendadas implementadas com o MDOP. Obtenha mais informações sobre o MDOP no site windowsvista.com/optimizeddesktop.

Os objetivos do Microsoft Desktop Optimization Pack
O principal objetivo do MDOP é, em resumo, permitir que a Microsoft ofereça novas tecnologias de gerenciamento em um período menor, em vez de deixá-lo preso aos lançamentos de novos sistemas operacionais. Certo, a Microsoft deseja garantir que a lacuna de tempo que existiu entre o Windows XP e o Windows Vista™ não aconteça novamente. Mas, ao oferecer ferramentas em um período previsível entre os lançamentos, o MDOP permitirá que a Microsoft atenda, com flexibilidade, às necessidades de seus usuários e isso permitirá que os clientes corporativos maximizem o valor de seus investimentos em software.
Para auxiliar empresas a se tornarem mais ágeis, a Microsoft procurou por uma estratégia que pudesse ajudar os clientes a mudar para uma infra-estrutura mais dinâmica — dinâmica no sentido definido por sua DSI (Dynamic Systems Initiative). Para obter mais informações sobre a DSI, consulte as informações disponíveis em microsoft.com/business/dsi.
Mas chega de estratégia de alto nível. Vamos examinar cada uma das cinco tecnologias incluídas no MDOP:
  • SoftGrid Application Virtualization (Virtualização de aplicativos SoftGrid)
  • Asset Inventory Service (Serviço de inventário de bens)
  • Diagnostics and Recovery Toolset (Conjunto de ferramentas de diagnóstico e recuperação)
  • Gerenciamento Avançado de Diretiva de Grupo
  • System Center Desktop Error Monitoring (Monitoramento de erro da área de trabalho central do sistema)

SoftGrid Application Virtualization
O SoftGrid Application Virtualization, adquirido da Softricity, oferece, como seu nome já diz, a virtualização de software. Quando comecei a examinar o SoftGrid, percebi que ele era o que a publicação de aplicativos para o Windows 2000 IntelliMirror® deveria ter sido. Por quê? Porque os aplicativos não são publicados para clientes, mas são totalmente virtualizados. Isso permite que eles sejam facilmente disponibilizados em sistemas cliente (ou no Terminal Server). Tão importante quanto isso, os aplicativos podem ser gerenciados de forma centralizada e até mesmo recuperados ou atualizados, se necessário. Em comparação com o modelo tradicional de MSIs e de transformações, o modelo SoftGrid torna a implantação do aplicativo significativamente menos complicada e menos arriscada.
Uma das formas de considerarmos o SoftGrid seria como uma imagem virtual. Talvez você já conheça o conceito de uma imagem de disco usada na implantação do Windows (e, freqüentemente, dos aplicativos instalados nele) em sistemas. O SoftGrid, em essência, pega o aplicativo e o empacota em uma imagem de aplicativo, em vez de uma imagem de um sistema operacional inteiro.
O SoftGrid Application Virtualization compreende três elementos fundamentais: a virtualização do aplicativo, a entrega do aplicativo e o console de gerenciamento central.
A virtualização do aplicativo propriamente dita é composta de representações virtuais do sistema de arquivos do Windows (incluindo os arquivos do sistema), do registro do Windows, das fontes, dos arquivos .ini, dos objetos COM/DCOM, dos serviços, dos objetos do kernel (semáforos, mutexes), dos objetos nomeados e dos namespaces de todos os componentes.
É importante que você não confunda a virtualização do SoftGrid com a forma como o UAC do Windows Vista executa o redirecionamento. Com o UAC, quando um aplicativo tenta gravar em áreas protegidas do registro ou do sistema de arquivos ou tenta modificá-las, ele é redirecionado a um modo de exibição do registro e do sistema de arquivos específico do usuário O SoftGrid, ao contrário, usa um conceito que realmente virtualiza o aplicativo para o sistema operacional — incluindo todos os componentes do registro e do sistema de arquivos. Mas a elegância do SoftGrid é que ele não é um único blob que define um aplicativo. Em vez disso, ele consiste em:
  • Um arquivo SFT de até 4 GB. Contém um ou mais aplicativos e todas as suas dependências, exceto as do Windows, que são esperadas nos sistemas de destino.
  • Um arquivo OSD de aproximadamente 2 KB. Contém uma definição de como o aplicativo pode ser solicitado e executado. Você pode pensar no arquivo OSD como um EXE.
  • Um arquivo ICO com cerca de 24 KB. É um atalho para o lançamento do aplicativo.
  • Um arquivo SPRJ com cerca de 13 KB. É usado pelo seqüenciador (o núcleo do SoftGrid) para a publicação, abertura, atualização e correção de pacotes existentes.
Existe um diagrama bastante abrangente sobre o funcionamento do SoftGrid Application Virtualization no site softricity.com/products/architecture.asp.
Uma imensa vantagem da solução SoftGrid é que um console de gerenciamento central (consulte a Figura 1) pode ser usado na determinação de quais aplicativos estão disponíveis para um determinado usuário ou conjunto de usuários do Active Directory®. Esses aplicativos podem então ser rapidamente enviados para os usuários por demanda, via um protocolo de streaming padrão de mercado. Uma vez instalados, os aplicativos se comportarão como se estivessem instalados localmente, pois obedecerão às personalizações do usuário (até mesmo por meio de perfis de usuário móvel) e funcionarão mesmo quando os clientes estiverem desconectados da rede. Os administradores poderão até interromper o acesso aos aplicativos — de forma dinâmica ou automática (depois de um determinado tempo, por exemplo).
Figura 1 Console de gerenciamento do SoftGrid
Figura 1 Console de gerenciamento do SoftGrid
O mais importante é que, por causa da forma como é implantado, não é necessário disponibilizar um aplicativo inteiro. Em vez disso, somente as partes necessárias para a execução do aplicativo em uso pelo usuário são baixadas. Imagine um cenário em que todo o Microsoft Office é disponibilizado como um pacote. Se um usuário usar o Word, somente os componentes necessários para a sua execução serão baixados — e não as partes necessárias para a execução do Excel®, do PowerPoint® e assim por diante. Assim que o usuário executa um dos aplicativos — o Excel, por exemplo — seus componentes associados são baixados conforme necessário.
O que há no ERD?
  • Prompt de comando
  • Explorer
  • Pesquisar
  • Bloco de Notas
  • Assistente de solução
  • Ferramentas administrativas: Autoruns, Gerenciamento de Disco, Visualizar Eventos, Editor do Registro, Serviços e Drivers, Informações do Sistema
  • Ferramentas de rede: Compartilhamento de Arquivos, Mapear Unidade de Rede, Configuração de TCP/IP
  • Ferramentas do sistema: Crash Analyzer, Disk Commander, DiskWipe, FileRestore, Hotfix Uninstall, Locksmith, System File Repair, Restauração do Sistema

Outro componente do SoftGrid é a sua capacidade de medição automática e de verificação de licenças. Isso ajudará você a permanecer em conformidade com o licenciamento de seu software sem a necessidade de software adicional.
Quase todos os aplicativos podem ser virtualizados. As principais exceções são o Internet Explorer® e outros componentes do Windows (incluindo hotfixes e service packs), softwares antivírus e drivers de dispositivo. Se você está interessado em se aprofundar no funcionamento do SoftGrid e em explorar o que ele pode fazer, recomendo a leitura do documento disponível no site Softricity.com.

Gerenciamento Avançado de Diretiva de Grupo
A DesktopStandard fez seu nome ao desenvolver ferramentas que atuavam como pontes para vínculos fracos da Diretiva de Grupo. Ao oferecer a ferramenta formalmente conhecida como GPOVault no MDOP — agora conhecida como Gerenciamento Avançado de Diretiva de Grupo — a Microsoft oferece aos clientes uma ótima ferramenta que pode transformar uma GPO poderosa (e, algumas vezes, perigosa) em um processo muito mais controlado e refinado.
Se você conhece os fundamentos do software de controle de origem, imagine o Gerenciamento Avançado de Diretiva de Grupo como um controle de origem para as Diretivas de Grupo do seu Active Directory (consulte a Figura 2 para obter um instantâneo do console do Gerenciamento Avançado de Diretiva de Grupo). Os administradores podem verificar as revisões de diretiva existentes, fazer alterações e verificá-las novamente, auditando os resultados usando relatórios semelhantes aos do console de Gerenciamento de Diretiva de Grupo. Quando o administrador estiver satisfeito com o estado da diretiva desejado, ele poderá confirmar as alterações e colocá-las em produção. Assim como um bom software de controle de origem, quando algo dá errado, as alterações poderão ser rapidamente revertidas com segurança para uma revisão anterior sem as suposições que normalmente ocorreriam em tal processo.
Figura 2 Console do Gerenciamento Avançado de Diretiva de Grupo
Figura 2 Console do Gerenciamento Avançado de Diretiva de Grupo
Outro aspecto fundamental desse processo é a capacidade de editar diretivas offline, em vez de exigir que as alterações sejam todas feitas em sistemas online e ativos. Isso permite o teste isolado de alterações antes que elas sejam feitas em todo o domínio ou unidade organizacional.
Finalmente, por meio de um modelo baseado em função, o Gerenciamento Avançado de Diretiva de Grupo permite que as alterações sejam orientadas por um processo de fluxo de trabalho projetado. Ao criar funções (como editor, revisor e aprovador), um administrador pode garantir que um processo seja colocado em um local de forma que as alterações sejam feitas de forma controlada. Assim, quando o implementador acreditar que a alteração já está pronta para ser confirmada, ele pode ter um mecanismo forte de controle de mudanças para garantir que as alterações de GPO automáticas não ocorram sem a aprovação adequada.

Asset Inventory Service
O Asset Inventory Service, composto pela tecnologia que a Microsoft obteve por meio da aquisição da AssetMetrix, é uma solução de gerenciamento de bens e de inventário muito poderosa. Ao contrário dos outros componentes do MDOP, o AIS emprega um modelo Web hospedado. Ele usa um agente de baixa capacidade que utiliza pouca largura de banda e pode ser executado uma vez ou em intervalos periódicos, permitindo que um administrador procure por aplicativos ao pesquisar um banco de dados incrivelmente extenso hospedado na Microsoft, com mais de 400.000 aplicativos, para determinar quais estão instalados nos sistemas cliente. O AIS pode, então, pegar esses dados e reconciliá-los com as licenças que você adquiriu, para garantir a conformidade e reduzir o desperdício da compra de mais licenças do que o necessário.
Alguns administradores podem, inicialmente, hesitar em usar o AIS, já que ele é um modelo que está do lado de fora do firewall e faz inventários dos sistemas internos pesquisando os programas instalados. Mas é importante entender o imenso trabalho que a Microsoft teve ao garantir a privacidade organizacional, começando por reescrever componentes fundamentais do aplicativo que compõe o AIS. Os dados do computador individual não estão ligados a quaisquer dados organizacionais. A Microsoft também certificará a tecnologia de transferência de dados com terceiros para garantir que os clientes fiquem à vontade com o modelo usado pelo AIS.

Diagnostics and Recovery Toolset
Como você já deve saber (se já teve a oportunidade de ler a biografia de minhas colunas dos últimos meses), eu era membro da Winternals quando ela foi adquirida pela Microsoft. Eu era gerente de produto de quase todos os produtos da Winternals, incluindo do Winternals Administrator's Pak. Esse foi o predecessor do DaRT (Microsoft Diagnostics and Recovery Toolset). Embora algumas das ferramentas existentes no Administrator's Pak não tenham sido incluídas no DaRT, os principais componentes do produto ERD Commander ainda estão disponíveis.
O objetivo do DaRT é oferecer um conjunto de ferramentas que pode ajudá-lo a diagnosticar problemas no sistema — mesmo se não for possível reiniciá-lo apropriadamente. E, com freqüência, você poderá corrigir esses problemas offline.
O ERD Commander utiliza o Windows PE para reinicializar um sistema que não esteja reinicializando total ou parcialmente. Um conjunto de ferramentas é disponibilizado por meio de uma interface de usuário semelhante à do Windows Explorer. Duas dessas ferramentas, o Crash Analyzer e o FileRestore, também estão disponíveis para uso online. No entanto, elas devem ser instaladas em todos os sistemas em que deverão ser executadas, se você não estiver usando o ERD Commander para diagnósticos ou recuperação offline.
A versão DaRT do ERD Commander é mostrada na Figura 3. Uma lista das ferramentas incluídas no componente ERD Commander pode ser encontrada na barra lateral. Com exceção da ferramenta Explorer, as cinco primeiras ferramentas listas são os mesmos aplicativos que você usaria em uma instalação normal do Windows. O Explorer é, assim como o aplicativo Menu Iniciar de onde ele é aberto, uma versão especializada (menor) desenvolvida para ser executada no Windows PE.
Figura 3 ERD Commander
Figura 3 ERD Commander
O Autoruns é uma ferramenta derivada de uma ferramenta da Sysinternals de mesmo nome, que permite a você ver todos os aplicativos definidos para iniciar quando o sistema é reinicializado ou quando um usuário faz logon. Gerenciamento de Disco, Visualizar Eventos, Serviços e Drivers e Informações do Sistema são ferramentas dispostas em uma interface de usuário comum e que oferece experiências similares às das ferramentas de mesmo nome do Windows. Serviços e Drivers é particularmente útil, pois pode ajudá-lo a fazer a reinicialização de um sistema que não esteja conseguindo isso devido a um driver de dispositivo ou de um serviço que não esteja funcionando corretamente. Finalmente, o Editor do Registro do Windows foi incluído para que você possa manipular o registro de um sistema offline.
O sistema de rede também está disponível no ERD Commander. Embora o sistema seja automaticamente configurado via DHCP, você pode definir um endereço IP estático usando o miniaplicativo Configuração de TCP/IP. Usando o DHCP ou o endereçamento IP estático, você pode mapear uma unidade de rede e copiar arquivos de e para o sistema inativo, ou usar o Compartilhamento de Arquivos para transformar o sistema em um servidor de arquivos para poder usar um sistema em funcionamento para copiar os arquivos do sistema com problemas.
Finalmente, também foi incluída uma coleção de diversas ferramentas. O Crash Analyzer usa as Ferramentas de Depuração para Windows (que devem ser baixadas e instaladas separadamente — elas são gratuitas, mas são atualizadas com muita freqüência) para diagnosticar a causa de uma pane. Você pode executá-lo de forma offline no ERD Commander, caso não esteja conseguindo reinicializar o sistema ou copiar um arquivo DMP para um sistema em execução e fazer o diagnóstico ali. Depois de descobrir o problema, se o culpado for um novo serviço ou driver, você poderá usar a ferramenta Serviços e Drivers para desabilitá-lo e ver se o sistema volta a funcionar normalmente.
O Disk Commander poderá ajudá-lo a recuperar uma partição acidentalmente excluída ou danificada, assim como um grupo de arquivos ou um diretório também excluídos. No outro lado do espectro, DiskWipe permite que você apague totalmente um disco ou volume. O FileRestore permite que você (seja de forma online ou offline) recupere um único arquivo que tenha sido acidentalmente excluído. Tenha em mente que o tipo de arquivo e a atividade tempo/disco desde a exclusão afetarão a capacidade de recuperação, a despeito da ferramenta utilizada.
Caso um hotfix ou service pack do Windows impeçam que o sistema tenha uma reinicialização normal, você poderá usar o Hotfix Uninstall para desinstalar, de forma seletiva, um ou mais hotfixes ou service packs. É necessário reinicializar para concluir o processo, já que o Windows não oferece suporte a uma remoção offline completa de aplicativos. Mas ele pode fazer você reinicializar novamente.
O Locksmith foi uma das ferramentas mais populares da Winternals incluídas no ERD Commander. Ele permite que você redefina qualquer senha de usuário local. Ele não funciona em controladores de domínio e não pode redefinir qualquer senha de usuário de domínio, mas é geralmente usado para redefinir a senha do administrador local quando ela é esquecida ou depois que o usuário sai da organização. O System File Repair verifica todos os arquivos do sistema protegidos para ver se algum deles está corrompido e os substitui quando necessário. A Restauração do Sistema, como o nome indica, permite que você reverta ou avance qualquer ponto de restauração do sistema Windows em um sistema Windows XP (para usar essa funcionalidade, é preciso que o Windows XP apresente pontos de restauração preexistentes).
As ferramentas do ERD Commander e do DaRT podem parecer de alguma forma aleatórias, mas são uma compilação eficaz de utilitários desenvolvidos pela Winternals. Tenho certeza de que você comprovará seu valor e verá como elas são úteis para as suas tarefas de recuperação e de solução de problemas.

System Center Desktop Error Monitoring
O DEM (System Center Desktop Error Monitoring) oferece uma forma fácil e rápida de as organizações centralizarem e diagnosticarem panes do Windows e travamentos de aplicativos. Em vez de enviar relatórios de pane e de travamento para a Microsoft, o DEM usa a Diretiva de Grupo e o Relatório de Erros do Windows para enviar relatórios a um servidor designado por você na organização para diagnóstico (e ele não exige um agente de software adicional). Todos os dados de servidor do DEM são armazenados em um banco de dados do SQL Server e, portanto, você pode facilmente consultar os dados coletados sobre seus próprios relatórios e aplicativos internos. Isso permite que você aponte problemas em sua organização de forma proativa. Usando essas informações, você pode criar relatórios sobre tais incidentes, descobrir as causas mais freqüentes de panes e de travamentos e garantir que patches do Windows e de aplicativos tenham prioridade para minimizar ou eliminar o tempo de inatividade do sistema.
Você pode configurar o seu servidor DEM para fazer o upload dos resultados para a Microsoft, assim como fazer com que o DEM baixe automaticamente os dados mais recentes para solução de problemas da Microsoft e de aplicativos de terceiros. Dados adicionais podem ser recolhidos de clientes em caso de uma pane ou um travamento.

Licenciando o MDOP
O primeiro requisito para que um cliente licencie o MDOP é a existência de um contrato SA com a Microsoft. Com isso em mãos, os custos de licenciamento variam de US$ 7 a US$ 10 por desktop. Também estão disponíveis descontos por volume e preços educacionais.
O MDOP não está disponível fora do contexto de um contrato SA, com uma exceção: os clientes que desejarem usar as tecnologias SoftGrid com seus Terminal Servers (consulte softricity.com/solutions/sbc.asp) ou SMS (consulte softricity.com/products/softgrid-sms.asp) poderão fazê-lo; as tecnologias AssetMetrix serão disponibilizadas em versões futuras do SMS e do System Center Configuration Manager.

Disponibilidade e atualizações
Os componentes iniciais do MDOP estão disponíveis atualmente. Os componentes são disponibilizados como a seguir:
  • A Microsoft disponibilizou o SoftGrid no início de 2007.
  • O Microsoft DaRT está disponível desde maio de 2007.
  • As tecnologias GPOVault devem ser disponibilizadas em julho de 2007.
  • O Desktop Error Monitoring deve ser disponibilizado no MDOP em julho de 2007.
  • As tecnologias AssetMetrix devem ser disponibilizadas em beta em julho de 2007 e serão lançadas em agosto.
  • Uma atualização dos componentes do DaRT foi planejada para o fim de 2007, sendo que a principal mudança será a compatibilidade com o Windows Vista.
O plano para lançamentos futuros do MDOP é oferecer aprimoramentos, atualizações e novos recursos duas vezes por ano.

A direção do MDOP
Como mencionado, os principais componentes das tecnologias AssetMetrix serão integrados a versões futuras do System Center Configuration Manager. Na verdade, você pode esperar que, com o tempo, a Microsoft desenvolva funcionalidades MDOP, algumas delas irão fluir para as tecnologias de implantação, gerenciamento e configuração de linha de base da Microsoft. Novas tecnologias (algumas criadas pela Microsoft, outras adquiridas de outras empresas) serão disponibilizadas em versões futuras do MDOP. Basicamente, o MDOP será um pacote sempre em evolução das tecnologias mais avançadas de gerenciamento e de configuração.

Wes Miller é gerente de desenvolvimento da Pluck em Austin, Texas. Antes disso, ele trabalhou na Winternals Software, em Austin, e na Microsoft, como gerente de programas e gerente de produtos do Windows. Entre em contato com ele pelo email technet@getwired.com.
Gostaria de expressar a minha gratidão a Chad Jones e Gavriella Schuster, gerentes de produto do Microsoft Desktop Optimization Pack, por me ajudarem nesta coluna.


 Segredos do Windows: Os poderes curativos do modo de seguran&#231;a
Segredos do Windows
Os poderes curativos do modo de segurança
Raymond Chen

Quando o modo de segurança do Windows (também conhecido como o modo "arrume esta bagunça") foi desenvolvido pela primeira vez para o Windows® 95, pretendia-se fazer mais do que simplesmente desativar drivers. Ele também foi criado para corrigir aquilo que pudesse ser corrigido automaticamente.
Por exemplo, quando você entra em modo de segurança, o Windows Explorer verifica as posições de todos os ícones da área de trabalho, garantindo que todos estejam visíveis, já que é possível criar um estado com um ícone posicionado fora da tela.
Se quiser fazer um teste, posicione dois ícones na área de trabalho, um na extremidade esquerda e outro na extremidade direita. Use Ctrl+clique para selecionar ambos os ícones e arraste o ícone à esquerda para o lado direito da tela. Quando isso for feito, o segundo ícone também se moverá, mantendo a mesma posição relativa ao ícone que está sendo arrastado. E ele se moverá para fora da tela.
O modo de segurança permite que os usuários solucionem problemas do Windows
O modo de segurança permite que os usuários solucionem problemas do Windows
Se o Windows Explorer não corrigir as posições dos ícones em modo de segurança, as instruções da solução de problemas serão potencialmente mais confusas do que úteis:
  1. Inicie o computador em modo de segurança (OK).
  2. Clique duas vezes no ícone Meu computador (hum, eu não consigo ver o ícone Meu computador).
  3. ...
Ôpa, o ícone Meu computador está fora da tela ou indisponível. Você não consegue passar nem da etapa 2 da solução de problemas.
Já houve reclamações de algumas pessoas que diziam: "Você não deveria ter corrigido os ícones automaticamente. Se um usuário ligar para o suporte técnico com esse problema, o engenheiro de suporte pode simplesmente dizer ao usuário para clicar com o botão direito do mouse na área de trabalho e selecionar a opção para redefinir as posições dos ícones. Missão cumprida e o modo de segurança não mexeu nos meus ícones".
Em primeiro lugar, você já perde o jogo quando diz "se um usuário ligar para o suporte técnico com esse problema". Se um usuário tiver de usar o telefone, você falhou.
Além disso, essa proposta não considera o aspecto psicológico do modo de segurança. Os usuários reiniciam em modo de segurança quando algo não está agindo de forma adequada, embora eles não saibam, necessariamente, o que farão quando chegarem lá. O que eles realmente estão fazendo é simplesmente ver o que acontece. "Se algo está errado, vamos tentar o modo de segurança". No Windows 95, aproveitamos esse aspecto psicológico ao implementarmos vários tipos de ações de correção automática em modo de segurança. Funcionou muito bem.
Além disso, se usuários ligarem para você e se ouvirem "reinicie em modo de segurança, isso deve corrigir o problema", dirão a si mesmos: "bem, a solução era fácil. Eu devia ter pensado nisso".
Mas se você oferecer mais instruções, dizendo "reinicie em modo de segurança, clique com o botão direito do mouse aqui, selecione esta opção de menu e clique nesta caixa", os usuários seguirão as instruções e o problema será corrigido, mas isso não fará nada para que eles se sintam mais à vontade com seus computadores. Em vez disso, eles se sentirão impotentes e desencorajados. Em vez de sentir que têm poder, os usuários entram em um estado de desamparo. "Eu nunca teria descoberto isso. Os computadores são muito difíceis de usar".

Raymond Chen, The Old New Thing (O Novo Velho), e o livro homônimo (Addison-Wesley, 2007) tratam da história do Windows e da programação Win32. Ele prefere ir embora antes de se aborrecer.