Agosto 2008 Agosto 2008
SQL Server: Principais dicas para uma manutenção eficiente do banco de dados
Com muita freqüência, pessoas que não recebem treinamento de administração de bancos de dados podem acabar se responsabilizando por um. Elas não contam com o treinamento e o conhecimento apropriados à manutenção do banco de dados, e os problemas começam a se desenvolver. Aqui está uma cartilha para todos os DBAs involuntários que precisam de um curso intensivo em práticas recomendadas de manutenção de bancos de dados. Paul S. Randal
Administração do Windows: Avaliando o desempenho do seu servidor
Quando os usuários reclamam do mau desempenho de um servidor, você sabe onde procurar para diagnosticar o problema? O PerfMon pode ser uma ferramenta indispensável para isso, devido a seus inúmeros recursos de diagnóstico. Obtenha uma visão geral dos principais indicadores que você deve usar para diagnosticar uma variedade de afunilamentos comuns capazes de retardar os servidores. Steven Choy
System Center: O Windows PowerShell no System Center Operations Manager
O Windows PowerShell foi integrado ao System Center Operations Manager 2007, proporcionando uma maneira altamente eficaz de realizar e automatizar tarefas administrativas comuns. Obtenha uma visão geral de como é possível usar o Windows PowerShell no OpsMgr para realizar manutenção de rotina, gerenciar agentes e muito mais. Marco Shaw
Serviços de Informações da Internet: Dimensionando aplicativos ASP.NET: lições aprendidas
A chave do dimensionamento bem-sucedido de um aplicativo ASP.NET é contar com um esforço colaborativo entre desenvolvedores e administradores de rede, desde o início do ciclo de vida do aplicativo. Descubra quais são os fatores necessários para dimensionar um aplicativo e veja como essa colaboração pode ajudar a garantir a execução desejada do aplicativo. Richard Campbell
Columns
Do editor: Ao vivo da Tech•Ed: | Cartas: Com a palavra, os leitores: | Toolbox: Novos produtos para profissionais de TI:
P+R SQL: Particionamento, verificações de consistência e muito mais: Paul Randal esclarece as suas dúvidas sobre o SQL Server, mostrando como realizar verificações de consistência e outros tipos de manutenção em bancos de dados muito grandes, como lidar com uma atualização acidental e muito mais.Paul S. Randal | Utilitário em destaque: Utilitário Limpeza do Windows Installer: As informações de configuração deixadas pelo Windows Installer poderão causar problemas quando você tentar atualizar ou desinstalar um aplicativo. Isso pode ser resolvido com o utilitário Limpeza do Windows Installer, que pode ajudá-lo a remover as informações do Windows Installer para um aplicativo e a reinstalá-lo.Lance Whitney | Explorando o SharePoint: Solução de problemas de integração do sistema de mensagens: Integrar o SharePoint em um ambiente de sistema de mensagens não é uma tarefa fácil, mas o impacto positivo na produtividade faz com que o projeto valha a pena. Veja a seguir orientações sobre como solucionar os problemas que podem surgir durante a configuração do ambiente.Pav Cherny
Windows PowerShell: Uma espiada no gerenciamento remoto da versão 2.0: O Windows PowerShell 2.0 está em produção, e o CTP mais recente fornece alguns ótimos recursos novos. Veja uma rápida análise sobre a comunicação remota, um dos recursos novos mais interessantes que você encontrará no Windows PowerShell 2.0 CTP2.Don Jones | Ei, Equipe de Scripts!: Tomando a via expressa: Com o Windows Vista, o controle ActiveX UserAccounts.CommonDialog para abrir uma caixa de diálogo de abertura de arquivo deixou de existir. Veja como você pode resolver esse problema usando o Visual Basic Express Edition.A Equipe de Scripts da Microsoft | Os arquivos da área de trabalho: Serviços de Implantação do Windows 101: Explore as diferentes versões dos Serviços de Implantação do Windows, veja como é possível capturar uma imagem personalizada do sistema operacional e saiba do que você precisa para fazer instalações mais automatizadas.Wes Miller
Security Watch: Senhas e cartões de crédito, parte 2: Na parte final desta série de três partes, Jesper Johansson analisa como fornecedores de software, pacotes de segurança e iniciativas de marketing dificultam os esforços de segurança efetivos e nos alerta de que essas práticas podem levar ao colapso do ecossistema de segurança em tecnologia.Jesper M. Johansson | Computação sustentável: Filtrando o greenwashing: Compreender o consumo de energia agora é parte essencial do gerenciamento de uma infra-estrutura de TI. Conheça as estratégias que podem ser empregadas para implementar o monitoramento de energia no ambiente e melhorar a compreensão do consumo de energia dos dispositivos em toda a organização.Dave Ohara | Anotações de campo: IMAP salva o mundo: Você tem emails salvos em diversos lugares, formatos e sistemas operacionais? Dara Korra’ti explica como acessar todos os seus emails em um único lugar usando IMAP4.R'ykandar Korra'ti
Segredos do Windows: Expandindo o passado: Raymond explica como o antigo e eficiente sistema Alpha AXP deixou a aposentadoria para ajudar no desenvolvimento de uma nova geração de sistemas de 64 bits.Raymond Chen


SQL Server
Principais dicas para uma manutenção eficiente do banco de dados
Paul S. Randal
Visão geral:
  • Gerenciando os arquivos de dados e os arquivos de log de transações
  • Eliminando a fragmentação do índice
  • Garantindo estatísticas precisas e atualizadas
  • Detectando páginas de banco de dados corrompidas
  • Estabelecendo uma estratégia de backup efetiva

Sumário
Gerenciamento de arquivos de dados e de arquivos de log
Fragmentação do índice
Estatísticas
Detecção de danos
Backups
Conclusão
Várias vezes por semana me pedem ajuda quanto à forma de manutenção eficiente de um banco de dados de produção. Às vezes, as perguntas vêm dos DBAs que estão implementando novas soluções e precisam de
práticas de manutenção de ajuste fino adequadas às novas características dos bancos de dados. No entanto, as perguntas costumam vir mais de pessoas que não são DBAs profissionais, mas que, por uma razão ou outra, receberam a propriedade e a responsabilidade de um banco de dados. Gosto de chamar essa função de "DBA involuntário". O objetivo deste artigo é apresentar uma última palavra quanto às práticas recomendadas da manutenção de banco de dados aos DBAs involuntários que existem.
Assim como acontece com a maioria das tarefas e dos procedimentos no mundo da TI, não existe uma solução de tamanho único, simples, para uma manutenção efetiva de banco de dados, mas há algumas áreas principais que quase sempre precisam ser abordadas. As minhas cinco áreas de preocupação principais são (sem nenhuma ordem de importância específica):
  • Gerenciamento de arquivos de dados e de arquivos de log
  • Fragmentação do índice
  • Estatísticas
  • Detecção de danos
  • Backups
Um banco de dados sem manutenção (ou com manutenção ruim) pode desenvolver problemas em uma ou mais dessas áreas, o que pode acabar resultando em mau desempenho do aplicativo ou até em tempo de inatividade e perda de dados.
Neste artigo, explicarei por que essas questões são importantes e mostrarei algumas formas simples de atenuar os problemas. Basearei as minhas explicações no SQL Server® 2005, mas também realçarei as principais diferenças encontradas no SQL Server 2000 e no futuro SQL Server 2008.

Gerenciamento de arquivos de dados e de arquivos de log
A primeira área que sempre recomendo verificar assim que alguém assume um banco de dados diz respeito às configurações relacionadas ao gerenciamento dos arquivos de dados e dos arquivos de log (de transações). Mais especificamente, você deve verificar se:
  • Os arquivos de dados e os arquivos de log estão separados uns dos outros e isolados em relação a todo o resto
  • O aumento automático está configurado corretamente
  • A inicialização instantânea de arquivo está configurada
  • A redução automática não está habilitada e se a redução não faz parte do plano de manutenção
Quando os arquivos de dados e os arquivos de log (que, em condições ideais, devem estar em volumes totalmente separados) compartilham um volume com outro aplicativo que cria ou expande arquivos, existe o potencial de fragmentação do arquivo. Em arquivos de dados, a fragmentação em excesso pode ser um pequeno fator de contribuição em consultas de mau desempenho (mais especificamente aquelas que examinam grandes quantidades de dados). Em arquivos de log, isso poderá ter um impacto muito mais significativo em termos de desempenho, em especial se o aumento automático estiver definido para aumentar muito pouco o tamanho de cada arquivo sempre que for necessário.
Internamente, os arquivos de log são divididos em seções chamadas VLFs (arquivos de log virtuais), e quanto mais fragmentação houver no arquivo de log (uso o singular aqui porque não há nenhum ganho em ter vários arquivos de log – deve haver apenas um por banco de dados), mais VLFs haverá. Dado um arquivo de log com mais de, digamos, 200 VLFs, o desempenho pode ser afetado negativamente em operações relacionadas a log como leituras de log (em replicações/reversões transacionais, por exemplo), backups de log e até mesmo gatilhos no SQL Server 2000 (a implementação dos gatilhos foi alterada no SQL Server 2005 para a estrutura do controle de versão em seqüência, no lugar do log de transações).
A prática recomendada em relação ao dimensionamento dos arquivos de dados e dos arquivos de log é criá-los com um tamanho inicial apropriado. Em arquivos de dados, o tamanho inicial deve levar em conta o potencial de adição de mais dados ao banco a curto prazo. Por exemplo, se o tamanho inicial dos dados for igual a 50 GB, mas você souber que nos próximos seis meses serão adicionados mais 50 GB de dados, faz sentido criar o arquivo de dados já com 100 GB, em vez de precisar aumentá-lo várias vezes até atingir esse tamanho.
Infelizmente, isso é um pouco mais complicado em arquivos de log, e você precisa considerar fatores como o tamanho da transação (transações demoradas não podem ser excluídas do log até que sejam concluídas) e a freqüência de backup do log (porque é isso o que remove a parte inativa do log). Para obter mais informações, consulte "8 etapas para uma maior produtividade dos logs de transações", uma postagem em blog conhecida em SQLskills.com escrita pela minha esposa, Kimberly Tripp.
Uma vez configurado, o tamanho dos arquivos deve ser monitorado em horários diferentes e aumentados de forma pró-ativa e manual em uma determinada hora do dia. O aumento automático deve permanecer ativado como uma proteção eventual para que os arquivos possam continuar crescendo no caso de algum evento anormal. A lógica contra deixar o gerenciamento de arquivos apenas como aumento automático é que o aumento automático de pequenas quantidades leva à fragmentação de arquivo, além de ser um processo demorado que paralisa a carga de trabalho do aplicativo em momentos imprevisíveis.
O aumento automático do tamanho deve ser definido como um valor específico, e não uma porcentagem, para associar a hora e o espaço necessários à sua realização, caso ele ocorra. Por exemplo, você talvez queira definir um arquivo de dados de 100 GB para ter um aumento automático fixo de 5 GB, em vez de, digamos, 10 por cento. Isso significa que ele sempre aumentará em 5 GB, não importando o tamanho final do arquivo, e não em uma quantidade sempre crescente (10 GB, 11 GB, 12 GB e assim por diante) sempre que o arquivo ficar maior.
Quando aumenta (manualmente ou pelo aumento automático), um log de transações é sempre inicializado com zero. Os arquivos de dados têm o mesmo comportamento padrão do SQL Server 2000, mas, desde o SQL Server 2005, é possível habilitar a inicialização de arquivo instantânea, que ignora a inicialização dos arquivos com zero e, assim, torna o aumento e o aumento automático praticamente instantâneos. Ao contrário do que as pessoas acreditam, esse recurso está disponível em todas as edições do SQL Server. Para obter mais informações, digite "inicialização de arquivo instantânea" no índice dos Manuais Online do SQL Server 2005 ou do SQL Server 2008.
Por fim, tome cuidado para não habilitar a redução de maneira alguma. A redução pode ser usada para diminuir o tamanho de um arquivo de dados ou de um arquivo de log, mas é um processo muito intrusivo, que demanda muitos recursos e causa grandes quantidades de fragmentação da verificação lógica em arquivos de dados (veja mais detalhes abaixo), além de levar a um mau desempenho. Alterei a entrada referente à redução nos Manuais Online do SQL Server 2005 para incluir um aviso quanto a esse efeito. No entanto, a redução manual dos arquivos de dados e dos arquivos de log individuais pode ser aceitável em circunstâncias especiais.
Vídeo
Assista à demonstração de Paul Randal de como a redução e a redução automática podem causar problemas de fragmentação graves no banco de dados.

A redução automática é a pior causa porque começa a cada 30 minutos no segundo plano e tenta reduzir bancos de dados nos quais a opção de redução automática do banco de dados está definida como verdadeira. Trata-se de um processo, em certa medida, imprevisível porque só reduz bancos de dados com mais de 25 por cento de espaço livre. Como a redução automática usa muitos recursos e causa a fragmentação por queda de desempenho, esse não é um bom plano em nenhuma circunstância. Você deve sempre desativar a redução automática com:
ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;
Um plano de manutenção regular que inclua um comando manual de redução do banco de dados quase sempre é tão ruim quanto. Caso você ache que o banco de dados continua crescendo depois de ter sido reduzido pelo plano de manutenção, isso é porque o banco de dados precisa desse espaço para execução.
A melhor coisa a fazer é permitir que o banco de dados aumente até um tamanho permanente e evitar executar a redução. É possível encontrar mais informações sobre as desvantagens de usar a redução, além de alguns comentários sobre os novos algoritmos do SQL Server 2005 no meu velho blog do MSDN® em blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx.

Fragmentação do índice
Além da fragmentação no nível do sistema de arquivos e dentro do arquivo de log, também é possível que haja fragmentação nos arquivos de dados, nas estruturas que armazenam os dados de tabela e os dados de índice. Há dois tipos de fragmentação básicos que ocorrem dentro de um arquivo de dados:
  • Fragmentação em páginas de dados e de índices individuais (às vezes, chamada de fragmentação interna)
  • Fragmentação em estruturas de índice ou de tabela que consiste em páginas (chamada de fragmentação da verificação lógica e fragmentação da verificação de extensão)
A fragmentação interna é onde existe um grande espaço vazio em uma página. Como mostra a Figura 1, todas as páginas de um banco de dados têm 8 KB e um cabeçalho de 96 bytes. Dessa forma, uma página pode armazenar aproximadamente 8.096 bytes de dados de tabela ou dados de índice (as informações internas específicas do índice e da tabela relacionadas aos dados e às estruturas das linhas podem ser encontradas no meu blog em sqlskills.com/blogs/paul, na categoria Inside The Storage Engine). O espaço vazio pode ocorrer caso um dos registros da tabela ou do índice seja maior do que metade do tamanho de uma página, e apenas um registro possa ser armazenado por página. Isso pode ser bem difícil ou impossível de corrigir, pois exigiria uma alteração no esquema da tabela ou do índice, por exemplo, alterando uma chave de índice para algo que não causasse pontos de inserção aleatórios como faz o GUID.
Figura 1 A estrutura de uma página de banco de dados (clique na imagem para ampliá-la)
É mais comum que a fragmentação interna seja resultante de modificações feitas em dados como inserções, atualizações e exclusões, o que pode deixar um espaço vazio em uma página. Um fator de preenchimento mal gerenciado também pode contribuir para a fragmentação. Consulte os Manuais Online para obter mais detalhes. Dependendo do esquema de tabela/índice e das características do aplicativo, esse espaço vazio, depois de criado, talvez jamais seja reutilizado e pode levar a quantidades cada vez maiores de espaço inutilizável no banco de dados.
Considere, por exemplo, uma tabela com 100 milhões de linhas e um tamanho de registro médio de 400 bytes. Com o passar do tempo, o padrão de modificação dos dados do aplicativo deixa cada página com, em média, 2.800 bytes de espaço livre. O espaço total exigido pela tabela é de aproximadamente 59 GB, calculados como 8.096-2.800/400 = 13 registros por página de 8 KB e, em seguida, dividindo 100 milhões por 13 para obter o número de páginas. Se o espaço não estivesse sendo desperdiçado, caberiam 20 registros por página, reduzindo o espaço total obrigatório para 38 GB. É uma grande economia!
Assim, o espaço desperdiçado em páginas de dados/índice pode levar à necessidade de mais páginas para manter a mesma quantidade de dados. Isso não apenas exige mais espaço em disco, mas também significa que uma consulta precisa usar mais E/Ss para ler a mesma quantidade de dados. E todas essas páginas a mais ocupam mais espaço no cache de dados, o que consome mais memória do servidor.
A fragmentação da verificação lógica é causada por uma operação chamada divisão da página. Isso ocorre quando um registro precisa ser inserido em uma página de índice específica (de acordo com a definição da chave de índice), mas não há espaço suficiente na página para colocar os dados que estão sendo inseridos. A página é dividida ao meio e aproximadamente 50 por cento dos registros são movidos para uma página recém-alocada. Essa nova página não costuma ser fisicamente contígua à antiga e, por isso, é chamada de fragmentada. O conceito da fragmentação da verificação de extensão é parecido. A fragmentação nas estruturas de tabela/índice afeta a possibilidade de o SQL Server realizar verificações eficientes, independentemente de serem em tabela/índice completo ou associadas a uma cláusula WHERE de consulta (como SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000).
A Figura 2 mostra páginas de índice recém-criadas com fator de preenchimento de 100 por cento e sem nenhuma fragmentação – as páginas estão cheias e a ordem física delas corresponde à ordem lógica. A Figura 3 mostra a fragmentação que pode ocorrer após inserções/atualizações/exclusões aleatórias.
Figura 2 Páginas de índice recém-criadas sem nenhuma fragmentação; páginas 100% cheias (clique na imagem para ampliá-la)
Figura 3 Páginas de índice que mostram as fragmentações da verificação interna e lógica após inserções, atualizações e exclusões aleatórias (clique na imagem para ampliá-la)
Às vezes, a fragmentação pode ser impedida pela alteração do esquema de tabela/índice, mas, como mencionei anteriormente, isso pode ser muito difícil ou impossível. Caso a prevenção não seja uma opção, há formas de remover a fragmentação depois que ela ocorreu – em especial, recompilando ou reorganizando um índice.
A recompilação de um índice envolve criar uma nova cópia do índice – bem compactado e o mais contíguo possível – e ignorar o antigo, fragmentado. Como o SQL Server cria uma nova cópia do índice antes de remover o antigo, ele exige um espaço livre nos arquivos de dados aproximadamente equivalente ao tamanho do índice. No SQL Server 2000, recompilar um índice sempre foi uma operação offline. No entanto, no SQL Server 2005 Enterprise Edition, a recompilação do índice pode acontecer online, com algumas restrições. Por outro lado, a reorganização usa um algoritmo in loco para compactar e desfragmentar o índice; ela exige apenas 8 KB de espaço adicional para ser executada – e a execução é sempre online. Na verdade, no SQL Server 2000, escrevi especificamente o código de reorganização do índice como uma alternativa online, que economiza espaço em disco, para recompilar um índice.
No SQL Server 2005, os comandos a serem analisados são ALTER INDEX … REBUILD para recompilar índices e ALTER INDEX … REORGANIZE para reorganizá-los. Essa sintaxe substitui os comandos DBCC DBREINDEX e DBCC INDEXDEFRAG do SQL Server 2000, respectivamente.
Existem muitas vantagens e desvantagens entre esses métodos, como a quantidade de registro em log de transações, a quantidade de espaço livre obrigatória no banco de dados e se o processo pode ser interrompido sem que haja perda do trabalho. Você encontrará um white paper que aborda esses fatores e muito mais em microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx. O documento se baseia no SQL Server 2000, mas os conceitos se aplicam facilmente às versões posteriores.
Algumas pessoas simplesmente optam por recompilar ou reorganizar todos os índices todas as noites ou todas as semanas (usando uma opção de plano de manutenção, por exemplo), em vez de imaginar quais são os índices fragmentados e se haverá algum benefício com a remoção da fragmentação. Embora essa possa ser uma boa solução para um DBA involuntário que só quer colocar as coisas em ordem com o mínimo de esforço, saiba que pode ser uma opção muito ruim para bancos de dados ou sistemas maiores nos quais os recursos são essenciais.
Uma abordagem mais sofisticada envolve usar a DMV sys.dm_db_index_physical_stats (ou DBCC SHOWCONTIG no SQL Server 2000) para determinar periodicamente quais são os índices fragmentados e, assim, escolher se e como trabalhar com eles. O white paper também aborda o uso dessas opções mais diretas. Além disso, é possível ver alguns códigos de exemplo sobre como fazer essa filtragem no Exemplo D da entrada nos Manuais Online referente à DMV sys.dm_db_index_physical_stats do SQL Server 2005 (msdn.microsoft.com/library/ms188917) ou no Exemplo E da entrada nos Manuais Online referente a DBCC SHOWCONTIG do SQL Server 2000 e versões posteriores (em msdn.microsoft.com/library/aa258803).
Independentemente do método que você usar, é altamente recomendável investigar e corrigir a fragmentação regularmente.
O Processador de Consultas faz parte do SQL Server que decide como uma consulta deve ser executada – mais especificamente, quais tabelas e índices usar e quais operações realizar neles para obter os resultados; isso se chama plano de consulta. Alguns dos dados mais importantes sobre esse processo de tomada de decisões são as estatísticas que descrevem a distribuição dos valores de dados das colunas dentro de uma tabela ou índice. Obviamente, as estatísticas precisam ser precisas e atualizadas para que sejam úteis ao Processador de Consultas; do contrário, podem ser escolhidos planos de consulta com mau desempenho.
As estatísticas são geradas com a leitura dos dados de tabela/índice e a determinação da distribuição dos dados para as colunas relevantes. As estatísticas podem ser criadas com a verificação de todos os valores de dados de uma determinada coluna (uma verificação completa), mas também podem se basear em uma porcentagem dos dados especificada pelo usuário (uma verificação de exemplo). Se a distribuição dos valores em uma coluna está bem equilibrada, uma verificação de exemplo deve ser o suficiente, e ela torna a criação e a atualização das estatísticas mais rápidas do que em uma verificação completa.
Observe que as estatísticas podem ser criadas e mantidas automaticamente ativando-se as opções de banco de dados AUTO_CREATE_STATISTICS e AUTO_UPDATE_STATISTICS, como mostra a Figura 4. Elas permanecem ativadas por padrão, mas se apenas herdou um banco de dados, você talvez queira vê-las apenas para ter certeza. Às vezes, as estatísticas podem ficar desatualizadas, caso em que é possível atualizá-las manualmente usando a operação UPDATE STATISTICS em determinados conjuntos de estatísticas. Como alternativa, pode ser usado o procedimento armazenado sp_updatestats, que atualiza todas as estatísticas desatualizadas (no SQL Server 2000, o sp_updatestats atualiza todas as estatísticas, não importa a idade).
Figura 4 Alterando as configurações do banco de dados por meio do SQL Server Management Studio (clique na imagem para ampliá-la)
Se você quiser atualizar as estatísticas como parte do plano de manutenção regular, existe um detalhe que deve ser observado. Tanto UPDATE STATISTICS quanto sp_updatestats usam como padrão o nível de amostragem especificado anteriormente (se houver) – e isso pode ser inferior a uma verificação completa. As recompilações de índice atualizam automaticamente as estatísticas com uma verificação completa. Caso você atualize manualmente as estatísticas após a recompilação de um índice, é possível acabar com estatísticas menos precisas! Isso pode acontecer caso uma verificação de exemplo da atualização manual substitua a verificação completa gerada pela recompilação do índice. Por outro lado, a reorganização de um índice não atualiza nenhuma estatística.
Mais uma vez, muitas pessoas têm um plano de manutenção que atualiza todas as estatísticas em um determinado ponto antes ou depois da recompilação de todos os índices – e, sem saber, acabam com estatísticas potencialmente menos precisas. Se você optar por apenas recompilar todos os índices com freqüência, isso também cuidará das estatísticas. Caso opte por uma rota mais complexa com remoção da fragmentação, você também deverá fazer isso para a manutenção de estatísticas. Sugiro o seguinte:
  • Analise os índices e determine em quais deles trabalhar, além de como realizar a remoção da fragmentação.
  • Em todos os índices que não foram recompilados, atualize as estatísticas.
  • Atualize as estatísticas de todas as colunas não indexadas.
Para obter mais informações sobre as estatísticas, consulte o white paper "Estatísticas usadas pelo Otimizador de Consultas no Microsoft® SQL Server 2005" (microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx).

Detecção de danos
Já abordei a manutenção relacionada ao desempenho. Agora quero mudar a marcha e abordar a detecção e a atenuação de danos.
É muito improvável que o banco de dados que você está gerenciando contenha informações totalmente inúteis com as quais ninguém se preocupa. O que fazer então para garantir que os dados permaneçam perfeitos e recuperáveis no caso de um desastre? Os detalhes da elaboração de uma estratégia de recuperação de desastres completa e alta disponibilidade estão além do escopo deste artigo, mas você poderá começar com algumas medidas simples.
A esmagadora maioria dos danos é causada por "hardware". Por que entre aspas? Bem, hardware aqui é, de fato, uma abreviação de "algo no subsistema de E/S sob o SQL Server". O subsistema de E/S consiste em elementos como o sistema operacional, drivers do sistema de arquivos, drivers de dispositivo, controladores RAID, cabos, redes e as próprias unidades de disco. Há muitos lugares onde os problemas podem (e devem) ocorrer.
Um dos problemas mais comuns é quando ocorre uma falha de energia e uma unidade de disco está em meio à gravação de uma página do banco de dados. Se a unidade não conseguisse concluir a gravação antes de ficar sem energia (ou as operações fossem armazenadas em cache e não houvesse bateria reserva suficiente para liberar o cache da unidade), o resultado seria uma imagem de página incompleta no disco. Isso pode acontecer porque uma página de banco de dados com 8 KB é, na verdade, formada por 16 setores de disco contíguos de 512 bytes. Uma gravação incompleta poderá ter gravado em alguns dos setores da página nova, mas deixado alguns dos setores da imagem da página anterior. Essa situação é chamada de página interrompida. Como é possível detectar quando isso acontece?
O SQL Server conta com um mecanismo para detectar essa situação. Isso envolve o armazenamento de alguns bits de cada setor da página e a gravação de um padrão específico em seu lugar (isso acontece pouco antes de a página ser gravada em disco). Se o padrão não for o mesmo quando a página for lida novamente, o SQL Server saberá que ela estava "interrompida" e irá gerar um erro.
No SQL Server 2005 e versões posteriores, está disponível um mecanismo muito mais abrangente chamado soma de verificação de página, capaz de detectar qualquer dano em uma página. Isso envolve a gravação de uma soma de verificação de página inteira na página um pouco antes de ela ser gravada e, em seguida, o teste quando a página é lida novamente, como acontece com a detecção de página interrompida. Após a habilitação das somas de verificação de página, uma página precisa ser lida no pool de buffers, alterada de alguma forma e, em seguida, gravada em disco novamente antes de ser protegida por uma soma de verificação da página.
Portanto, trata-se de uma prática recomendada manter as somas de verificação habilitadas no SQL Server 2005 em diante, com a detecção de página interrompida habilitada no SQL Server 2000. Para habilitar somas de verificação de página, use:
ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;
Para habilitar a detecção de página interrompida no SQL Server 2000, use:
ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;
Esses mecanismos permitem detectar quando uma página apresenta um dano, mas somente quando ela é lida. De que forma é possível forçar facilmente a leitura de todas as páginas alocadas? O melhor método para fazer isso (e encontrar outros tipos de dano) é usar o comando DBCC CHECKDB. Independentemente das opções especificadas, esse comando sempre irá ler todas as páginas do banco de dados, o que faz com que todas as somas de verificação de página ou detecção de página interrompida sejam verificadas. Você também deve configurar alertas para saber quando os usuários enfrentam problemas de danos durante a execução de consultas. É possível ser notificado de todos os problemas descritos acima usando um alerta para erros de severidade 24 (Figura 5).
Figura 5 Configurando um alerta para todos os erros de severidade 24 (clique na imagem para ampliá-la)
Portanto, outra prática recomendada é executar regularmente DBCC CHECKDB nos bancos de dados para verificar sua integridade. Há muitas variações desse comando e dúvidas quanto à freqüência de sua execução. Infelizmente, não há nenhum white paper disponível que aborde isso. No entanto, como DBCC CHECKDB foi o principal trecho de código que escrevi para o SQL Server 2005, bloguei muito a respeito dele. Consulte a categoria "CHECKDB From Every Angle" no meu blog (sqlskills.com/blogs/paul) para obter vários artigos detalhados sobre verificação de consistência, práticas recomendadas e dicas práticas. Para DBAs involuntários, a regra geral é executar um DBCC CHECKDB sempre que você faz um backup completo do banco de dados (mais detalhes a seguir). Recomendo a execução do seguinte comando:
DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS,
  ALL_ERRORMSGS;
Se houver qualquer saída desse comando, o DBCC terá encontrado danos no banco de dados. Então a pergunta passa a ser o que fazer caso o DBCC CHECKDB encontre um dano. É onde surgem os backups.
Quando ocorre um dano ou outro desastre qualquer, a forma mais eficiente de recuperação é recuperar o banco de dados usando backups. Agora, isso inicialmente pressupõe que você tenha backups e que eles próprios não estejam corrompidos. É muito comum que as pessoas queiram saber como recolocar um banco de dados seriamente corrompido em execução quando não têm um backup. A resposta é simples: não é possível, não sem experimentar alguma forma de perda de dados que pudesse gerar confusão em relação à lógica de negócios e à integridade dos dados relacionais.
Portanto, existe uma ótima situação para fazer backups regulares. As complicações do uso do backup e da restauração estão muito além do escopo deste artigo, mas me permita dar uma palavra final quanto ao estabelecimento de uma estratégia de backup.
Primeiro, você deve fazer backups regulares completos do banco de dados. Isso proporciona um ponto único que você poderá restaurar posteriormente. É possível fazer um backup completo do banco de dados usando o comando BACKUP DATABASE. Examine os Manuais Online em busca de exemplos. Tendo em vista uma maior proteção, é possível usar a opção WITH CHECKSUM, que verifica as somas de verificação (caso estejam presentes) das páginas lidas e calcula a soma de verificação em relação ao backup inteiro. Você deve optar por uma freqüência que reflita a margem de perda de dados ou de trabalho com a qual a empresa se sente confortável. Por exemplo, fazer um backup completo do banco de dados uma vez por dia significa que você pode perder até um dia de dados em caso de desastre. Caso só esteja usando backups completos de bancos de dados, você deve estar no modelo de recuperação SIMPLES (normalmente chamado de modo de recuperação) para evitar as complicações relacionadas ao gerenciamento do aumento do log de transações.
Segundo, sempre mantenha os backups por alguns dias caso haja danos em um – um backup feito há alguns dias é melhor do que nada. Você também deve verificar a integridade dos backups usando o comando RESTORE WITH VERIFYONLY (novamente, consulte os Manuais Online). Se você estiver usado a opção WITH CHECKSUM quando o backup for criado, a execução do comando de verificação confirmará se a soma de verificação do backup continua válida, além de verificar novamente todas as somas de verificação das páginas do backup.
Terceiro, caso um backup completo diário do banco de dados não permita encontrar a perda máxima de dados/trabalho que a empresa pode suportar, você talvez precise analisar backups de banco de dados diferenciais. Um backup de banco de dados diferencial se baseia em um backup de banco de dados completo e contém um registro de todas as alterações feitas desde o último backup completo do banco de dados (um equívoco comum é achar que os bancos de dados diferenciais são incrementais; eles não são). Uma estratégia simples pode ser fazer o backup completo diário de um banco de dados com um backup diferencial a cada quatro horas. Um backup diferencial fornece uma única opção de recuperação pontual a mais. Caso só esteja usando backups completos de bancos de dados, você deve continuar usando o modelo de recuperação SIMPLES.
Por fim, a última palavra em termos de recuperação vem do uso dos backups de log. Eles só estão disponíveis nos modelos de recuperação COMPLETOS (ou BULK_LOGGED) e fornecem um backup de todos os registros em log gerados desde o backup do log anterior. A manutenção de um conjunto de backups de log com backups completos de banco de dados (e talvez do banco de dados diferencial) garante um número ilimitado de pontos de recuperação – inclusive a recuperação minuto a minuto. O dilema é que o log de transações continuará aumentando até ser "liberado" por um backup de log. Uma estratégia de exemplo aqui seria um backup completo do banco de dados todos os dias, um backup do banco de dados diferencial a cada quatro horas e um backup de log a cada meia hora.
Decidir uma estratégia de backup e configurá-la pode ser complicado. Na pior das hipóteses, você deve contar com um backup completo de banco de dados regular para garantir que tenha, pelo menos, um ponto de recuperação.
Como se pode ver, para garantir a integridade e a disponibilidade do banco de dados, existem algumas tarefas "a serem cumpridas". Esta é a minha lista de verificação final para um DBA involuntário assumindo um banco de dados:
  • Remova a fragmentação excessiva do arquivo de log de transações.
  • Defina corretamente o aumento automático.
  • Desative todas as operações de redução agendadas.
  • Ative a inicialização de arquivo instantânea.
  • Estabeleça um processo regular para detectar e remover a fragmentação do índice.
  • Ative AUTO_CREATE_STATISTICS e AUTO_UPDATE_STATISTICS, além de ter um processo regular para atualizar estatísticas.
  • Ative as somas de verificação de página (ou pelo menos a detecção de página interrompida no SQL Server 2000).
  • Mantenha um processo regular para executar DBCC CHECKDB.
  • Mantenha um processo regular para fazer backups completos do banco de dados, além de backups de log e diferenciais para recuperação pontual.
Usei comandos T-SQL no artigo, mas é possível fazer muito com o Management Studio também. Espero ter apresentado alguns ponteiros úteis para uma manutenção eficiente de bancos de dados. Em caso de dúvidas ou comentários, me escreva – paul@sqlskills.com.

Paul S. Randal é diretor administrativo da SQLskills.com e MVP em SQL Server. Trabalhou na equipe do mecanismo de armazenamento do SQL Server da Microsoft de 1999 a 2007. Paul é especialista em recuperação de desastres, alta disponibilidade e manutenção de bancos de dados. Ele bloga em SQLskills.com/blogs/paul.

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


Administração do Windows
Avaliando o desempenho do seu servidor
Steven Choy
Visão geral:
  • Como personalizar o Desempenho do Sistema
  • Diretrizes sobre o que medir e com que freqüência
  • Uma visão geral dos principais contadores e do que procurar

Sumário
Como tornar os resultados mais legíveis
O que e quando medir
Afunilamento de disco rígido
Afunilamento de memória
﻿Afunilamento de processador
Afunilamento de rede
Afunilamento de processo
Conclusão
Imagine que você acaba de chegar ao escritório em uma manhã de segunda-feira e é recebido por um usuário ansioso, reclamando da lentidão de seu servidor. Por onde começar para ajudá-lo? O Desempenho
do Sistema, uma ferramenta muito útil incorporada ao Windows®, pode ajudá-lo a diagnosticar o problema.
Você pode acessar o Desempenho do Sistema digitando perfmon no prompt de comando, ou então selecionando o Desempenho do Sistema (ou o Monitor de Desempenho e Confiança, no Windows Vista® e no Windows Server® 2008) no menu Ferramentas Administrativas. Para adicionar contadores de desempenho e objetos a serem monitorados, basta clicar no sinal de adição e selecionar uma entre as diversas opções disponíveis.
Então, como avaliar o funcionamento de um servidor? Há mais de 60 objetos básicos de desempenho, e cada um deles contém vários contadores. Neste artigo, abordarei os contadores que revelam os sinais vitais de um servidor e descreverei os intervalos típicos de amostragem normalmente utilizados pelos engenheiros do Suporte aos Serviços Microsoft® para solucionar problemas relacionados ao desempenho.
Logicamente, uma linha de base representa um ponto de referência essencial para a solução de problemas. Como a carga do servidor depende dos requisitos comerciais e também varia de tempos em tempos, dependendo do ciclo de negócios, é importante estabelecer uma linha de base, determinada pela carga de trabalho normal em um período especificado. Isso permite observar alterações e identificar tendências.

Como tornar os resultados mais legíveis
Antes de me aprofundar na análise dos contadores que representam os sinais vitais dos servidores, explicarei dois truques que facilitam a medição desses sinais vitais usando o Desempenho do Sistema. Observe que esses truques não são necessários no Windows Vista e no Windows Server 2008. Mas, se você estiver executando o Desempenho do Sistema em versões anteriores do Windows, eles poderão ser muito úteis.
Primeiro, você pode remover todos os ruídos produzidos por exemplos irrelevantes que obscurecem a exibição gráfica das linhas de tendência. No Windows Vista e no Windows Server 2008, o Desempenho do Sistema pode exibir até 1.000 pontos de dados na visualização gráfica. Nas versões anteriores do Windows, o limite era de apenas 100 pontos de dados. Quando há mais de 100 pontos, o Desempenho do Sistema classifica os pontos de dados. Uma classificação é representada por uma linha vertical indicando os valores mínimo, médio e máximo dos pontos de exemplo incluídos.
Como você pode ver no gráfico da Figura 1, é difícil identificar a linha de tendência quando há tantos dados exibidos ao mesmo tempo. O gráfico da Figura 2 mostra como é bem mais fácil compreender rapidamente os dados quando todas as informações visuais irrelevantes são desativadas. Para obter mais detalhes sobre como desativar essas linhas verticais, consulte o artigo da Base de Dados de Conhecimento disponível em support.microsoft.com/kb/283110.
Figura 1. Dados de desempenho mostrados com classificações irrelevantes e sem vírgulas (clique na imagem para ampliá-la)
Figura 2. Uma exibição mais clara dos dados, separados por vírgulas (clique na imagem para ampliá-la)
O segundo truque consiste em adicionar a separação por vírgulas aos números, tornando muito mais fácil ler os valores mostrados nos contadores. O Windows Vista e o Windows Server 2008 têm a separação por vírgulas habilitada por padrão. Contudo, nas versões anteriores do Windows, o Desempenho do Sistema não habilita as vírgulas por padrão.
Talvez não pareça que isso fará uma grande diferença, mas observe a Figura 1, que mostra os contadores de desempenho sem vírgulas, e depois a Figura 2, que mostra os contadores com vírgulas. Considero a segunda versão muito mais legível. Para obter instruções mais simples sobre como adicionar a separação por vírgulas aos seus contadores de desempenho no Windows XP, consulte o artigo da Base de Dados de Conhecimento em support.microsoft.com/kb/300884.

O que e quando medir
Os afunilamentos ocorrem quando um recurso alcança o limite da sua capacidade, reduzindo o desempenho de todo o sistema. Os afunilamentos geralmente são causados por recursos insuficientes ou mal configurados, componentes com funcionamento incorreto e solicitações incorretas de recursos por parte de um programa.
Há cinco áreas principais de recursos que podem causar afunilamentos e afetar o desempenho do servidor: disco físico, memória, processo, CPU e rede. Se qualquer um desses recursos for utilizado em excesso, o servidor ou o aplicativo poderá ficar muito lento ou até falhar. Examinarei cada uma dessas cinco áreas, fornecendo diretrizes sobre os contadores que você deve usar e oferecendo sugestões de limites para avaliar o desempenho dos seus servidores.
Como o intervalo de amostragem tem um impacto considerável sobre o tamanho do arquivo de log e a carga do servidor, você deve defini-lo com base na média de tempo decorrido até a ocorrência do problema, de forma a estabelecer uma linha de base antes que ele ocorra novamente. Isso permitirá identificar qualquer tendência que conduza ao problema.
Quinze minutos serão uma boa janela para estabelecer uma linha de base durante as operações normais. Defina um intervalo de amostragem de 15 segundos se a média de tempo decorrido até a ocorrência do problema for de cerca de quatro horas. Se o tempo até a ocorrência do problema for de oito horas ou mais, defina um intervalo de amostragem de pelo menos cinco minutos. Caso contrário, você terá um arquivo de log grande demais, dificultando a análise dos dados.

Afunilamento de disco rígido
Como o sistema de disco armazena e manipula os programas e os dados no servidor, um afunilamento que afete o uso e a velocidade do disco terá um grande impacto sobre o desempenho geral do servidor.
Observe que, se os objetos de disco não tiverem sido habilitados no seu servidor, você precisará usar a ferramenta de linha de comando Diskperf para habilitá-los. Observe também que % Tempo de Disco pode exceder os 100% e, por isso, eu prefiro usar % Tempo Ocioso, Média de Disco s/Leitura e Média de Disco s/Gravação para obter uma visão mais precisa do nível de ocupação do disco rígido. Você encontra mais informações sobre % Tempo de Disco no artigo da Base de Dados de Conhecimento disponível em support.microsoft.com/kb/310067.
A seguir, estão os contadores que os engenheiros do Suporte aos Serviços Microsoft utilizam para o monitoramento de disco.
LogicalDisk\% Espaço Livre Mede a porcentagem de espaço livre na unidade lógica de disco selecionada. Fique atento se cair abaixo de 15%, pois você corre o risco de ficar sem espaço livre para o armazenamento de arquivos críticos pelo sistema operacional. Uma solução óbvia para esse problema é acrescentar mais espaço em disco.
PhysicalDisk\% Tempo Ocioso Mede a porcentagem de tempo de inatividade do disco durante o intervalo de amostragem. A queda do contador abaixo de 20% significa que o sistema de disco está saturado. Avalie a possibilidade de substituir o sistema de disco atual por um mais rápido.
PhysicalDisk\Média de Disco s/Leitura Mede o tempo médio, em segundos, para a leitura de dados no disco. Um número maior do que 25 ms (milissegundos) significa que o sistema de disco está apresentando latência na leitura do disco. Em servidores de missão crítica que hospedam o SQL Server® e o Exchange Server, o limite aceitável é muito menor, de cerca de 10 ms. A solução mais lógica é substituir o sistema de disco atual por um mais rápido.
PhysicalDisk\Média de Disco s/Gravação Mede o tempo médio, em segundos, para a gravação de dados no disco. Um número maior do que 25 ms significa que o sistema de disco está apresentando latência ao gravar no disco. Em servidores de missão crítica que hospedam o SQL Server e o Exchange Server, o limite aceitável é muito menor, de cerca de 10 ms. Provavelmente, a solução é substituir o sistema de disco por um mais rápido.
PhysicalDisk\Comprimento Médio da Fila de Disco Indica quantas operações de E/S aguardam a disponibilidade do disco rígido. Um valor maior do que o número de eixos mais dois significa que o afunilamento pode ser o disco propriamente dito.
Memória\Bytes de Cache Indica a quantidade de memória usada pelo cache do sistema de arquivos. Pode haver um afunilamento de disco se o valor for superior a 200 MB.

Afunilamento de memória
A insuficiência de memória geralmente se deve à RAM insuficiente, a um vazamento de memória ou a uma chave de memória colocada dentro de boot.ini. Antes de analisar os contadores de memória, abordarei a chave /3GB.
A presença de mais memória reduz a atividade de E/S do disco e, conseqüentemente, melhora o desempenho dos aplicativos. A chave /3GB foi introduzida no Windows NT® como uma maneira de fornecer mais memória aos programas de modo de usuário.
O Windows usa um espaço de endereço virtual de 4 GB (independentemente da quantidade de RAM física presente no sistema). Por padrão, os 2 GB inferiores são reservados para os programas de modo de usuário e os 2 GB superiores, para os programas de modo kernel. Com a chave /3GB, 3GB são fornecidos aos processos de modo de usuário. Logicamente, isso causa impacto sobre a memória do kernel, que terá apenas 1 GB de espaço de endereço virtual. Isso pode causar problemas, pois os Bytes de Pool Não-Paginável, os Bytes de Pool Paginável, as Entradas Livres de Tabela de Paginação do Sistema e o heap de área de trabalho ficam "apertados" nesse espaço de 1 GB. Assim, a chave /3GB somente deve ser usada após testes detalhados do seu ambiente.
Isso deve ser levado em conta se você suspeitar que está experimentando um afunilamento relacionado à memória. Se a chave /3GB não for a causa dos problemas, você poderá usar os contadores a seguir para diagnosticar um possível afunilamento de memória.
Memória\% Bytes Confirmados em Uso Mede a taxa de Bytes Confirmados em relação ao Limite de Confirmação — em outras palavras, a quantidade de memória virtual em uso. Um número maior do que 80% indica memória insuficiente. A solução óbvia é o acréscimo de mais memória.
Memória\% Mbytes Disponíveis Mede a quantidade de memória física, em megabytes, disponível para executar processos. Um valor menor do que 5% do total de RAM física significa que a memória é insuficiente, e isso pode aumentar a atividade de paginação. Para resolver esse problema, basta adicionar mais memória.
Memória\Entradas Livres de Tabela de Paginação do Sistema Indica o número de entradas de tabela de paginação que não estão atualmente em uso pelo sistema. Se o número for menor do que 5.000, pode haver um vazamento de memória.
Memória\Bytes de Pool Não-Paginável Mede o tamanho, em bytes, do pool não-paginável. Essa é uma área da memória do sistema para objetos que não podem ser gravados em disco, mas que devem permanecer na memória física enquanto estiverem alocados. Se o valor for maior do que 175 MB (ou 100 MB, com a chave /3GB), pode haver um vazamento de memória. Uma típica Identificação do Evento 2019 é registrada no log de eventos do sistema.
Memória\Bytes de Pool Paginável Mede o tamanho, em bytes, do pool paginável. Essa é uma área da memória do sistema usada para objetos que podem ser gravados em disco quando não estão em uso. Se o valor for maior do que 250 MB (ou 170 MB, com a chave /3GB), pode haver um vazamento de memória. Uma típica Identificação do Evento 2020 é registrada no log de eventos do sistema.
Memória\Páginas por Segundo Mede a taxa na qual as páginas são lidas ou gravadas em disco para resolver falhas de páginas de hardware. Se o valor for maior do que 1.000, como resultado da paginação excessiva, pode haver um vazamento de memória.

﻿Afunilamento de processador
A sobrecarga do processador pode se dever à potência insuficiente do próprio processador, ou então a um aplicativo ineficiente. Você precisa verificar se o processador gasta muito tempo com a paginação, devido à memória física insuficiente. Ao investigar um possível afunilamento de processador, os engenheiros do Suporte aos Serviços Microsoft utilizam os contadores a seguir.
Processador\% Tempo do Processador Mede a porcentagem do tempo decorrido gasto pelo processador na execução de um thread ocupado. Se a porcentagem for superior a 85%, o processador está sobrecarregado, e pode ser que o servidor precise de um processador mais rápido.
Processador\% Tempo de Usuário Mede a porcentagem do tempo decorrido gasto pelo processador no modo de usuário. Se o valor for elevado, o servidor está ocupado com o aplicativo. Uma possível solução é otimizar o aplicativo que está utilizando os recursos do processador.
Processador\% Tempo de Interrupção Mede o tempo que o processador gasta para receber e fazer a manutenção de interrupções de hardware durante intervalos de amostragem específicos. Se o valor for maior do que 15%, o contador indica um possível problema de hardware.
Sistema\Comprimento da Fila de Processador Indica o número de threads na fila do processador. Se o valor for superior a duas vezes o número de CPUs por um período extenso, isso indica que o servidor não conta com capacidade de processamento suficiente.

Afunilamento de rede
Logicamente, um afunilamento de rede afeta a capacidade do servidor de enviar e receber dados via rede. Pode ser um problema na placa de rede do servidor, ou talvez a rede esteja saturada e precise ser segmentada. Você pode usar os contadores a seguir para diagnosticar possíveis afunilamentos de rede.
Interface de Rede\Total de Bytes/s Mede a taxa pela qual bytes são enviados e recebidos por cada adaptador de rede, inclusive caracteres de enquadramento. Se você descobrir que mais de 70% da interface é consumida, isso significa que a rede está saturada. Para uma placa de interface de rede de 100 Mbps, a interface consumida é de 8,7 MB/s (100 Mbps = 100.000 kbps = 12,5 MB/s* 70%). Em uma situação assim, talvez você queira adicionar uma placa de rede mais rápida ou segmentar a rede.
Interface de Rede\Comprimento da Fila de Saída Mede, em pacotes, o comprimento da fila de saída de pacotes. Existe saturação da rede se o valor for superior a 2. Você pode solucionar esse problema acrescentando uma placa de rede mais rápida ou segmentando a rede.

Afunilamento de processo
O desempenho do servidor será afetado consideravelmente se você tiver um processo de comportamento inadequado ou processos não-otimizados. Vazamentos de threads e identificadores causarão, em algum momento, a interrupção do funcionamento do servidor, e o uso excessivo do processador levará ao rastreamento do servidor. Os contadores a seguir são indispensáveis para diagnosticar afunilamentos relacionados a processos.
Processo\Número de Identificadores Mede o número total de identificadores abertos por um processo no momento. Se o valor for maior do que 10.000, o ﻿contador indica um possível vazamento de identificadores.
Processo\Contagem de Threads Mede o número total de threads ativos em um processo no momento. Pode haver um vazamento de threads se esse número for superior a 500, entre os números mínimo e máximo de threads.
Processo\Bytes Particulares Indica a quantidade de memória que o processo alocou e que não pode ser compartilhada com outros processos. Pode haver um vazamento de memória se o valor for superior a 250, entre os números mínimo e máximo de threads.

Conclusão
Agora, você já sabe que contadores os engenheiros do Suporte aos Serviços Microsoft utilizam para diagnosticar diversos afunilamentos. Logicamente, você terá seu próprio conjunto de contadores favoritos, adaptados de acordo com as suas necessidades específicas. Talvez você queira economizar tempo, eliminando a necessidade de adicionar todos os seus contadores favoritos manualmente sempre que precisar monitorar os servidores. Felizmente, existe uma opção no Desempenho do Sistema que permite salvar todos os seus contadores em um modelo para uso posterior.
Talvez você ainda esteja em dúvida se deve executar o Desempenho do Sistema local ou remotamente. E qual será o impacto exato sobre o desempenho ao executá-lo localmente? Isso depende do seu ambiente específico. O impacto sobre o desempenho no servidor será praticamente imperceptível se você definir intervalos de pelo menos cinco minutos.
Talvez você prefira executar o Desempenho do Sistema localmente se souber que há um problema de desempenho no servidor, pois é possível que ele não consiga capturar dados de um computador remoto quando os recursos do servidor estiverem se esgotando. Executá-lo remotamente, a partir de um computador central, é uma abordagem mais adequada para situações em que você queira monitorar ou estabelecer uma linha de base para vários servidores.

Steven Choy é engenheiro-chefe de campo sênior do departamento de engenharia de campo de ponta da Microsoft. Ele prestou suporte a agências governamentais e clientes comerciais em seus projetos de implantação e migração de desktops, gerenciamento de patches e Diretiva de Grupo. Atualmente, está concentrado na virtualização e na integridade de servidores.


System Center
O Windows PowerShell no System Center Operations Manager
Marco Shaw
Visão geral:
  • O shell de comando do OpsMgr
  • O provedor de monitoramento do OpsMgr
  • Automação de tarefas administrativas comuns
  • Alguns exemplos reais de uso do Windows PowerShell

Sumário
O shell de comando do Operations Manager
O provedor de monitoramento do OpsMgr
Automação de tarefas comuns
Exemplos reais
Conclusão
O OpsMgr (System Center Operations Manager 2007) permitiu aos administradores o acesso ao Windows PowerShell, uma nova e poderosa linguagem de scripts para a automação de tarefas. Desde seu lançamento, em novembro de 2006, já foi baixado mais de dois milhões de vezes.
Neste artigo, abordarei o Windows PowerShell® e como ele se aplica ao Operations Manager. Tratarei de algumas tarefas comuns que o Windows PowerShell pode ajudá-lo a realizar de forma muito mais simples e automatizada, e também indicarei alguns sites que fornecem scripts e explicações úteis. Reuni publicações em blogs e idéias de muitos especialistas que utilizam atualmente o Windows PowerShell.
Embora a Microsoft já tenha começado a lançar as versões CTP (Community Technology Preview) do Windows PowerShell 2.0, essas versões ainda não estão prontas para a produção, não foram testadas com o OpsMgr e não devem ser instaladas em um sistema de produção.

O shell de comando do Operations Manager
No OpsMgr, o Windows PowerShell é acessado por meio do shell de comando, que é semelhante ao ambiente padrão do Windows PowerShell, exceto pelo fato de carregar um arquivo de console e um script que inicializa o ambiente com os cmdlets, as funções e uma conexão padrão do OpsMgr.
Você pode iniciar o shell de comando a partir de um ícone no menu Iniciar do OpsMgr ou clicando com o botão direito do mouse em um nome de computador no console da interface do usuário do OpsMgr (veja a Figura 1). Isso o colocará diretamente no caminho da unidade Monitoring do OpsMgr (que abordarei em breve).
Figura 1. Abrindo o shell de comando a partir da interface do usuário do OpsMgr (clique na imagem para ampliá-la)
O Windows PowerShell faz interface com o OpsMgr via SDK do OpsMgr. Felizmente para os administradores, já foram fornecidos cmdlets para muitas das tarefas que eles geralmente gostariam de automatizar ou concluir usando uma linha de comando. Se não houver um cmdlet para uma tarefa específica, é possível usar o Windows PowerShell para interagir com o SDK.
Os comandos fornecidos pelo shell de comando do Operations Manager estão contidos em um snap-in — uma DLL carregada pelo Windows PowerShell que contém cmdlets para a administração do OpsMgr. O snap-in inclui também o provedor OperationsManagerMonitoring do Windows PowerShell. Essa ferramenta, também conhecida como provedor de monitoramento, permite a navegação em conexões, grupos e objetos de monitoramento, de forma muito semelhante à navegação no sistema de arquivos.
É possível obter uma lista de todos os cmdlets específicos do OpsMgr usando o cmdlet Get-OperationsManagerCommand, conforme mostrado na Figura 2 (na primeira versão, essa era uma função que não oferecia suporte à conclusão de tabulação; tornou-se um cmdlet no SP1). A versão original do Operations Manager incluía 74 cmdlets; já o OpsMgr SP1 tem 87.
Figura 2. Obtendo uma lista de cmdlets do OpsMgr (clique na imagem para ampliá-la)

O provedor de monitoramento do OpsMgr
Utilizando o cmdlet Set-Location ou o alias cd, você pode navegar pelo layout de grupos e computadores. O layout de base da unidade Monitoring padrão tem esta aparência:
Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)
Partindo daqui, você pode obter objetos mais específicos. Observe que estou lidando apenas com um ambiente simples neste caso, onde há um único servidor de gerenciamento. O primeiro servidor de gerenciamento instalado em um grupo de gerenciamento é conhecido como RMS (Servidor de Gerenciamento Raiz).
Quando o shell de comando é iniciado, ele cria uma unidade chamada Monitoring, mapeia essa unidade para a raiz do provedor OperationsManagerMonitoring e, por fim, define o local ou o caminho atual na raiz da unidade Monitoring. Então, o shell de comando procura, no Registro, o nome do RMS padrão ao qual deverá conectar-se. Se a conexão com o RMS for bem-sucedida, o local ou o caminho atual será definido com o nome da conexão, ou do RMS, conforme mostrado na Figura 3.
Figura 3. A localização do shell de comando é definida como o RMS (clique na imagem para ampliá-la)

Automação de tarefas comuns
Vejamos como o Windows PowerShell é capaz de lidar com algumas das tarefas administrativas mais comuns.
Controlar o modo de manutenção Seja qual for a tarefa que esteja gerenciando, geralmente você desejará especificar a data e a hora em que ela deverá ocorrer. Farei uma descrição resumida do cmdlet Get-Date para mostrar como isso é fácil. A Figura 4 mostra alguns exemplos.
Figura 4. Usando o cmdlet Get-Date (clique na imagem para ampliá-la)
Como você pode ver, criei uma variável $date que contém um objeto representando a hora atual. Então, usei alguns métodos documentados com suporte do objeto para mostrar como se pode obter facilmente a data e a hora cinco minutos depois, e também cinco horas depois. Se eu quisesse obter valores do passado, simplesmente usaria (-5) em vez de (5).
Quando precisa bloquear todos os alertas de um computador, você pode habilitar o modo de manutenção. O OpsMgr 2007 permite colocar um serviço do Windows®, ou mesmo um banco de dados específico, no modo de manutenção, em vez de colocar um computador ou um grupo inteiro. Há três cmdlets que lidam especificamente com as tarefas do modo de manutenção: Get-MaintenanceWindow, New-MaintenanceWindow e Set-MaintenanceWindow.
Para colocar um computador no modo de manutenção a partir do shell de comando, navegue até o computador ou o objeto de monitoramento desejado usando o provedor de monitoramento e invoque o cmdlet New-MaintenanceWindow, conforme mostrado na Figura 5. Como você pode ver, essa ação coloca o computador chamado Denver.contoso.com em modo de manutenção. Também defini a hora de início da janela de manutenção para entrar em vigor imediatamente, e a hora de término para entrar em vigor exatamente uma hora depois. Observe que colocar um computador em modo de manutenção usando esse método não interrompe todos os alertas, pois as instâncias HealthService e HealthServiceWatcher do objeto ainda estão habilitadas.
Figura 5. Usando o cmdlet New-MaintenanceWindow (clique na imagem para ampliá-la)
Boris Yanushpolsky, gerente de programa da equipe do Microsoft OpsMgr, forneceu um código muito útil do Windows PowerShell, que pode ser usado para colocar todos os objetos relacionados a um computador em modo de manutenção, e explicou como usá-lo depois que você criar um script. Para ler mais sobre o assunto, visite seu blog em blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.
Algumas vezes, é preciso determinar se há objetos no modo de manutenção que não deveriam estar. No entanto, percorrer todos os objetos na tentativa de descobrir isso pode ser uma empreitada muito trabalhosa. Felizmente, Boris Yanushpolsky mais uma vez traz a solução, com um script do Windows PowerShell que usa o SDK do OpsMgr. Você pode obter o código diretamente na postagem do seu blog (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) e colá-lo em uma janela do shell de comando para obter uma listagem de todos os objetos em modo de manutenção.
Quando um objeto estiver em modo de manutenção, talvez você queira encerrar o período de manutenção antes da hora de término originalmente especificada. Se você está familiarizado com o Windows PowerShell, talvez espere um cmdlet com um verbo de interrupção ou remoção, mas na verdade deve usar Set-MaintenanceWindow, como na Figura 6.
Figura 6. Usando Set-MaintenanceWindow para alterar a hora de término (clique na imagem para ampliá-la)
Gerenciar agentes Os administradores normalmente trabalham com agentes, e há seis cmdlets e uma função (no momento do lançamento) para lidar com diversas tarefas relacionadas a agentes. Você pode obter uma lista deles com este comando:
Get-Command *-agent*
No momento do lançamento do SP1, Install-AgentByName é fornecido como um cmdlet, e não como uma função. É recomendável que você use o cmdlet Install-AgentByName, pois ele proporciona uma base melhor em termos de suporte e consistência.
A ajuda interna incluída no shell de comando traz alguns bons exemplos de uso dos cmdlets Install-Agent e Uninstall-Agent. Roger Sprague, engenheiro sênior de design de software da equipe do Microsoft OpsMgr, postou em seu blog um método alternativo, reproduzido na Figura 7 (veja a postagem original em blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).
Esse script funciona bem com o OpsMgr RTM (você precisa estar localizado na raiz do provedor de monitoramento — neste artigo, é monitoring:\oxford.contoso.com), mas falha com o OpsMgr SP1. Para fazê-lo funcionar com o OpsMgr SP1, é preciso trocar o primeiro comando da Figura 7 pelo seguinte:
$managementServer = Get-RootManagementServer
Figura 7. Instalando um agente
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects
Neste ponto, o agente é instalado no sistema remoto que deve ser monitorado, mas ainda há uma última etapa, na qual o servidor de gerenciamento deve realmente aceitar o novo agente, antes que ele seja completamente monitorado. Se nenhuma ação adicional for realizada, o servidor de monitoramento aceitará automaticamente o novo agente para monitoramento. Mas esse processo de aceitação também pode ser acelerado com o uso do cmdlet Get-AgentPendingAction. Esta única linha de código irá acelerar o processo de aceitação do agente:
Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
Canalizando isso para Reject-AgentPendingAction, em vez de Approve-AgentPendingAction, você pode bloquear a aceitação do agente pelo servidor do OpsMgr, se a ação ainda estiver pendente. Se não estiver pendente, use o cmdlet Uninstall-Agent.
Como já mencionei, também é possível usar Install-AgentByName para especificar um computador diretamente na linha de comando onde o agente deve ser instalado.
Trabalhar com pacotes de gerenciamento Há quatro cmdlets para ajudá-lo a lidar com várias tarefas relacionadas a pacotes de gerenciamento. Você pode listá-los usando:
Get-Command –noun ManagementPack
Este comando simples apresenta os pacotes de gerenciamento atualmente instalados e seus números de versão:
Get-ManagementPack | Format-Table –autosize
Agora, utilizarei o shell de comando para instalar dois pacotes de gerenciamento comuns com estes instaladores:
  • Internet Information Services System Center Operations Manager2007 Management Pack.msi
  • Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.
Uma vez que meu objetivo é mostrar a forma como o shell de comando pode tornar mais simples as tarefas cotidianas, farei isso usando a menor quantidade possível de comandos (conforme mostrado na Figura 8). Eu poderia ter alterado o procedimento de instalação para passar o sinalizador silencioso para o instalador (os arquivos .msi), mas preferi selecionar manualmente o local onde os arquivos seriam extraídos.
Figura 8. Instalando pacotes de gerenciamento (clique na imagem para ampliá-la)
Em seguida, preciso instalar as bibliotecas comuns, o que pode ser feito com o seguinte:
Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
Depois, instalo os outros pacotes de gerenciamento necessários:
Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
Conforme mostrado na Figura 9, a ajuda interna do shell de comando traz um ótimo exemplo de uso do cmdlet Export-ManagementPack para exportar pacotes de gerenciamento sem lacre. Se você quiser exportar todos os pacotes de gerenciamento, altere esta linha:
$mps=Get-ManagementPack |
Where-Object {$_.Sealed –eq $false}

$mps=Get-ManagementPack
Figura 9. Exportando um pacote de gerenciamento (clique na imagem para ampliá-la)
Manipular funções de usuários O cmdlet Get-UserRole oferece alguns recursos para a administração de usuários. No entanto, por estranho que pareça, não vem com um cmdlet Set complementar e, em geral, você não vai utilizá-lo para fazer edições ou atualizações (de acordo com a documentação do SDK do Windows PowerShell). Como você pode ver na Figura 10, eu primeiro obtenho uma listagem das atuais funções de usuários, para depois adicionar um usuário ao grupo de operadores somente leitura (veja a Figura 11).
Figura 10. Exibindo funções de usuários (clique na imagem para ampliá-la)
Figura 11. Adicionando um usuário (clique na imagem para ampliá-la)
Habilitar o ACS (Audit Collection Services) O ACS é um novo recurso opcional do Operations Manager 2007 que, em suma, proporciona uma forma centralizada para lidar com informações de auditoria de segurança. O ACS não é habilitado por padrão e, em geral, pode ser configurado mais tarde, em uma fase futura da implementação do OpsMgr.
Quando chega a hora de habilitar uma grande quantidade de agentes para o ACS, o Windows PowerShell ajuda a automatizar a configuração. Na versão beta do OpsMgr, a Microsoft forneceu um script para habilitar o ACS em todos os agentes. Neale Browne, contribuidora e blogger do SystemCenterForum.org, levou essa questão um passo adiante e acrescentou suporte para parâmetros adicionais.
O site SystemCenterForum.org (um site da comunidade que fornece soluções para o Microsoft® System Center) criou dois scripts diferentes para o Windows PowerShell, que estão disponíveis para automatizar a configuração do ACS. Para configurar todos os agentes de um grupo específico, use systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Para configurar todos os agentes monitorados, baixe systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip.
Habilitar a atuação de agentes como proxy Seu ambiente OpsMgr pode incluir dispositivos monitorados sem agentes. Esses dispositivos precisam ser atribuídos a um servidor de gerenciamento ou a um dispositivo gerenciado por agente, que realizará o monitoramento remoto. Você encontra uma descrição detalhada do uso de um script do Windows PowerShell para configurar uma grande quantidade de agentes em systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell. Há uma versão atualizada do script disponível em systemcenterforum.org/wp-content/uploads/Set-AgentProxyBulk_FQDN.zip.
Existem também outras condições nas quais pacotes de gerenciamento específicos requerem que um agente seja configurado para atuar como um proxy. Consulte a documentação do pacote de gerenciamento para obter mais detalhes.

Exemplos reais
Eis aqui alguns exemplos reais para demonstrar em mais detalhes a forma como o Windows PowerShell pode auxiliar na automação.
Solucionar alertas Você já precisou excluir vários alertas de um computador específico? Talvez tenha ocorrido algo de errado em um aplicativo, ou então os alertas não estavam sendo solucionados ativamente. Este comando de uma só linha solucionará todos os alertas com estado de resolução zero:
Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null
O próximo exemplo cumpre a mesma função do anterior, mas será executado com muito mais rapidez em um ambiente maior, com mais alertas pendentes:
Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
O motivo da diferença de desempenho é que, quando o parâmetro de critérios é usado, o valor transmitido é fornecido diretamente ao banco de dados do SQL Server®, e somente os dados relevantes são retornados. Isso reduz a quantidade de objetos a serem transmitidos de volta ao console do Windows PowerShell.
Agora, você conta com uma forma rápida de remover todos os alertas pendentes de um computador. Dependendo das suas necessidades, você poderá configurar essa função para ser executada automaticamente.
Por fim, eis um comando rápido que permite exibir todos os alertas de um dia específico:
Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''
Você pode alterar facilmente o valor da data e canalizar a saída para o cmdlet Resolve-Alert.
Testar alertas Algumas vezes, você quer monitorar determinados eventos no Visualizador de Eventos do Windows e realizar testes a partir deles. Estas duas linhas criarão uma entrada rápida no log de eventos:
$api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")
No entanto, por padrão, a gravação será feita no log de eventos do Operations Manager, que provavelmente não é o local onde você esperaria que um evento específico fosse registrado. Felizmente, Stefan Stranger, engenheiro-chefe de campo da Microsoft, escreveu um script para criar eventos no Visualizador de Eventos do Windows que oferece mais flexibilidade, por ser capaz de gravar em um log específico. Você encontra o script em go.microsoft.com/fwlink/?LinkId=120308. (Stefan empacotou o script em um arquivo .cab; você precisará baixar o arquivo e depois clicar nele com o botão direito do mouse para extrair o script).
A única observação importante a respeito do script de Stefan é que o valor inserido para a origem do evento determina em que log a entrada será gravada. Talvez a forma mais simples de garantir que um alerta seja direcionado para o log adequado seja abrindo o Visualizador de Eventos do Windows e localizando a origem da última entrada.
Definir o proprietário Algumas vezes, pode ser útil definir automaticamente o proprietário de um alerta. Eis uma forma simples de fazer isso a partir do shell de comando:
$alert = Get-Alert
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
A primeira linha desse código obtém o ID de um objeto de alerta específico e o transmite para a variável $alert. Na segunda linha, essa variável é usada para definir o proprietário, e finalmente a atualização é aplicada ao banco de dados do OpsMgr. Se você verificar o proprietário do alerta com o comando a seguir, verá a alteração:
Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner
Para definir o proprietário de todo um conjunto de alertas, você pode simplificar o código assim:
Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}
Restaurar o estado de monitoramento Provavelmente você já se deparou com agentes em um estado "não monitorado". Quando isso ocorre, pode ser preciso restaurar com rapidez todos os agentes a um estado totalmente monitorado, para depois tentar determinar o que ocorreu. A execução do script na Figura 12 diretamente no shell de comando deve restaurar o monitoramento total dos agentes afetados.
Figura 12. Redefinindo o armazenamento do serviço de integridade
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}
Observe o código na Figura 12. Depois de declarar uma variável, eu obtenho uma lista de todos os agentes neste RMS e filtro os que parecem apresentar problemas. Então, chamo uma tarefa de forma assíncrona para redefinir o armazenamento do serviço de integridade de todos os agentes na lista filtrada.
Associar alertas a pacotes de gerenciamento A Figura 13mostra como obter uma lista de todos os novos alertas, além do pacote de gerenciamento ao qual cada um deles está associado.
O código exigiu o uso de alguns truques para garantir que todos os nomes de pacotes de gerenciamento pudessem ser solucionados. Os cmdlets usados variam, dependendo se o alerta vem de uma regra ou de um monitor. Observe que, na Figura 13, precisei implementar uma solução alternativa para o cmdlet Get-Monitor. No OpsMgr SP1, o cmdlet oferece suporte a um novo parâmetro de ID, que deve simplificar um pouco o código.
Figura 13. Localizando o pacote de gerenciamento
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}
Gerar relatórios com facilidade Quando você atualizar seu ambiente, talvez seja útil fazer a auditoria das versões de todos os agentes instalados. Basta um script simples para imprimir um ótimo relatório:
Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}
A Figura 14 mostra a saída do script. Esse script é uma versão expandida dos exemplos fornecidos em systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.
Figura 14. Saída mostrando as versões de alguns agentes (clique na imagem para ampliá-la)
Programar uma tarefa Talvez você queira executar regularmente um script do Windows PowerShell. Digamos que você use um computador cliente para conectar-se e gerenciar seu servidor do OpsMgr, e que você tenha as ferramentas de administração do OpsMgr instaladas localmente. E suponha, por exemplo, que você queira executar o relatório de versão dos agentes diariamente e salvar a saída em um arquivo tendo a data atual como nome. Você pode usar o agendador de tarefas interno do Windows para executar o script a partir do seu computador local.
Para fazer isso, basta configurar uma nova tarefa com o programa definido como powershell.exe (geralmente localizado em C:\Windows\System32\WindowsPowerShell\v1.0). Depois de criar a tarefa, edite-a e configure o comando para ser executado da seguinte forma:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
No fim das contas, precisei fazer algumas alterações no código original do Windows PowerShell, como você pode ver na Figura 15. Precisei adicionar o snap-in OpsMgr PowerShell, criar a unidade Monitoring mapeada para o provedor OperationsManagerMonitoring e criar uma conexão com o RMS. Também carrego o script do Windows PowerShell personalizado para o OpsMgr (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1) para carregar funções específicas do OpsMgr.
Figura 15. Agendando o script de versões de agentes
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file
Mas isso não é tudo. Talvez você perceba que, sempre que a tarefa é executada, uma janela de console preta aparece na tela se alguém estiver conectado ao sistema onde o script está sendo executado. Você encontra um truque simples para solucionar isso, oferecido por Don Jones e Jeffery Hicks, da Sapien, em blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell.
Basicamente, você precisa encapsular o script em um VBScript. Para fazer isso, é preciso usar código como o exposto na Figura 16, em vez de chamar o seguinte na sua tarefa agendada:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
Figura 16. Ocultando pop-ups
Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0
Agora, a tarefa utilizará o programa wscript.exe, e a chamada terá uma aparência semelhante a isto:
C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs
Finalmente, posso criar relatórios automatizados, e o processo é ocultado dos usuários conectados.

Conclusão
Esta apresentação rápida dos novos recursos de automação disponíveis no OpsMgr 2007 proporciona apenas uma noção superficial de como você pode usar o Windows PowerShell para realizar a administração do OpsMgr.
Eu gostaria de agradecer a todas as pessoas mencionadas no artigo, e também a Pete Zerger, MVP do MOM e fundador do SystemCenterForum.org, por seu valioso auxílio.

Marco Shaw é analista de sistemas de TI de uma empresa canadense de telecomunicações. Ele trabalha no setor de TI há mais de dez anos e recebeu recentemente um prêmio para MVPs do Windows PowerShell. Marco é também o diretor comunitário assistente do novo site da comunidade do PowerShell em powershellcommunity.org. Ele mantém um blog em marcoshaw.blogspot.com.

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


Serviços de Informações da Internet
Dimensionando aplicativos ASP.NET: lições aprendidas
Richard Campbell
Visão geral:
  • A importância da colaboração do desenvolvedor/TI
  • Compreendendo as principais estratégias de dimensionamento
  • Compartilhando o conhecimento entre as equipes
  • Definindo um conjunto básico de conhecimento

Sumário
Os conceitos básicos do dimensionamento
O encontro das idéias
O que o sistema de rede precisa saber quanto ao desenvolvimento
O que o desenvolvimento precisa saber quanto ao sistema de rede
Voltando ao dimensionamento
O combate conjunto a incêndios
Como consultor, todos os aplicativos ASP.NET dimensionados com êxito nos quais já trabalhei foram o resultado de um esforço colaborativo entre os desenvolvedores (quem os criou) e os administradores de rede (quem os executa de fato). Infelizmente, nem sempre fica claro no início do
ciclo de vida de um aplicativo que essa colaboração é essencial. Assim, quase nunca tive uma chance de me envolver no início do ciclo de vida de um aplicativo – apenas no final, quando o problema já existe.
A verdade é que nenhum aplicativo é dimensionado efetivamente na primeira vez – é impossível ter tudo certo desde o começo. Para dimensionar um aplicativo com êxito, você precisa compreender como ele foi criado, bem como de que forma funciona o ambiente operacional em que ele é executado. Em outras palavras, você precisa de informações tanto do pessoal do desenvolvimento quanto do pessoal de rede. Sem esse conhecimento compartilhado, não é possível obter êxito.

Os conceitos básicos do dimensionamento
Antes de nos aprofundarmos, montemos o palco para o que é necessário ao efetivo dimensionamento de um aplicativo ASP.NET. Há duas estratégias básicas empregadas normalmente: especialização e distribuição. E grande parte dos aplicativos ASP.NET grandes, dimensionados, aplicam ambas as estratégias. Além disso, todos os truques existentes por aí para ajudar no dimensionamento do aplicativo ASP.NET acaba se dividindo em uma ou em outra.
A especialização se resume a separar elementos do aplicativo para que eles possam ser dimensionados de maneira independente. Por exemplo, você talvez queira criar servidores de imagens dedicados, e não usar os mesmos servidores que processam páginas ASP.NET. A configuração ideal de um servidor de imagens é bem diferente em relação a um servidor ASP.NET. Além disso, a separação das solicitações de imagem do restante do aplicativo cria a possibilidade de usar recursos de terceiros no oferecimento de imagens. A mesma abordagem pode ser aplicada aos demais arquivos de recurso.
Por outro lado, a distribuição envolve a difusão simétrica do aplicativo em vários servidores, normalmente chamados de web farm. Os aplicativos ASP.NET são especialmente adequados à distribuição porque cada solicitação de página individual é relativamente pequena, e as interações de um determinado usuário são, em grande medida, independentes dos demais usuários. A distribuição é mesmo a manifestação da filosofia de "redução da escala", em que vários servidores de desempenho médio funcionam juntos para atender aos usuários, e não a abordagem de "aumento de escala" em que há único servidor possante fazendo tudo.
A combinação entre especialização e distribuição aumenta a eficiência – é possível distribuir apenas os elementos do aplicativo que precisam de desempenho adicional. Por exemplo, caso você tenha criado servidores de imagens especializados, mas o oferecimento delas continua inadequado, é possível adicionar servidores de imagens, e não servidores para todo o aplicativo. É importante manter essas estratégias em mente enquanto você procura aumentar o desempenho e a escalabilidade do aplicativo ASP.NET.

O encontro das idéias
Em algum ponto do ciclo de vida de todo aplicativo ASP.NET, os desenvolvedores e a equipe de rede/TI devem se encontrar. Com alguma sorte, isso acontecerá antes da implantação do aplicativo, mas às vezes só acontece depois que já há uma crise – por exemplo, quando o aplicativo é executado sem problemas no ambiente de teste, é remetido para os usuários e pára. (É quando chamam consultores como eu.)
Quando os desenvolvedores e o pessoal da rede se encontram, o objetivo principal é trocar informações. Os desenvolvedores têm conhecimento essencial a respeito do aplicativo, assim como a equipe de rede tem sobre o ambiente operacional. Cada grupo precisa compreender os dados do outro, e quanto mais cedo eles se reunirem durante o ciclo de vida do aplicativo, melhor.
Essa reunião não deve ocorrer pela primeira vez durante uma crise. Sem uma compreensão básica entre as duas equipes, é extremamente difícil imaginar por que o aplicativo não está atendendo aos requisitos. Além disso, é muito fácil se defender achando que o problema está única e exclusivamente na outra equipe. E isso simplesmente nunca é verdade – invariavelmente, as duas partes são necessárias para resolver qualquer problema significativamente complexo.
No entanto, mesmo nos bons momentos, uma reunião assim pode ser um grande desafio. As que organizei normalmente começavam com o pessoal da rede de um lado da mesa e o pessoal de desenvolvimento de outro. E um começa a olhar para o outro. Para começar a conversa, ressalto o objetivo da reunião, mais especificamente uma troca de conhecimentos. Não importa quem começa. Começarei com o que o sistema de rede precisa saber do desenvolvimento.

O que o sistema de rede precisa saber quanto ao desenvolvimento
Todo aplicativo ASP.NET tem características próprias, embora haja elementos essenciais que se aplicam a qualquer caso. O arquivo web.config é um deles (veja a Figura 1). Web.config é um ponto de interseção entre o desenvolvimento e o sistema de rede. Às vezes, ele é configurado pelos desenvolvedores e, em outras, pela equipe de rede. De uma forma ou de outra, o conteúdo de web.config estabelece os limites quanto à configuração do hardware e da rede, afetando diretamente o modo de funcionamento do aplicativo. Explorar detalhadamente todos os mínimos aspectos do arquivo web.config seria o bastante para escrever um livro inteiro; aqui, a questão é que ambos os grupos precisam estudar o arquivo web.config e chegar a um consenso quanto ao que a configuração representada por ele significa e em relação ao impacto que várias configurações terão sobre o aplicativo e o ambiente.
Figura 1 Um web.config básico mostrando algumas configurações do aplicativo e uma configuração de erro personalizada (clique na imagem para ampliá-la)
Por exemplo, a seção <authorization> de web.config especifica como os usuários serão autenticados no aplicativo e, assim, define uma dependência. Se o aplicativo usar a autenticação do Windows®, poderá depender do Active Directory®. Caso ele use a autenticação baseada em formulários, a dependência será de um repositório de dados de contas de usuários. Isso certamente vale uma conversa.
A seção <customErrors> é digna de nota porque afeta a maneira como as falhas aparecem para os usuários. Não se trata de uma configuração complexa, mas vale a pena discuti-la apenas para compreender como serão as páginas de erro. Em um momento inicial do ciclo de colaboração, é provável que não haja nenhuma página de erro personalizada – também vale a pena conversar sobre isso.
A seção <appSettings> de web.config pode ser especialmente significativa. É nela que os desenvolvedores costumam armazenar valores globais como cadeias de conexão para bancos de dados. Trata-se de uma grande fonte de dependências, além de ser parte essencial do planejamento de failover, migração etc. Mas, por ser totalmente personalizada, a seção <appSettings> pode conter praticamente qualquer coisa e talvez exija muita explicação para que se compreenda o conteúdo. Quase sempre há órfãos nesta seção – valores que não são, de fato, usados em lugar algum no aplicativo.
Mesmo que os desenvolvedores não estejam usando <appSettings>, o pessoal de rede/operações poderá querer que eles usem – tendo todas as cadeias de conexão de banco de dados, há uma maneira eficiente de criar uma estratégia de failover simples. Caso o servidor do banco de dados seja desativado, poderá ser inserida uma cadeia de caracteres de substituição a fim de apontar para um servidor de banco de dados diferente. Aproveitar essa oportunidade logo no início do ciclo de desenvolvimento pode aumentar a confiabilidade e a facilidade de manutenção do aplicativo.
Por fim, você deve observar que um valor absolutamente essencial no web.config do ponto de vista do dimensionamento é a marca <sessionState>, que determina onde os dados da sessão serão armazenados para o aplicativo. Por padrão, os dados da sessão são armazenados em "InProc", ou no espaço do processo do aplicativo ASP.NET. Caso os dados da sessão estejam configurados como em processo, isso significa que todo balanceamento de carga deve ser "adesivo" – um determinado usuário deve sempre ser atendido pelo mesmo servidor em que os dados da sessão residem. Há uma intensa conversa entre os desenvolvedores e o pessoal de rede porque isso tem impacto direto na forma como você dimensiona e usa o failover. Falar sobre isso logo pode evitar muitas dores de cabeça durante a tentativa de depuração do aplicativo.
Quando a conversa chega ao estado de sessão, é fácil atender aos requisitos do balanceamento de carga do aplicativo em geral. Alguns ambientes contam com hardware para balanceamento de carga dedicado com recursos específicos – mas se o aplicativo não puder tratar esses recursos, eles não significarão muito. Encontrei situações em que o balanceamento de carga do hardware estava sendo usado com um aplicativo ASP.NET que apresentava dados da sessão em processo. A conseqüência foi a perda ocasional de sessões sem nenhuma explicação. Parecia um bug no aplicativo, mas não era – tratava-se de um equívoco na configuração.
O pessoal de rede precisa saber claramente do desenvolvimento quais esquemas de balanceamento de carga funcionarão no aplicativo. Essa é muito mais uma conversa de duas vias a respeito de quais são os esquemas de balanceamento de carga disponíveis, bem como o que o aplicativo pode tolerar. Uma grande vantagem de ter essa conversa logo no início do ciclo de vida do aplicativo é que você poderá planejar com antecedência recorrer a um esquema de balanceamento de carga sem afinidade, fora do processo.
No momento em que um aplicativo ASP.NET estiver pronto para implantação (ou já estiver na implantação inicial), a equipe de desenvolvimento terá uma boa idéia das áreas mais rápidas e mais lentas do aplicativo. E o mais importante: terá uma noção dos afunilamentos ou dos possíveis pontos de crise no sistema. Caso conheça esses afunilamentos, a equipe de rede/operações poderá se preparar para os problemas que se sucederão, e talvez até evitá-los.
Por exemplo, trabalhei uma vez com um aplicativo que apresentava um processo pesado de carga de dados todas as noites, durante o tempo de inatividade. Os desenvolvedores criaram, testaram e compreenderam como o mecanismo de carregamento dos dados funcionava. Eles sabiam que isso era muito desgastante para o banco de dados, embora fosse eficiente e uma boa forma de resolver o problema.
Mas eles jamais disseram à equipe de rede que esse processo ocorria ou que tinham programado sua execução à 1h00 – a mesma hora em que eram executados os backups do banco de dados. Este permanecia online, mas era executado muito mais lentamente durante o backup porque todas as transações enviadas para o banco de dados seriam mantidas no log de transações.
A causa do conflito só foi identificada após a falta de espaço em disco para o log de transações do banco de dados decorrente da combinação entre a carga de dados e o backup simultâneos. Passar o início da carga de dados para as 3h00 resolveu o problema por completo – mas somente depois de vários dias de crise.
Manter uma conversa logo no início a respeito desses tipos de itens da carga de trabalho no aplicativo pode evitar grandes problemas ao longo do caminho.

O que o desenvolvimento precisa saber quanto ao sistema de rede
O meu ponto de partida favorito quanto àquela parte da reunião em que o pessoal de rede explica seu mundo ao pessoal de desenvolvimento é o diagrama de rede. É muito comum que os desenvolvedores vejam a rede como mostra a Figura 2 – ou seja, apenas servidores Web, navegadores e a Internet.
Figura 2 A visão simples do desenvolvedor em relação à rede (clique na imagem para ampliá-la)
É claro que a realidade é muito mais complexa. Um diagrama como o da Figura 3 está muito mais próximo da realidade, ainda que esteja simplificado. Ao observar a Figura 3, você imediatamente tem mais dúvidas, como, por exemplo, "de que forma os usuários de VPN (rede virtual privada) trabalharão com o aplicativo" ou "qual é a diferença de autenticação entre usuários internos e públicos" etc.
Figura 3 A verdadeira rede que os desenvolvedores precisam compreender (clique na imagem para ampliá-la)
É óbvio que não basta simplesmente fornecer um diagrama de rede. Também é importante explicar a rede detalhadamente porque é impossível saber, apenas observando um diagrama, exatamente quais elementos terão impacto sobre o aplicativo. Você precisa abordar o processo de conexão real de usuários públicos, VPN e internos. E discutir as várias regras de firewall existentes, em especial em arquiteturas de rede ao estilo DMZ mais complexas, trará naturalmente problemas em potencial para o aplicativo.
Obviamente, seria vantajoso manter todas essas discussões antes da implantação do aplicativo, até mesmo antes do início do desenvolvimento – mas não importa, a discussão tem de acabar acontecendo, e contar com todos à mesa para compreender todo o diagrama de rede é a chave.
O sistema de rede também é a área de modelos de failover e redundância, mas sem um suporte a software ou pelo menos o reconhecimento do comportamento, esses modelos raramente funcionam como planejado. Deve acontecer uma discussão detalhada de como seriam os vários cenários de falha. Se houver clustering in-loco no banco de dados, isso afetará o código relacionado ao acesso ao banco de dados. Por exemplo, é possível tentar novamente as consultas após uma alternância de servidor? Se houver um local redundante disponível, como os dados serão replicados até ele? Como ocorre uma alternância de um local para outro?
Mais uma vez, manter uma conversa logo no início ajuda, mas antes tarde do que nunca – todo o pessoal envolvido com o aplicativo precisa compreender como funcionam essas coisas. Não há nada mais frustrante do que contar com uma solução em failover que não funciona de fato quando necessário.
Por fim, existe um outro recurso de rede essencial que precisa ser compartilhado: os logs de produção. Sempre recomendo que os logs de produção sejam disponibilizados à equipe de desenvolvimento. A reação habitual do pessoal de rede a essa solicitação é "me peça que eu envio para você". Não acho isso adequado – é muito mais eficiente dar aos desenvolvedores a possibilidade de recuperar os logs por conta própria, normalmente em um site de backup.
Os logs de produção são essenciais durante uma crise. Eles costumam ser a melhor (e a única) fonte de dados reais, empíricos, sobre o que realmente aconteceu. Mas eles são igualmente importantes em circunstâncias mais comuns. Quando têm acesso habitual a logs de produção, os desenvolvedores podem verificá-los para saber de que forma um novo recurso está se comportando. E essa é uma ótima forma de descobrir que o recurso não está fazendo o que você esperava e corrigir o problema antes que haja uma crise. Quando todos têm acesso a logs, é possível reagir e corrigir os problemas mais rapidamente.

Voltando ao dimensionamento
A reunião entre a rede e o desenvolvimento se resume à compreensão de todo o escopo dos problemas que cercam o dimensionamento de um aplicativo ASP.NET. O ambiente real em que o aplicativo opera afeta diretamente como o código executado por ele funcionará. Todas as estratégias relacionadas ao dimensionamento terão impacto sobre o comportamento no ambiente. A aplicação de uma estratégia de especialização como, por exemplo, separar as partes relacionadas a SSL do aplicativo pode exigir alterações no ambiente do sistema de rede e talvez mudanças nos próprios servidores.
Mesmo uma alteração aparentemente centralizada no código usando o cache pode ter impacto no ambiente. Isso porque, ao adicionar o cache de dados ao aplicativo ASP.NET, você está diminuindo o número de chamadas do banco de dados em troca de um aumento no uso da memória. O resultado é que você pode aumentar o número de servidores ASP.NET necessários ou o número de reciclagens do thread de trabalho nos servidores, o que dispararia eventos no lado do monitoramento de rede.
O dimensionamento do aplicativo ASP.NET não tem impacto sobre o pessoal de desenvolvimento e de rede – assim, vale muito a pena envolver ambos os grupos no processo de decisão. É comum a colaboração produzir soluções originais que as equipes, trabalhando de maneira independente, não descobririam. Por exemplo, o pessoal de rede pode reconhecer soluções de hardware existentes na empresa capazes de ajudar os desenvolvedores a atender aos requisitos de desempenho e de dimensionamento. A conversa sobre os detalhes do aplicativo e do ambiente revelará essas oportunidades.

O combate conjunto a incêndios
Recursos para o dimensionamento de aplicativos ASP.NET

  • Desenvolvendo aplicativos ASP.NET de alto desempenho
  • Como dimensionar aplicativos ASP.NET
  • Como ajustar e dimensionar o desempenho de aplicativos criados no .NET Framework
  • Implementando uma arquitetura escalonável
  • Maximizando o desempenho do IIS
  • Dimensionando estratégias para aplicativos ASP.NET
Uma crise no dimensionamento não é necessariamente algo ruim – na verdade, isso costuma ser bom porque vem à tona com muitos usuários que desejam executar o aplicativo, o que comprova o seu valor! Agora, porém, você precisa fazê-lo funcionar.
Às vezes, as crises no dimensionamento acontecem por conta de outro evento – às vezes, a empresa está fazendo uma promoção, você blogou a respeito ou um site de relacionamentos direcionou um grande número de pessoas para o site ao mesmo tempo. De uma hora para outra, você está em meio a uma batalha para manter o aplicativo em funcionamento. Como você deve imaginar, é melhor considerar esse tipo de cenário antes que ele aconteça de fato. E uma demonstração de como a colaboração pode ajudar uma organização a superar esse tipo de crise é uma maneira excelente de encerrar a reunião de desenvolvedores e equipe de rede.
A primeira questão ao administrar a crise é "como detectamos que o site está sendo sobrecarregado?" A resposta costuma ser: "recebemos uma ligação do CTO". Se o primeiro sinal de que o site está com problemas for uma ligação de alguém de fora, você realmente tem um problema. Uma medição mínima deve informar os problemas antes que o telefone toque. O telefone não irá parar de tocar, de fato, mas pelo menos isso dará uma idéia de como atendê-lo. Dizer "ah, sério?" para o CTO não ajuda muito na carreira, não.
Próxima pergunta: para quem ligar primeiro? Quem responde ao evento? Em geral, o pessoal de rede recebe o primeiro aviso e, como esse pessoal pode ser relativamente inexperiente, deve haver um plano de escalonamento claro. Para quem ligar em seguida? O desafio é fazer um diagnóstico rápido, preventivo, para saber que tipo de problema você está enfrentando. Caso seja uma queda na rede, isso é uma coisa. Mas se o problema é de dimensionamento, isso é algo totalmente diferente. Em problemas de dimensionamento, é recomendável chamar logo alguém da equipe de desenvolvimento envolvido.
Como todos os envolvidos no combate ao incêndio precisam de boas informações, direitos de acesso efetivos são essenciais. O objetivo é disseminar o máximo de informações possível para que seja feito um diagnóstico efetivo, e isso deve acabar ditando o escopo da solução.
Normalmente, se a única resposta for escrever um código, o evento terá passado antes que ele escrito. É claro que o evento deve ser observado para poder ajudar a formar prioridades para o desenvolvimento no futuro, mas não é razoável (ou inteligente) tentar escrever muitos códigos e colocá-los em produção antes de um teste cuidadoso. A regra número 1 de qualquer combate a incêndio: jamais coloque mais lenha na fogueira.
Quando surgem os problemas de dimensionamento, às vezes, a solução é simplesmente aguardar. Porém, ainda assim, é preciso tomar uma decisão.
Ao mesmo tempo, o planejamento em relação a essas contingências significa que diferentes técnicas podem ser aplicadas rapidamente. Reunir recursos de rede e de desenvolvimento para resolver um problema de dimensionamento costuma resolvê-lo em um tempo consideravelmente bom, talvez antes mesmo do suficiente para fazer desse evento promocional mais do que um sucesso.
Concluindo, a lição aprendida no lado da rede é que um aplicativo ASP.NET com bom desempenho e dimensionamento representa uma colaboração bem-sucedida entre o pessoal que criou o aplicativo e aqueles que o implantam e o operam.
Como a colaboração é inevitável, é melhor começar logo com as reuniões entre as equipes para compartilhar as informações. O objetivo delas é criar uma compreensão e um consenso de todos os elementos do aplicativo, o que ele faz, como faz, do que depende, como se comporta sob carga e como lida com problemas que surgem com o decorrer do tempo.
Quando essa colaboração é, de fato, efetiva, o resultado é uma empresa mais ágil, capaz de responder rapidamente diante de problemas, além de poder comunicar objetivos claros quanto ao necessário para que o aplicativo tenha êxito no futuro.

Richard Campbell é diretor regional da Microsoft, MVP em ASP.NET e co-apresentador do .NET Rocks, o programa de entrevistas em áudio da Internet destinado a desenvolvedores .NET (visite dotnetrocks.com). Ele trabalhou para empresas durante anos como consultor de desempenho e dimensionamento do ASP.NET, além de ser um dos co-fundadores da Strangeloop Networks.


Do Editor Ao vivo da Tech•Ed
Joshua Hoffman

É sempre um pouco complicado quando paro para escrever a Nota do Editor a cada mês. Pensar em um assunto, em geral, não é difícil, pois há sempre muita coisa interessante sobre o que falar. Não, o problema é que a Nota do Editor precisa ser escrita aproximadamente seis semanas antes que alguém a leia (em parte, porque assim temos tempo de imprimir a revista, mas principalmente porque os copidesques ganham tempo para corrigir todos os meus erros). Ao contrário de um blog, que pode reagir totalmente ao momento, é difícil escrever sobre "novidades" nesse contexto porque, na hora em que a pessoa ler, já não será mais novidade.
No entanto, estou na Tech•Ed 2008, na "ensolarada" Orlando, que realmente é o evento mais importante em nosso setor no momento. Portanto, embora esta nota já possa estar um pouco desatualizada quando você a ler... bem... é uma pena.
A Tech•Ed é um evento empolgante para nós por vários motivos. Em primeiro lugar, é uma das poucas ocasiões no ano em que podemos encontrar muitos de nossos leitores (e até mesmo autores) em pessoa! Temos o prazer de falar com eles por email, mensagens instantâneas e telefone durante o ano inteiro, mas nada se compara à troca de idéias e às conversas interessantes que ocorrem na presença de tantas pessoas.
A Tech•Ed também é uma ótima oportunidade para se ter uma idéia do que acontecerá no ano seguinte. Os executivos comparecerão para falar sobre grandes estratégias, o que sem dúvida será muito informativo. Receberemos muitas orientações novas sobre virtualização, a próxima geração da Web, conceitos revolucionários em sistemas de gerenciamento, entre outras coisas.
Entretanto, estou aqui para tratar de questões mais práticas. Mark Russinovich, um colega da Microsoft na área técnica e editor colaborador, falará sobre a redefinição de limites de segurança. Steve Riley, outro editor colaborador, falará sobre o total desaparecimento dos limites de rede, um conceito especialmente interessante e inovador! E Mark Minasi, Romi Mahajan, Dharmesh Godha e eu participaremos de uma conferência sobre a personalização de TI.
Também falarei sobre a primeira coisa a ser feita se você quiser escrever para a TechNet Magazine, uma apresentação que tenho feito com muito prazer nos últimos anos e que inspirou vários autores iniciantes. Quando você ler esta nota, os slides da minha palestra estarão postados no nosso blog, em blogs.technet.com/tnmag, portanto, fique à vontade para visitá-lo. Quem sabe? Talvez você se apresente na Tech•Ed do ano que vem como um de nossos autores!
Ah, e não vamos nos esquecer das festas da Tech•Ed. Adoramos as festas também.
– Joshua Hoffman

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Sunil Agarwal, Eric Charran, Trina Gorman, Sanjeev Nair, Isaac Roybal, Jez Sadler, Roger Sprague, Stefan Stranger, Kevin Sullivan, Jim Truher, Alan von Weltin, Michael Walsh e Buck Woody.


Cartas Com a palavra, os leitores

Tipos de conteúdo do SharePoint
Estou procurando informações que me dêem uma visão detalhada de como usar tipos de conteúdo no Microsoft® SharePoint®. Onde posso encontrar essas informações?
– E.A.

Uma boa fonte dessas informações é o blog da equipe de produtos e tecnologias do Microsoft SharePoint (disponível em blogs.msdn.com/sharepoint), e Pav Cherny escreveu um artigo sobre a padronização do gerenciamento de dados com tipos de conteúdo personalizados que você pode encontrar em technet.microsoft.com/magazine/cc194408. Há um white paper sobre o gerenciamento de metadados corporativos que você talvez ache útil disponível em technet.microsoft.com/library/cc262729.
Outro recurso que você deve explorar é o blog de Andrew May em blogs.msdn.com/andrew_may. Andrew trabalha como programador e redator na Microsoft, sendo responsável por escrever a documentação destinada ao desenvolvedor sobre os recursos de gerenciamento de conteúdo corporativo do Windows® SharePoint Services 3.0 e do Microsoft Office SharePoint Server 2007. Ele bloga a respeito dos tipos de conteúdo e está apresentando cartazes com ilustrações técnicas que lidam com tipos de conteúdo e explicam os aspectos mais complicados do gerenciamento de conteúdo corporativo em um ambiente do SharePoint.

Levando a segurança ainda mais longe
Adorei o artigo "O grande debate: segurança pelo disfarce" (junho de 2008, technet.microsoft.com/magazine/cc510319). Entretanto, fiquei um pouco desapontado com o fato de tudo se concentrar exclusivamente na alteração do nome do Administrador. Praticamente fiquei do lado de Roger Grimes e Aaron Margosis em relação ao debate sobre o nome di Administrador porque concordo que ele é melhor do que nada, além de criar poucas dores de cabeça para o gerenciamento. Mas existem tantos desafios mais legais – os compartilhamentos administrativos foram mencionados, mas não totalmente dissecados pelo grupo, e isso sim causa grandes dores de cabeça ao gerenciamento quando bloqueado.
Também adoraria ver o grupo debater os prós e os contras das tentativas de "redução da superfície de ataque". Reduzir a superfície de ataque é uma pequena variante da segurança pelo disfarce porque grande parte das saídas que o pessoal da área usa é desligar tudo que divulgue o local ou a identidade. Por exemplo, tenho muitos clientes deixando o IPv6 de lado em nome da segurança pelo disfarce. A remoção do serviço costuma ser como aquilo que os médicos faziam na época medieval: feche os olhos, aproxime-se e torça para não matar o paciente.
– Shelly B.

Estamos totalmente de acordo com você quanto ao foco limitado à alteração do nome administrativo. Os primeiros rascunhos tinham vários outros exemplos, mas o artigo teria 20 páginas se não tivéssemos de cortá-lo! Escolhemos então um exemplo para nos concentrar, e o problema da conta administrativa parece ser o mais mencionado. Mas não se preocupe – já começamos a disparar aquele olhar na direção dos autores para que eles escrevam mais sobre o assunto em um futuro próximo.

Sem o disfarce suficiente
"O grande debate: segurança pelo disfarce" foi um ótimo artigo. Pensando nele, percebi duas coisas. Primeiro, acho que enquanto o ROI (retorno do investimento) do disfarce for grande o suficiente, o disfarce será algo positivo. Segundo, notei que grande parte da segurança de TI sempre tem um componente de disfarce.
Considere senhas, por exemplo. Nós as disfarçamos mais e mais com o passar do tempo. No começo de tudo, não era necessário ter uma senha na maioria dos PCs. Depois, à medida que os computadores se tornaram mais conectados, bastava ter uma única senha. Quando a conectividade começou a crescer, uma senha de pelo menos oito caracteres passou a ser importante. Quando a segurança já não era suficiente, tivemos de recorrer a caracteres combinados, depois a frases etc. Acho que descobriremos que as nossas proteções mais disfarçadas continuarão não tendo o disfarce suficiente.
– Tom B.

Tom, agradecemos os seus comentários muito pertinentes. Será fascinante ver como essa tendência continua, especialmente porque conceitos de segurança como a autenticação multifator (cartões inteligentes mais senhas, por exemplo) estão se tornando lugar-comum.

TechNet Magazine Cartazes
Gostaria de adquirir os cartazes da Microsoft presentes em algumas edições anteriores da TechNet Magazine destinadas aos desenvolvedores da minha empresa. Vocês podem me dizer como posso comprá-los?
– Helen G.

Os três cartazes disponíveis são: Arquitetura de componentes do Microsoft Exchange Server 2007, Componentes de recursos do Windows Server® 2008 Active Directory® e Componentes de recurso do Windows Server 2008. Você pode comprá-los ligando para 800-444-4881 nos EUA e no Canadá, e para 785-838-7500 em todos os demais países.


Toolbox Novos produtos para profissionais de TI
Greg Steen

Monitore seus servidores
PA Server Monitor Pro
poweradmin.com/servermonitor
Você precisa manter o controle de todas as partes da sua infra-estrutura. Saber que há algo de errado antes dos usuários finais é fundamental para o controle de danos e a comunicação (e, além do mais, não é nada agradável ter o chefe pegando no seu pé). O PA Server Monitor Professional Edition, da Power Admin LLC, é uma ferramenta capaz de ajudá-lo a manter o controle da sua infra-estrutura de servidores.
É relativamente simples colocar o PA Server Monitor em operação, especialmente com o Processo de Configuração Inteligente interno do aplicativo, capaz de descobrir os computadores da sua LAN e configurar automaticamente um conjunto de monitores para cada um deles. Caso não esteja interessado em passar pelo processo de descoberta, você poderá importar uma lista de computadores para os quais deseja configurar verificações com monitores. E, depois de configurar um computador, você poderá exportar essa configuração via GUI para reutilizá-la como modelo para outros computadores, ou então como backup, caso venha a ser necessária uma reinstalação.
O PA Server Monitor oferece 18 monitores diferentes, que você pode atribuir a cada um dos seus servidores. Esses monitores incluem verificações padrão, como o monitoramento de espaço em disco, erros no log de eventos, execução remota de scripts, alterações em arquivos e diretórios, utilização de CPU e memória, resposta do protocolo ICMP (ping) e status de serviço do Windows®.
Há vários outros monitores especialmente úteis, inclusive o monitoramento de portas TCP, capaz de verificar o status básico de portas e também de enviar um texto de comando e verificar a resposta em relação a um valor predeterminado. O monitoramento de arquivos de log é capaz de verificar em um arquivo de log a existência de uma ocorrência de texto, que você pode definir como uma expressão regular ou como texto simples. Um monitor de cotas de diretório pode ajudá-lo a garantir que os usuários finais não excedam seus limites. E, caso eles excedam suas cotas, serão notificados por email. Você pode monitorar a execução de scripts de qualquer tarefa personalizada que deseje executar. E, por fim, pode usar o monitoramento de idade dos arquivos para acompanhar sua fila de emails e assegurar a realização de backup.
Depois de definir um monitor para um servidor, você precisará especificar uma ação a ser realizada se o limite desse monitor for alcançado. O PA Server Monitor conta com 15 ações internas, incluindo email, log de eventos, caixas de mensagens, arquivos de log, reinicialização de serviços, protocolo SNPP e scripts personalizados para ações personalizadas. Ao definir as ações, você pode também estabelecer uma cadeia de escalonamento, que executará ações adicionais se o monitor permanecer em estado de erro por um período mais longo do que o especificado. É possível, por exemplo, configurar uma ação para, primeiro, reiniciar seu site automaticamente. Depois, se a verificação ainda falhar após mais cinco minutos, uma mensagem de email será enviada para o seu dispositivo de mão informando o status do site.
Depois de algum tempo, provavelmente você desejará ver as estatísticas dos monitores configurados. O PA Server Monitor conta com recursos internos de geração de relatórios para ajudá-lo a fazer com que as informações cheguem a quem precisa delas. Entre os relatórios internos, estão um resumo do servidor que mostra estatísticas e o estado de um servidor específico; um resumo geral com uma linha sobre cada um dos seus computadores monitorados; e um mapa de status gráfico mostrando indicadores de status de instalações geograficamente dispersas. Os relatórios são gerados em HTML, podendo ser acessados com um navegador da Web, o que acrescenta um toque especial ao seu centro de operações. Além disso, você pode gerar relatórios ad hoc com gráficos e tabelas simples, ou então fazer a exportação para um arquivo CSV para uso posterior. Também é possível programar relatórios. Isso permite que o aplicativo envie automaticamente para o seu email as estatísticas mais recentes dos seus servidores com regularidade.
O PA Server Monitor não tem agentes. Uma grande vantagem dessa abordagem é que você pode colocá-lo em operação rapidamente, desde que o contexto de serviço do aplicativo esteja em execução com autoridade suficiente para conectar-se a computadores na rede e ser executado via WMI (Instrumentação de Gerenciamento do Windows) e outros serviços administrativos remotos como a RPC (chamada de procedimento remoto). No entanto, uma das desvantagens é o nível elevado de conta necessário para conectar-se aos computadores remotos. Logicamente, há outros tipos de monitores de protocolo de servidor, inclusive HTTP e SMTP, que não exigem essas permissões elevadas.
Outra possível desvantagem é que conectar-se a computadores em uma infra-estrutura e em uma topologia de rede complexas e dispersas pode ser difícil, além de depender da confiabilidade do domínio e da rede. Então, no fim das contas, o funcionamento dessa abordagem sem agente no seu ambiente dependerá do layout da sua infra-estrutura e do que exatamente você planeja fazer com a sua solução de monitoramento de servidores.
Preço: US$ 99 (para venda direta) para um monitor ativo ou US$ 349 (para venda direta) para cinco monitores ativos.
Mantenha o controle dos seus servidores com o PA Server Monitor Professional Edition (clique na imagem para ampliá-la)

Apague arquivos duplicados
dupeGuru
hardcoded.net/dupeguru
Se você trabalha com usuários finais ou gerencia um espaço em disco compartilhado pelos usuários, certamente já percebeu que esse espaço fica muito desorganizado com o passar do tempo. Isso geralmente ocorre porque um único usuário salva o mesmo arquivo em vários locais, ou até mesmo porque vários usuários salvam o mesmo arquivo em vários locais. Para ajudá-lo a consolidar e limpar o espaço dos usuários, talvez seja indispensável um localizador de duplicatas. O dupeGuru, da Hardcoded Software, é uma ótima solução.
A ferramenta examina sua pasta ou unidade de destino em busca de duplicatas, analisando os nomes e o conteúdo dos arquivos. Mas o dupeGuru vai além da comparação básica de cadeias de caracteres. Ele utiliza um algoritmo de correspondência difusa para localizar duplicatas que, de outra forma, passariam despercebidas. Com as duplicatas marcadas, você pode optar por enviá-las para a lixeira, excluí-las definitivamente, movê-las para outra pasta ou abri-las com o aplicativo padrão para uma verificação final. Se quiser examinar os resultados mais tarde, você pode exportá-los para XHTML.
Nas preferências, é possível decidir com que nível de rigor o filtro de nomes e conteúdo deverá agir ao examinar os arquivos. Isso pode aumentar o número de duplicatas encontradas, mas pode também aumentar a probabilidade de um falso positivo. O dupeGuru tem ainda a capacidade de marcar todas as duplicatas contendo uma palavra específica no nome do arquivo. Isso é muito útil para localizar todos os arquivos "Cópia de" criados acidentalmente pelos usuários, e também as pastas vazias com o nome "Nova pasta" espalhadas pelos diretórios.
Há versões disponíveis para o Windows 2000 ou superior e para o Mac OS X. Se você deseja reduzir as duplicatas em suas músicas ou fotos, vale a pena experimentar as versões adaptadas, chamadas, respectivamente, dupeGuru ME e dupeGuru PE.
Preço: US$ 19,95 (para venda direta).
Apague arquivos duplicados com o dupeGuru (clique na imagem para ampliá-la)

Mantenha o controle do seu ambiente
pt360 Tool Suite PRO
packettrap.com
Pode ser muito vantajoso ter uma interface única que permita exibir e administrar uma grande variedade de ferramentas de monitoramento e gerenciamento de rede. Além de economizar bastante tempo (e recursos de desktop), um pacote integrado facilita o compartilhamento de dados entre diferentes ferramentas de monitoramento e, ao mesmo tempo, permite pesquisar vários monitores simultaneamente, proporcionando uma visão mais completa do estado da sua infra-estrutura.
Se isso parece interessante, experimente o pt360 Tool Suite PRO, da PacketTrap Networks. Esse aplicativo oferece uma interface do usuário integrada para as ferramentas da PacketTrap Networks, com recursos adicionais de centralização e geração de relatórios consolidados. Você pode criar e organizar sua exibição de ferramentas em um painel personalizado para ter acesso instantâneo às ferramentas mais utilizadas e a informações sobre o status da infra-estrutura. O painel do pt360 também pode ser configurado em modo de tela inteira. Isso será muito útil no seu centro de operações, pois permitirá que qualquer membro da equipe, olhando para uma única tela, veja rapidamente o status de diversos recursos de rede e de servidores. O aplicativo oferece suporte a vários painéis, permitindo criar diversas exibições no seu ambiente de acordo com suas necessidades.
Para configurar um painel, basta selecionar a quantidade de gadgets em uma lista suspensa e clicar em cada gadget para configurá-lo. Os gadgets são agrupados em cinco categorias — Aplicativo, Sistema de Rede, Dispositivos, Disponibilidade e Outro — e contam com o protocolo SNMP e a WMI para monitorar seus servidores, aplicativos e dispositivos de rede. Os gadgets de Aplicativo trazem informações sobre o Active Directory®, o Microsoft® Exchange Server e o SQL Server®, além de fornecerem uma ferramenta de navegação. Os gadgets de Sistema de Rede proporcionam uma visão geral das interfaces de dispositivos e fornecem as dez principais exibições de perda média de pacotes, latência mais alta e uso de interface por cliente. Os gadgets de Dispositivos trazem indicadores de uso de CPU e memória, espaço em disco disponível, listagens de volumes, utilização de interface de rede e muito mais. São ótimos para controlar o desempenho dos seus servidores em tempo real, por meio das consultas WMI configuráveis. Os monitores de Disponibilidade mostram o tempo de atividade dos seus computadores em formato de gráfico, medidor, texto ou lista. E, por fim, Outro conta com um grande relógio digital.
Além do painel, o pacote de ferramentas do pt360 inclui recursos para sistemas de rede. Você obtém, por exemplo, um Configurador Cisco. Isso permite arquivar, modificar, carregar, baixar e comparar arquivos de configuração do seu equipamento Cisco. Você obtém também três ferramentas de ping diferentes — uma que oferece uma exibição de tabela classificável, outra com uma exibição de gráfico e a terceira que permite verificar rapidamente o ping de um grupo de endereços IP. Entre as outras ferramentas de verificação à sua disposição, estão um verificador de endereço MAC, uma ferramenta de verificação de portas, um verificador de SNMP e uma ferramenta de verificação de WMI.
O pacote de ferramentas também pode atuar como um servidor syslog e enviar, receber, registrar e exibir mensagens syslog de e para qualquer dispositivo na rede com suporte para syslog. A exibição ainda oferece suporte à filtragem. Assim, você pode isolar rapidamente mensagens preocupantes, acelerando o processo de solução de problemas.
O pacote funciona como um servidor de protocolo TFTP, permitindo mover rapidamente arquivos de/para dispositivos em toda a rede. As outras ferramentas incluem recursos de roteamento, Whois e wake-on-LAN. É claro que, por tratar-se de uma solução de gerenciamento centralizado, com conexões com seus hosts via WMI e SNMP, a forma como o pacote armazena suas credenciais de conexão é fundamental. Felizmente, o pacote utiliza um armazenamento de credenciais com criptografia AES de 256 bits, no qual é possível adicionar, atualizar e excluir as informações necessárias para monitorar sua infra-estrutura.
Preço: US$ 999 (para venda direta) por licença de usuário.
Figura 36. Monitore seus sistemas com o pt360 Tool Suite PRO (Clique para ver a imagem ampliada)

Gerencie o uso do disco
TreeSize Professional
jam-software.com/treesize/index.shtml
A pergunta "O que estará ocupando todo o espaço em disco deste servidor?" soa familiar? Seu aplicativo de monitoramento acaba de lhe enviar um email notificando que um limite de pouco espaço em disco foi alcançado. Talvez você esteja se perguntando como fazer para limpar o computador. E como julgar rapidamente quais são os melhores candidatos ao "Shift-Delete" (o atalho para excluir definitivamente, ignorando a lixeira). Uma ferramenta capaz de ajudá-lo na busca pelo "sinal verde" no seu monitor de host é o TreeSize Professional, da JAM Software.
O aplicativo é executado no Windows 2000 ou posterior, nas versões de 32 e 64 bits do Windows, e proporciona uma visão detalhada dos arquivos que ocupam o espaço das suas unidades. Você precisa apenas selecionar a unidade a ser verificada, e o aplicativo examinará automaticamente a estrutura de pastas. Quando a ação for concluída, você terá acesso a sete exibições diferentes da unidade. A primeira é uma visualização de Gráfico, que inclui três gráficos distintos a serem analisados: um gráfico de pizza, um gráfico de barras e um gráfico de caixa de tamanho relativo. Cada um deles permite fazer uma busca detalhada nas diversas pastas, para que você possa identificar rapidamente os principais consumidores de espaço. Também é possível personalizar as cores e o estilo dos gráficos.
Em seguida, há uma exibição de Detalhes que apresenta os arquivos em uma tabela classificável. Dentro dessa exibição, você pode escolher as colunas mostradas entre diversas opções. As opções mais úteis para os usuários incluem o autor de arquivos do Microsoft Office, o tamanho médio dos arquivos em uma pasta, a porcentagem do diretório pai ocupada pelo arquivo ou pasta e os links físicos.
A exibição de Extensões indica os tipos de arquivos que ocupam mais espaço em cada diretório, conforme você faz uma pesquisa detalhada das pastas. A exibição de Usuários permite uma visualização composta do espaço ocupado pelos arquivos da conta de um usuário ou sistema, o que é fundamental para ajudá-lo a isolar os usuários problemáticos. A exibição de Idades de Arquivos apresenta graficamente as porcentagens de arquivos modificados, criados ou acessados no último dia, mês ou ano — o intervalo de tempo que você preferir — permitindo identificar arquivos antigos que possam ser arquivados ou excluídos com segurança. Há também uma exibição dos 100 mais, que identifica os 100 maiores arquivos na unidade. E, por fim, há a exibição de Histórico, que apresenta os padrões de uso da unidade ao longo do tempo.
Todas as sete exibições podem ser impressas, salvas e copiadas para a área de transferência para uso posterior. Além disso, o TreeSize agiliza as tarefas comuns de limpeza para manutenção via barra de tarefas, permitindo que você isole rapidamente os arquivos maiores, mais antigos, temporários, de cache de Internet e duplicados com o recurso de Pesquisa de Arquivos. O TreeSize Professional também é capaz de examinar a rede por meio de compartilhamentos UNC, mas isso gera uma perda de desempenho considerável, devido à sobrecarga de rede envolvida.
O aplicativo também oferece suporte a um modo de linha de comando. Isso é ótimo para agendamento e execuções noturnas. Você pode ainda criar uma verificação de Tarefa Agendada, configurando-a para examinar um caminho e fazendo com que produza um conjunto de relatórios em um cronograma padrão. Isso é útil para monitorar o espaço compartilhado pelos usuários todas as noites e manter um controle rigoroso sobre a utilização do espaço em disco.
Se você está se perguntando como é possível que todo o seu espaço para os usuários, na escala dos terabytes, já tenha sido consumido, talvez o TreeSize possa ajudá-lo a entender como o seu espaço em disco está sendo utilizado e a gerenciá-lo com mais eficiência.
Preço: US$ 49,95 (para venda direta) por licença de usuário.
Gerencie o uso do disco com o TreeSize Professional (clique na imagem para ampliá-la)

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


P+R SQL Particionamento, verificações de consistência e muito mais
Paul S. Randal

P Anexei acidentalmente um banco de dados de produção a um servidor do SQL Server® 2005 e agora estou tentando anexá-lo ao servidor correto, que está executando o SQL Server 2000. Tentei simplesmente desanexar o banco de dados e depois anexá-lo ao servidor do SQL Server 2000. Tentei também fazer o mesmo com um procedimento de backup e restauração, mas nenhuma das duas formas funcionou. Por que o banco de dados não funciona com meu servidor do SQL Server 2000? Essa é a única cópia que tenho do banco de dados.
R O primeiro ponto a ser observado é a importância de se manter backups. Os DBAs geralmente pensam na necessidade dos backups para recuperar-se de corrupção de dados ou de outro desastre causador de destruição. Mas você se deparou com um desastre menos óbvio: algo que deu errado durante uma atualização, embora, nesse caso, trate-se de uma atualização acidental. Seja como for, a questão é que você deve ter sempre um backup completo e recente do banco de dados, para o caso de que algo aconteça a ele.
Uma atualização, seja intencional ou acidental, é uma operação unidirecional, e é extremamente difícil reverter seus efeitos. Quando você faz uma atualização entre versões do SQL Server, uma série de etapas de atualização é realizada no banco de dados. Cada etapa geralmente envolve algumas alterações físicas no banco de dados e aumenta seu número de versão.
Por exemplo, uma das principais alterações realizadas ao atualizar um banco de dados do SQL Server 2000 para o SQL Server 2005 é a alteração da estrutura dos catálogos de sistema do banco de dados (geralmente chamados de tabelas do sistema ou metadados do banco de dados). Esses catálogos contêm diversos metadados sobre tabelas, índices, colunas, alocações e outros detalhes referentes à estrutura física e relacional do banco de dados.
À medida que cada uma dessas etapas de atualização é realizada, o número de verão do banco de dados é aumentado. Por exemplo, os bancos de dados do SQL Server 7.0 têm o número de versão 515, os do SQL Server 2000 têm o número de versão 539 e os do SQL Server 2005 têm o número de versão 611 (ou 612, se o recurso vardecimal estiver habilitado). Isso permite que o SQL Server saiba qual foi a última etapa de atualização realizada no banco de dados.
As versões do SQL Server não são capazes de ler bancos de dados atualizados para versões mais recentes (por exemplo, o SQL Server 2000 não pode ler um banco de dados atualizado para o SQL Server 2005). Isso ocorre porque versões mais antigas não contêm o código necessário para interpretar as estruturas e o layout atualizados do banco de dados. A isso se deve o problema com o seu banco de dados, que foi atualizado para o SQL Server 2005: ele não pode ser anexado de volta ao SQL Server 2000.
Na ausência de um backup completo, sua única opção é exportar todos os dados do banco de dados atualizado e transferi-los manualmente para um novo banco de dados do SQL Server 2000. Desde que você não tenha usado nenhum novo recurso do SQL Server 2005, poderá extrair o script da estrutura do banco de dados, criar o novo banco de dados no SQL Server 2000 e exportar/importar os dados.
Para extrair o script do banco de dados no SQL Server 2005, você pode usar o Object Explorer do SQL Server Management Studio. Clique com o botão direito do mouse no banco de dados, selecione Tasks (Tarefas) e depois a opção Generate Scripts (Gerar Scripts). O assistente é auto-explicativo e gera um script para criar todos os objetos, índices, restrições, gatilhos etc.
P Reprojetamos recentemente nosso esquema para usar o particionamento de tabelas na tabela principal. Soubemos que isso ajuda a melhorar o desempenho. O banco de dados está armazenado em uma só unidade de 120 GB e a tabela está contida em um único grupo de arquivos. Não está sendo criada nenhuma janela deslizante. Apenas novas partições são adicionadas semanalmente, e todos os dados precisam estar disponíveis online. A maioria das nossas consultas processa dados de uma única semana. Apenas algumas atuam no último ano. Parece ser mais fácil fazer isso em um único grupo de arquivos. Estou certo ou há mais detalhes que não conheço?
R Embora pareça mais fácil usar um único grupo de arquivos, é pouco provável que, dessa forma, você perceba os benefícios do particionamento. As principais utilizações do particionamento são para obter uma manutenção mais eficiente do banco de dados e para aumentar a disponibilidade de dados em caso de desastre; além disso, você pode criar um esquema que gere ganhos de desempenho.
O exemplo típico de particionamento é uma tabela de vendas com 12 partições, cada uma representando um mês dos dados de vendas do último ano. No final do mês, a partição mais antiga é retirada (e arquivada ou excluída), e uma nova partição é incluída. Esse é o cenário de janela deslizante que você mencionou. A partição do mês atual é configurada para leitura/gravação e os meses mais antigos são somente leitura. Cada partição é armazenada em um grupo de arquivos separado. Esse esquema proporciona todas as vantagens do particionamento, mas não é o ideal em todas as circunstâncias.
Minha esposa, Kimberly, criou uma variação do esquema descrito acima que permite uma indexação mais eficiente. Imagine dividir a tabela de vendas em duas tabelas — uma para manter a única partição de leitura/gravação e outra para manter as 11 partições somente leitura, com uma exibição particionada das duas tabelas.
Isso permite que a tabela de leitura/gravação tenha uma pequena quantidade de índices, e que a tabela somente leitura tenha mais índices para dar suporte às consultas para a geração de relatórios. Isso, por sua vez, torna as operações em DML (linguagem de manipulação de dados) nos dados de leitura/gravação consideravelmente mais eficientes, pois eles não precisam manter tantos índices não clusterizados.
Além disso, as consultas aos dados de leitura/gravação não precisam processar também os dados somente leitura. A eliminação de partições em planos de consulta não é perfeita no SQL Server 2005, especialmente em casos com predicados complexos, mas foi muito aperfeiçoada no SQL Server 2008. Para obter mais informações sobre isso, consulte a postagem no blog de Kimberly em sqlskills.com/blogs/kimberly/default,month,2007-10.aspx#a71c70243-3d57-4940-9af7-a802b73f2f93.
Para mostrar o que quero dizer, explicarei alguns recursos habilitados pelo particionamento em vários grupos de arquivos.
Disponibilidade parcial do banco de dados É a capacidade de um banco de dados de estar online e acessível durante uma situação de recuperação de desastre, desde que o grupo de arquivos principal esteja online. Se você tiver apenas um grupo de arquivos, todo o banco de dados ficará inativo durante a restauração. Com os dados distribuídos por vários grupos de arquivos, somente os grupos danificados ficarão offline durante a restauração, e talvez o seu aplicativo possa continuar em operação.
Restauração por etapas Esse esquema é semelhante à disponibilidade parcial do banco de dados. Com um único grupo de arquivos, a unidade de restauração é uma só página ou o banco de dados inteiro. Com vários grupos de arquivos, você pode restaurar apenas um deles, permitindo a disponibilidade parcial do banco de dados.
Manutenção do banco de dados particionado Com qualquer um dos esquemas de particionamento abordados anteriormente, você pode realizar a remoção da fragmentação por índice de partição, até mesmo quando todas as partições estiverem em um único grupo de arquivos. Mas, com um único grupo de arquivos, você perde a capacidade de realizar verificações de consistência por grupo de arquivos, o que pode reduzir drasticamente o volume de dados a serem processados pela DBCC (verificação de consistência de banco de dados) — e, conseqüentemente, o volume de recursos de CPU e E/S utilizados.
Simplesmente, embora você possa ter várias partições no mesmo grupo de arquivos, há diversas vantagens em ter um mapeamento 1-1 entre as partições e os grupos de arquivos.
P Há pouco tempo, levamos um susto com um de nossos servidores avançados de banco de dados: uma placa de memória defeituosa estava causando corrupções. Descobrimos isso quando dados aleatórios começaram a aparecer em nosso aplicativo. Executamos o DBCC CHECKDB e encontramos todos os tipos de corrupção. Infelizmente, os dados corrompidos também estavam presentes em nossos backups. Então, foi preciso removê-los manualmente.
Para encurtar a história, substituímos o hardware defeituoso e ativamos as somas de verificação de páginas. Gostaríamos de executar verificações de consistência regularmente, mas não temos uma janela de manutenção grande, e a verificação do nosso banco de dados de 2,4 TB é demorada. O que podemos fazer?
R A dúvida sobre como realizar verificações de consistência e outros tipos de manutenção em um VLDB (banco de dados muito grande) vem se tornando cada vez mais comum. Muitos DBAs desistem depois de descobrir que DBCC CHECKDB leva mais tempo para ser executado do que permite a janela de manutenção (em algumas situações, o banco de dados é usado 24 horas por dia, 7 dias por semana, e não há tempo hábil para abrir mão da sobrecarga de CPU e E/S exigida pelo DBCC CHECKDB por um período extenso).
Além de desistir e não executar nenhuma verificação de consistência (o que eu definitivamente não recomendo), há quatro métodos que você pode utilizar. Já ajudei clientes a utilizar todas as quatro abordagens.
Usar a opção WITH PHYSICAL_ONLY do DBCC CHECKDB Um DBCC CHECKDB normal executa uma grande quantidade de verificações de consistência lógica, consumindo muita capacidade da CPU (e sendo, basicamente, uma operação vinculada à CPU). O uso da opção WITH PHYSICAL_ONLY limita essa execução às verificações rápidas de consistência de bitmaps de alocação DBCC CHECKALLOC, e depois à leitura e auditoria de todas as páginas alocadas no banco de dados, obrigando todas as somas de verificação de páginas presentes nos documentos a serem testadas. Isso transforma o DBCC CHECKDB em uma operação vinculada à E/S, com um tempo de execução muito menor (na verdade, chega a ser dez vezes mais rápido do que um DBCC CHECKDB completo, o que representa uma economia de tempo significativa).
Dividir a carga de trabalho da verificação de consistência Isso envolve dividir as tabelas do banco de dados em grupos do mesmo tamanho (a abordagem mais simples é fazer isso por número de páginas) e depois usar os comandos de DBCC CHECKTABLE para verificar a consistência de todas as tabelas em um único grupo a cada noite. Então, por exemplo, com sete grupos sendo verificados, um por dia, com um DBCC CHECKALLOC e um DBCC CHECKCATALOG uma vez por semana, é possível realizar o equivalente a um DBCC CHECKDB, embora dividido ao longo da semana.
Usar o particionamento de tabelas com vários grupos de arquivos As maiores tabelas do VLDB podem ser divididas em vários grupos de arquivos. Um exemplo de esquema de verificação de consistência pode ser a execução diária de DBCC CHECKFILEGROUP no grupo de arquivos que contém a partição de leitura/gravação, e também execuções semanais de DBCC CHECKFILEGROUP nos grupos de arquivos contendo as partições somente leitura. A lógica disso é que os dados somente leitura contam com backups abrangentes e não são usados no processamento diário. Por isso, não precisam de verificações de consistência tão freqüentes, pois a corrupção não é tão crítica nesses dados.
Descarregar as verificações de consistência para outro servidor Essa opção envolve restaurar os backups completos regulares do banco de dados em outro servidor e executar o DBCC CHECKDB nesse servidor. É claro que isso descarrega completamente do servidor de produção a carga de trabalho da verificação de consistência. Contudo, a desvantagem é que, se uma corrupção for encontrada, será preciso executar uma verificação de consistência no servidor de produção — mas isso deve ocorrer com muito pouca freqüência.
Como você pode ver, há várias opções disponíveis para que os DBAs realizem verificações de consistência em um VLDB, reduzindo assim a carga extra de recursos necessária para executar um DBCC CHECKDB completo. Como já mencionei, ajudei clientes a utilizar todas as quatro abordagens. Acredito que essas opções funcionarão no seu caso.
Dica: usando gatilhos para implementar lógica no servidor
Em alguns cenários, é necessário implementar lógica no servidor com gatilhos. Mas você deve estar atento a certas armadilhas. Eis aqui alguns pontos importantes que é preciso ter em mente.
  • Os gatilhos são acionados por instruções, e não por linha. Assim, certifique-se de colocar lógica adicional na lógica do seu gatilho para lidar com o cenário em que várias ou nenhuma linha é afetada pela instrução (os gatilhos são acionados por instruções, mesmo que nenhuma linha seja afetada). Os dados afetados são mantidos em tabelas virtuais para as instruções DML (linguagem de manipulação de dados). Essas tabelas podem ser unidas, permitindo que você trabalhe com os dados.
  • Os gatilhos são executados na sua transação de forma síncrona. Lembre-se disso sempre que quiser chamar um aplicativo externo ou acessar um recurso externo e não tiver certeza se ele retornará com uma resposta ou em um tempo razoável. Por exemplo, se você acionar uma instrução Update em relação a uma tabela e um gatilho for acionado nessa ação, a transação (o aspecto implícito da instrução Update) não será encerrada até que toda a lógica do gatilho tenha sido concluída. Se o aplicativo ou o processo externo retornar um código de erro, o SQL Server poderá cancelar ou reverter a transação (dependendo do tratamento de erros implementado e do código de erro). Então, se você precisar realizar alguma operação externa com um gatilho que não seja essencial para a transação (ou que não precise ser executada no mesmo escopo), dimensione-a para outro processo, coletando dados de forma assíncrona. O SQL Server 2005 introduziu o SQL Server Service Broker, que pode realizar essas tarefas de forma assíncrona.
  • É extremamente difícil localizar um erro causado por uma instrução em um gatilho. Se houver várias tabelas envolvidas na transação, lembre-se de inspecionar os gatilhos em caso de erro e de implementar o tratamento de erros adequado. Se você alterar o esquema no seu banco de dados, certifique-se de também manter o controle da lógica dos gatilhos. Caso contrário, um pequeno gatilho poderá causar um grande impacto no desempenho e na estabilidade gerais. A maioria das implicações relativas a alterações de esquema pode ser verificada usando o Visual Studio® for Database Professionals, realizando verificações automáticas de esquema ao editar o projeto e executando a análise estática do código para verificar inconsistências de tipo de dados.
— Jens K. Suessmeyer, consultor em banco de dados da Microsoft

Paul S. Randal é diretor administrativo da SQLskills.com e MVP do SQL Server. Ele trabalhou na equipe do mecanismo de armazenamento do SQL Server da Microsoft de 1999 a 2007. Paul escreveu o DBCC CHECKDB/repair para SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Especialista em recuperação de desastre, alta disponibilidade e manutenção de banco de dados, Paul é expositor em conferências regularmente. Ele mantém um blog em SQLskills.com/blogs/paul.

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


Utilitário em destaque Utilitário Limpeza do Windows Installer
Lance Whitney

Você tenta desinstalar ou atualizar um aplicativo em um dos PCs em seu ambiente, mas o comando não é executado. Em vez disso, é exibido um erro dizendo que o aplicativo não pôde ser desinstalado ou atualizado. Parece familiar? Nesse caso, certamente você já parou para se perguntar o que causou esse problema.
O software instalado que usa a tecnologia Microsoft® Windows® Installer (MSI) grava alguns arquivos e configurações do registro. Se alguns desses arquivos ou configurações estiverem ausentes ou corrompidos, talvez não seja possível remover, atualizar ou mesmo reinstalar um programa. A solução nesses casos é remover todas as informações do Windows Installer para que o programa possa ter uma instalação limpa. Para tanto, a Microsoft oferece o utilitário gratuito Limpeza do Windows Installer.
O utilitário Limpeza do Windows Installer exclui todos os arquivos e as configurações do registro associados à configuração do Windows Installer para um programa. É importante notar que a ferramenta não remove os arquivos ou as configurações do registro da instalação do programa. Ela também não substitui nem sobrescreve o comando Adicionar/Remover Programas.
Na verdade, você deve recorrer a esse utilitário se não conseguir instalar ou atualizar um aplicativo usando o método Adicionar/Remover Programas ou qualquer outro. Ao excluir as informações do Windows Installer, será possível reinstalar o aplicativo. Depois, você poderá deixar o programa instalado como está, atualizá-lo ou mesmo removê-lo.
O utilitário Limpeza do Windows Installer exibe uma lista de todos os aplicativos baseados no Windows Installer no PC (clique na imagem para ampliá-la)
Alguns leitores talvez conheçam o programa de linha de comando da Microsoft msizap, que remove os dados do Windows Installer de um programa. Bem, esse comando ainda é usado aqui: a Limpeza do Windows Installer é apenas um front-end amigável para o msizap, portanto, você não precisa mais sofrer com as complicadas opções de linha de comando.
Depois de instalar o utilitário, você encontrará um subdiretório chamado Limpeza do Windows Installer aninhado em Arquivos de Programas. Dentro dele há três arquivos: msicuu.exe, msizap.exe e readme.txt. O arquivo msicuu.exe exibe uma lista de todos os aplicativos baseados no Windows Installer no PC, permitindo que você marque, desmarque ou remova qualquer um deles. Esse programa passa as suas escolhas para o comando msizap.exe, que remove as informações do Windows Installer para os aplicativos selecionados.
Para executar a Limpeza do Windows Installer, vá para o menu Iniciar | Todos os Programas e localize a pasta; depois clique no atalho Limpeza do Windows Installer. Você verá uma lista de todos os aplicativos baseados no Windows Installer que estão no PC (como mostra a captura de tela). Selecione o aplicativo que está causando problema e clique no botão Remover. Esse aplicativo será excluído do banco de dados do Windows Installer, dando a oportunidade de fazer uma nova instalação limpa.
Você verá que, depois de executar a ferramenta Limpeza, o aplicativo não aparecerá mais em Adicionar/Remover Programas. Por isso, se eventualmente desejar removê-lo, primeiro terá de reinstalá-lo. A Limpeza do Windows Installer funciona apenas com software que usa a tecnologia do Windows Installer, que normalmente inclui instalações empacotadas como arquivos MSI.
Finalmente, observe que é necessário fazer logon como administrador para executar a Limpeza do Windows Installer. A ferramenta é compatível com todas as versões de 32 e 64 bits do Windows. Para obter mais informações sobre o utilitário e para baixar o software, visite support.microsoft.com/kb/290301.

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


Explorando o SharePoint Solução de problemas de integração do sistema de mensagens
Pav Cherny

Código disponível para download em: SharePoint2008_08.exe (416 KB)
Sumário
Abordagem geral da solução de problemas
Arquitetura do sistema de mensagens do SharePoint
Obtendo informações sobre diagnóstico
Transferência de mensagens de saída
Transferência de mensagens de entrada
Gerenciamento de diretórios
Conclusão
Em um ambiente bem projetado do SharePoint, os operadores de informações não precisam alterar seus hábitos de comunicação nem suas rotinas de trabalho para colaborar. Em vez de verificar manualmente os sites de colaboração de forma contínua, o SharePoint pode entregar documentos e outras informações, como alertas e lembretes, diretamente em suas caixas de correio.
Os usuários também podem participar em fluxos de trabalho respondendo a essas mensagens ou enviando novos itens como mensagens de email a bibliotecas de documentos e listas.
Entretanto, integrar o SharePoint® a um ambiente de sistema de mensagens seguro é um desafio, além de representar uma oportunidade para os componentes que não sejam do SharePoint influenciarem na colaboração baseada no SharePoint. O desafio é isolar e eliminar, com eficiência, as causas dos problemas do ambiente integrado sempre que eles ocorrerem.
Nesta coluna, falarei sobre a integração do sistema de mensagens do SharePoint baseada em uma comprovada estratégia de solução de problemas que fornece resultados rápidos. A idéia é localizar o ponto problemático de forma eficiente e abordá-lo com etapas de solução de problemas direcionadas e mais detalhadas.
Em uma organização de grande porte, essa investigação em fases pode significar a entrega do caso para outro especialista depois de uma análise inicial, especialmente se o problema estiver relacionado a componentes que não são do SharePoint. Em organizações de pequeno e médio portes, porém, não raro, um único administrador de TI deve ser capaz de solucionar os problemas de todos os sistemas envolvidos diretamente, o que reforça ainda mais a necessidade de usar abordagens estruturadas.
Para manter esta coluna orientada à prática, usei um ambiente de teste com o Active Directory®, Exchange Server 2007 e o WSS 3.0. As instruções passo a passo para criar esse ambiente de teste, bem como as ferramentas de solução de problemas discutidas nesta coluna, estão no material complementar, disponível na seção de downloads de código do site da TechNet Magazine.

Abordagem geral da solução de problemas
Talvez mais do que em qualquer outro cenário de interoperabilidade, a solução de problemas de integração do sistema de mensagens do SharePoint requeira uma abordagem extremamente estruturada. Há vários fatores que complicam essa tarefa.
Obviamente, é preciso lidar com tecnologias complexas e, ao se deparar com questões de transferência de mensagens, conversões de formatos de mensagem, aspectos de segurança e problemas de gerenciamento de diretórios, você verá que algumas mensagens de erro do SharePoint são bem confusas. Os grupos de notícias da Internet são repletos de linhas de discussão não resolvidas e sugestões que podem levá-lo a seguir o caminho errado — por exemplo, executar todos os aplicativos Web sob a identidade do pool de aplicativos para a Administração Central do SharePoint a fim de fazer com que a integração do sistema de mensagens funcione.
Mas há também aspectos positivos. O SharePoint é muito flexível. Na verdade, ele pode fornecer informações detalhadas sobre solução de problemas se você souber onde procurar. Com alguns scripts básicos, você pode melhorar muito sua eficiência na solução de problemas.
O primeiro objetivo da solução de problemas é entender o problema específico com o qual você está lidando. É necessário identificar onde o problema está localizado e quais componentes estão envolvidos. Você também pode tentar reproduzir o problema variando as configurações do sistema e estudando os logs de eventos e os arquivos de log baseados em texto do Windows®. Contudo, isso pode ser complicado, já que alguns problemas ocorrem apenas esporadicamente. Ainda assim, quanto melhor você conseguir reproduzir um problema, mais rápido poderá identificar e eliminar sua causa. Outro objetivo importante, muitas vezes negligenciado, é documentar todas as alterações e correções de configuração e verificar se elas foram aplicadas a todos os sistemas relevantes no ambiente, como todos os servidores front-end em uma Web farm.

Arquitetura do sistema de mensagens do SharePoint
Sempre que surgir um problema relacionado à integração do sistema de mensagens, uma sugestão é que você primeiro tome uma xícara de café ou de chá e, em seguida, analise a arquitetura de integração do sistema de mensagens antes de se envolver na solução do problema. Caso contrário, você poderá acabar corrigindo o problema ou componente errado. Por exemplo, um erro de Acesso Negado que o impede de criar um objeto de contato no Active Directory não significa necessariamente que você precisa corrigir as permissões de acesso do Active Directory, como veremos mais adiante.
Seja como for, é vital entender o papel de cada componente envolvido na integração do sistema de mensagens e como os componentes individuais interagem entre si. A Figura 1 mostra os componentes importantes em um cenário de conectividade do SharePoint, assunto que será abordado em detalhes nas seções a seguir.
Figura 1 Arquitetura de integração do sistema de mensagens do SharePoint (clique na imagem para ampliá-la)

Obtendo informações sobre diagnóstico
Uma das ferramentas mais importantes na solução de problemas são informações confiáveis de diagnóstico. O exemplo clássico é o log de eventos do Windows. Entre outras coisas, você pode controlar o nível de detalhes com que o SharePoint grava o log de eventos do Windows nos servidores Web usando a Administração Central do SharePoint (na página Operações, em Log e Relatório, clique em Log de Diagnóstico). Você pode especificar o evento menos crítico a ser relatado no log de eventos e no log de rastreamento. O log de rastreamento (localizado por padrão em %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs) será muito útil se você estiver pesquisando informações de baixo nível, mas pode acumular com muita rapidez, portanto, use esse recurso com parcimônia.
Outra maneira de obter informações sobre diagnóstico é habilitar a depuração para o aplicativo Web afetado, configurando o arquivo web.config correspondente, conforme descrito no Web Application Config.pdf do material complementar. O SharePoint exibe informações detalhadas sobre rastreamento diretamente na interface do usuário. Uma vantagem dessa abordagem é que você pode ver as informações de erro relevantes sem ter de analisar os megabytes dos dados de rastreamento. Uma desvantagem é que você deve alterar a configuração do sistema do seu aplicativo Web. Não se esqueça de fazer backup do arquivo web.config original e revertê-lo à configuração original depois de concluir a solução de problemas.
Também é possível configurar o serviço SMTP para gravar informações detalhadas no log do protocolo SMTP (no Gerenciador ISS, marque a caixa de seleção Habilitar o recurso de log na guia Geral). Instale o módulo Log de ODBC com o recurso Serviço SMTP conforme descrito no SharePoint Messaging Integration.pdf do material complementar, mesmo que não planeje usar o Log de ODBC. Caso contrário, o serviço SMTP não gravará o log de protocolo. Por padrão, o log do protocolo SMTP está localizado em %SystemRoot%\System32\LogFiles\SmtpSvc1. É um arquivo de texto que permite analisar a comunicação SMTP em detalhes e determinar se uma mensagem saiu do servidor SharePoint.
No servidor Transporte de Hub que se comunica com o serviço SMTP, também é possível habilitar o registro em log do protocolo na configuração Conector de Envio e Conector de Recebimento (consulte o SharePoint Messaging Integration.pdf). Você também pode usar muitas outras ferramentas para seguir o caminho que as mensagens tomam no ambiente do Exchange Server 2007 pelos servidores Transporte de Hub e Caixa de Correio, como o Controle de Mensagens, o Visualizador de Filas e o Pipeline Tracing (Rastreamento de Pipeline). Se desejar informações detalhadas sobre a solução de problemas de fluxo de emails do Exchange Server 2007, consulte o tópico "Problemas de transporte e fluxo de emails" em go.microsoft.com/fwlink/?LinkID=120145.
Nos controladores de domínio do Active Directory, é possível coletar informações detalhadas sobre a solução de problemas habilitando o registro em log de diagnóstico para o Acesso a Diretório e outras categorias por meio da definição das entradas do registro correspondentes em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Um valor de 0x0 para uma categoria significa que apenas os eventos críticos são registrados, enquanto que um valor de 0x5 significa que todos os eventos são registrados, incluindo as informações sobre depuração. O uso de um nível de registro em log maior do que 0x3 pode degradar o desempenho do servidor e rapidamente acumular o log de eventos do Windows. Durante operações normais, todos os valores devem ser definidos como 0x0.
A coleta de informações detalhadas de diagnóstico nos servidores SharePoint, Exchange e Active Directory em uma situação de solução de problemas pode ajudar a localizar um ponto problemático com rapidez e confiança. Outras ferramentas de solução de problemas, como TCP/IP (ping, tracert, telnet etc.) e o Monitor de Rede, também podem ser úteis, já que a maior parte da comunicação entre esses sistemas ocorre na rede do computador. O Microsoft® Network Monitor 3.1 está disponível em go.microsoft.com/fwlink/?LinkId=120143.

Transferência de mensagens de saída
Recursos
  • Site dos Produtos e Tecnologias do SharePoint
  • TechCenter do Windows SharePoint Services
  • Windows SharePoint Services Developer Center
  • Blog da equipe de Produtos e Tecnologias do Microsoft SharePoint
Equipado com os logs de eventos, de rastreamentos, de protocolos, de rastreamentos de mensagens e de rastreamentos de rede, estou pronto para solucionar problemas de integração do sistema de mensagens do SharePoint. Vamos começar pela parte fácil: a transferência de mensagens de saída. O SharePoint oferece suporte à transferência de mensagens de saída em diversas configurações e não requer um serviço SMTP local nos servidores Web. Entretanto, em um cenário de integração de mensagens completo, a configuração recomendada é usar o serviço SMTP local. A Figura 2 mostra os principais componentes no cenário.
Figura 2 Transferência de mensagens de saída (clique na imagem para ampliá-la)
Este cenário do sistema de mensagens inclui quatro estágios: o SharePoint deve transferir a mensagem para o serviço SMTP, o serviço SMTP deve processar a mensagem, o servidor Transporte de Hub deve receber a mensagem e o Exchange Server 2007 deve transferir a mensagem para o destino final.
Se o SharePoint não puder transferir a mensagem para o serviço SMTP, em condições normais, você receberá um erro na interface do usuário, como uma notificação de email que não pôde ser enviada. A causa pode ser que o serviço SMTP não está em execução. Ou talvez o log do protocolo SMTP diga que o serviço SMTP rejeitou a tentativa de envio com o código de erro 550 [Requested action not taken: mailbox unavailable (Não é possível executar a ação solicitada: caixa de correio não disponível)], uma indicação de que o problema está localizado no serviço SMTP.
Para verificar se não é um problema do SharePoint, você pode usar um script básico (consulte SMTP.vbs no material complementar) para enviar uma mensagem de teste pelo SMTP com as mesmas informações de remetente e destinatário. Se for um problema do serviço SMTP, o script não terá êxito. Na verdade, esse script pode lhe dar pistas importantes sobre a causa do problema, que o SharePoint infelizmente não revela mesmo com a depuração habilitada, conforme ilustrado na Figura 3.
Figura 3 Não é possível retransmitir mensagens (clique na imagem para ampliá-la)
Ao conceder as permissões de retransmissão do servidor Web na configuração do serviço SMTP e ao reiniciar esse serviço, o problema de envio de mensagens do SharePoint pode ser resolvido. Agora a mensagem chegará ao serviço SMTP, e o próximo passo importante é saber se o serviço consegue rotear a mensagem ao servidor Transporte de Hub.
Se a mensagem permanecer na pasta Queue (Fila), o serviço SMTP não conseguirá contatar o servidor Transporte de Hub. Se isso acontecer, é porque o serviço Transporte do Microsoft Exchange não está em execução ou há um problema de comunicação ou de configuração de rede. Usando o cliente Telnet, você pode verificar com rapidez e facilidade se é possível conectar à porta de destino de um Conector de Recebimento configurado para comunicação interna.
Não precisa ser necessariamente a porta 25 TCP. Na verdade, se o serviço SMTP usar essa porta, você poderá transferir as mensagens para o Conector de Recebimento padrão de servidores Transporte de Hub, que é configurado para bloquear envios de mensagens anônimas. Nesse caso, você verá um arquivo de mensagem na pasta Drop (Recebimento) (o serviço Temporizador do Windows SharePoint Services deve ser interrompido; caso contrário, a mensagem desaparecerá depois de alguns segundos). O arquivo de mensagem é uma notificação de status de entrega declarando que a mensagem foi rejeitada com "Diagnostic-code: smtp;530 5.7.1 Client was not authenticated" ("Código de diagnóstico: cliente smtp;530 5.7.1 não foi autenticado").
Para resolver esse problema, você deve criar um Conector de Recebimento para os servidores SharePoint. Como seus servidores SharePoint são sistemas internos, escolha a opção de autenticação Externally Secured (Protegido Externamente). Nesse caso, não é necessário conceder direitos estendidos à conta ANONYMOUS LOGON. Além disso, considere o uso de IPsec para proteger a comunicação entre os servidores SharePoint e o servidor Transporte de Hub.
Se as mensagens deixarem a pasta Queue do SMTP e os logs do protocolo SMTP nos servidores SharePoint e Transporte de Hub (verifique a pasta %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) indicarem uma transferência de mensagem bem-sucedida, considere o serviço concluído, pois o Exchange Server 2007 é capaz de rotear a mensagem até o destino. Como mencionado anteriormente, use as ferramentas de solução de problemas de fluxo de email incluídas no Exchange Server 2007 para investigar qualquer problema se as mensagens não chegarem aos destinatários do Exchange esperados. Observe que informações de destinatário incorretas, filtros de spam e restrições de tamanho de mensagem podem evitar uma entrega final nesse estágio.

Transferência de mensagens de entrada
Na direção oposta, a transferência de mensagens é um pouco mais complicada porque os possíveis problemas são mais sutis. Por exemplo, a documentação de produto do SharePoint recomenda configurar os registros MX no DNS para domínios de email do SharePoint, o que é uma boa maneira de desviar mensagens em uma organização do Exchange.
O Exchange Server 2007 usa Conectores de Envio com espaços de endereço associados para transferir mensagens. Ele pode rotear suas mensagens do SharePoint para servidores de Transporte de Borda ao transferir por meio da Internet mesmo que os servidores SharePoint sejam internos. Para transferência de mensagens internas, use Conectores de Envio com espaços de endereço detalhados e especifique seus servidores SharePoint executando o serviço SMTP como hosts inteligentes na configuração do conector (consulte o SharePoint Messaging Integration.pdf no download complementar). O estabelecimento de uma topologia de roteamento bem definida com servidores bridgehead dedicados ajuda a obter uma transferência de mensagens confiável do Exchange para o SharePoint.
Para verificar se as mensagens chegam aos servidores SharePoint, interrompa o serviço Temporizador do Windows SharePoint Services. As mensagens serão acumuladas na pasta Drop porque é o serviço Temporizador que processa as mensagens e coloca os anexos de arquivo nas bibliotecas de documentos associadas aos endereços de email de destinatário, conforme indicado na Figura 4. Se as mensagens não chegarem à pasta Drop, use o Visualizador de Filas no servidor Transporte de Hub para ver se o Exchange roteia as mensagens corretamente. Depois investigue os problemas de comunicação de rede que podem impedir que o Transporte de Hub se comunique com o serviço SMTP no servidor SharePoint.
Figura 4 Transferência de mensagens de entrada (clique na imagem para ampliá-la)
Ao reiniciar o serviço Temporizador, você verá os itens de mensagem desaparecerem da pasta Drop. Entretanto, se os anexos de mensagem não chegarem como documentos nas bibliotecas de destino mesmo que o SharePoint indique o processamento de mensagens bem-sucedido no log de eventos do Windows, isso significa que o Exchange enviou as mensagens no formato RTF do Exchange. Para investigar esse problema, encerre o serviço Temporizador novamente, envie outra mensagem com um anexo do seu cliente Outlook® e abra a mensagem no Bloco de Notas depois que ela chegar à pasta Drop. Agora pesquise a cadeia de caracteres "winmail.dat". Se você encontrá-la, o Exchange Server está enviando as mensagens no formato errado.
O SharePoint requer que os anexos de mensagem sejam codificados no formato MIME ou UUENCODE. Além disso, ele não mostra nenhum problema de processamento relacionado ao winmail.dat no log de eventos do Windows (consulte a Figura 5). Os anexos de arquivo simplesmente não aparecem na biblioteca de documentos. Use o Bloco de Notas como uma ferramenta de solução de problemas e elimine o problema de formatação, configurando uma definição Remote Domain (Domínio Remoto) no Console de Gerenciamento do Exchange para o domínio de email do SharePoint. Na guia Format of original message sent as attachment to journal report (Formato da mensagem original enviada como anexo para o relatório de diário), em Exchange rich-text format (Formato rich-text do Exchange), selecione Never use (Nunca usar).
Figura 5 Processamento de mensagens Winmail.dat (clique na imagem para ampliá-la)

Gerenciamento de diretório
Um dos eventos mais úteis do serviço Timer é o evento 6873, que declara que um erro ocorreu ao processar um arquivo de email de entrada por causa de um alias desconhecido. Isso acontece se um usuário do Exchange especificar um endereço de email incorreto do SharePoint ao enviar mensagens, como uma biblioteca de documentos inexistente.
Você pode minimizar esse problema configurando o Serviço de Gerenciamento de Diretório nas configurações de Email de Entrada da Administração Central do SharePoint a fim de criar objetos de destinatário para bibliotecas de documentos habilitadas para email no Active Directory. Os usuários do Exchange poderão, então, selecionar, conforme conveniente, esses objetos de destinatário com as informações de endereço corretas no catálogo de endereços.
No entanto, saiba que agora você estará entrando em um novo território de solução de problemas. O Serviço de Gerenciamento de Diretório falha em uma configuração de proteção do sistema baseada no princípio de privilégios mínimos porque esse recurso possui requisitos de permissão elevada no servidor Web. Além disso, a documentação do produto (como technet.microsoft.com/library/cc262947.aspx) exagera a situação quando sugere que você deve conceder à conta do pool de aplicativos Administração Central o direito "Criar, excluir e gerenciar contas de usuário" na UO especificada para os objetos de destinatário do SharePoint no Active Directory.
O Serviço de Gerenciamento de Diretório cria objetos de contato e de grupo e, por isso, a conta do pool de aplicativos Administração Central requer controle total sobre esses objetos na UO mas não requer permissões administrativas para as contas de usuário. Se você configurar o Serviço de Gerenciamento de Diretório em uma Web farm conforme descrito e tentar habilitar emails em uma biblioteca de documentos, é bastante provável que obtenha um erro de "Acesso negado".
As informações de erro indicam problemas de permissão do Active Directory, e os administradores do SharePoint não hesitam em atribuir controle total para Todos na UO do SharePoint. Entretanto, além de reduzir a segurança do Active Directory, essa medida não resolve o problema.
Uma solução de problemas estruturada requer que você localize o ponto problemático primeiro e depois aplique as alterações de configuração planejadas. Se seguir essa abordagem, verificar o log de eventos do Windows no controlador de domínio e rastrear a comunicação de rede usando o Monitor de Rede, talvez descubra que o SharePoint não acessa o Active Directory quando o problema ocorre. Portanto, é improvável que as alterações na configuração do Active Directory corrijam o problema. Ele está ocorrendo no servidor SharePoint.
Infelizmente, é extremamente difícil obter mais informações úteis sobre o problema da permissão. O SharePoint não registra nenhuma informação adicional no log de eventos do Windows. Contudo, se habilitar a depuração do SharePoint, você verá a pilha de chamadas (como mostra a Figura 6), que sugere que o Serviço de Gerenciamento de Diretório usa o método CreateContact de um serviço Web do SharePoint. O SDK do SharePoint dirá que esse é o Email Integration Web Service (Serviço Web de Integração de Email) (<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx).
Figura 6 Saída de depuração
Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters)
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags)
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias)
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration)
   at Microsoft.SharePoint.SPList.Update()
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args)
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)
Vejamos o SharepointEmailWS.asmx em um navegador da Web para obter a lista de operações com suporte. É possível ver o método CreateContact, e um clique no link CreateContact revela as mensagens SOAP que você deve enviar a esse serviço Web se quiser criar um contato no Active Directory. Isso é ótimo porque agora você pode criar uma ferramenta de solução de problemas baseada em script (consulte SharepointEmailWS.vbs no material complementar) para trabalhar fora da interface do usuário do SharePoint, o que torna mais fácil especificar contas de usuário diferentes durante as execuções de teste. A Figura 7 mostra as informações retornadas se você executar esse script na conta do pool de aplicativos Administração Central (à esquerda) e na conta Administrador do SharePoint (à direita).
Figura 7 Dois erros diferentes de "Acesso negado" (clique na imagem para ampliá-la)
As mensagens de erro são diferentes! As duas mensagens declaram que o acesso é negado, mas o erro à esquerda indica um problema de processamento e o erro à direita não indica. Então, qual é a diferença entre as contas do pool de aplicativos e a conta Administrador do SharePoint?
A conta Administrador do SharePoint é um Administrador local no servidor SharePoint, enquanto que as contas do pool de aplicativos não são. O problema pode ser resolvido adicionando as contas do pool de aplicativos do seu aplicativo Web ao grupo Administradores locais e reiniciando o servidor Web, mas isso não é novidade. Considero inaceitável a ação de executar as contas do pool de aplicativos com privilégios administrativos em servidores Web de produção.
Por que uma conta do pool de aplicativos requer essas permissões elevadas? Novamente, o script pode revelar a resposta. Se conceder a todos os usuários permissões de Administrador local no seu servidor Web para fins de teste, você descobrirá que as contas do pool de aplicativos podem usar o Email Integration Web Service enquanto o acesso permanece negado para todas as outras contas, inclusive administradores do SharePoint. Isso significa que o Email Integration Web Service usa a configuração de pool de aplicativos como base para decisões de controle de acesso.
A configuração do pool de aplicativos faz parte da metabase IIS (ou do arquivo applicationHost.config no IIS 7.0), e o acesso à metabase é restrito aos Administradores locais por padrão. Felizmente, é possível conceder acesso de contas que não seja de administrador à metabase usando o Metabase Explorer (Gerenciador de Metabase) incluído nas ferramentas do IIS 6.0 Resource Kit. No IIS 7.0, é ainda mais fácil conceder controle total ao arquivo applicationHost.config; basta executar os seguintes comandos:
CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config"
/G "<application pool account>" :F /E iisreset /noforce
Além disso, para criar objetos de contato no Active Directory, o pool de aplicativos Administração Central requer controle total sobre os objetos de contato e de grupo na UO de destino. E as contas do pool de aplicativos Web requerem acesso total à metabase nos servidores SharePoint da Web farm. Agora você está pronto para criar objetos de contato usando a interface do usuário do SharePoint.
Mas, espere; tem mais! Criar objetos de destinatário no Active Directory é apenas uma parte da história de integração de diretório. A outra parte é gerar atributos de destinatário relacionados ao Exchange e atualizar os catálogos de endereço baseados no servidor. Por exemplo, se atualizar a lista de endereços global no servidor Exchange usando o comando do Shell de Gerenciamento do Exchange Update-GlobalAddressList "Default Global Address List", você poderá encontrar os objetos de destinatário recentemente criados para as bibliotecas de documentos do SharePoint no catálogo de endereços do Outlook. Mas o ato de enviar mensagens para esses destinatários gera relatórios de falha de entrega por causa de informações de endereço incorretas, conforme ilustrado na Figura 8.
Figura 8 Mensagem que não pode ser entregue a uma biblioteca de documentos (clique na imagem para ampliá-la)
O acrônimo IMCEAEX significa Internet Mail Connector Encapsulated Address for Exchange (Endereço encapsulado do conector de email da Internet para o Exchange). Ele indica um endereço de destinatário que não é do Exchange encapsulado em um formato que o antigo Internet Mail Connector do Exchange é capaz de manipular. Mas, atualmente, estamos lidando com o Exchange Server 2007 e Conectores de Envio baseados em SMTP nativos.
A questão é que o Email Integration Web Service do SharePoint não grava os atributos de endereço que o Exchange Server 2007 requer para a transferência de mensagens. Ele apenas grava os atributos específicos de nome, sobrenome, nome de exibição e endereço de destino (e, opcionalmente, ms-ExchRequireAuthToSendTo). No entanto, ele não define o apelido de email, os endereços de proxy ou Exchange DN herdados, e não associa o objeto de destinatário a uma diretiva de destinatário do Exchange.
Para resolver o problema, use o cdmlet Get-Mailbox no Shell de Gerenciamento do Exchange a fim de obter todos os objetos de destinatário com um endereço de destino que aponte para o domínio de email do SharePoint. E faça um pipe da saída para o cdmlet Set-MailContact a fim de ativar as diretivas de destinatário do Exchange, conforme se segue:
Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True
Se preferir, use o Console de Gerenciamento do Exchange e marque a caixa de seleção "Atualizar automaticamente endereços de email com base em diretiva de endereço de email" nas propriedades do objeto de contato.

O WSS 3.0 e o MOSS 2007 já vêm com suporte à integração total do sistema de mensagens para habilitar alertas e notificações, fluxos de trabalho e envio de documentos baseados em email. Embora não seja uma tarefa fácil configurar os sistemas corretamente, a integração de mensagens pode aumentar a produtividade de trabalho. Especificamente, você deve verificar se a transferência de mensagens de entrada e de saída funcionam corretamente. Você também deve garantir que a integração de diretórios funcione.
As mensagens de erro do SharePoint nem sempre são intuitivas ou informativas. Entretanto, mostrei maneiras de chegar à origem dos problemas de integração, localizar as causas e eliminá-las de forma confiável, sem comprometer a segurança dos servidores SharePoint.

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

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


Windows PowerShell Uma espiada no gerenciamento remoto da versão 2.0
Don Jones

Esta coluna baseia-se em uma versão de pré-lançamento do Windows PowerShell. Todas as informações deste artigo estão sujeitas a alterações.

Sumário
Dois tipos de comunicação remota
Síncrona versus assíncrona
Espaços de execução reutilizáveis
Comunicação remota do tipo fan-in
O aplicativo arrasador na versão 2.0
Você teve a oportunidade de experimentar o mais recente CTP (Community Technology Preview) do Windows PowerShell 2.0? A versão mais recente, CTP2, possui um gerenciamento remoto aprimorado, e esta é uma ótima chance de começar a se familiarizar com os novos recursos que ela oferece. Antes de começar, pare um instante para
baixá-la em go.microsoft.com/fwlink/?LinkID=119707.
Primeiro, permita-me esclarecer alguns pontos importantes. Um CTP é um código pré-beta que a Microsoft fornece para permitir que usuários ansiosos como eu tenham uma idéia do que ela pretende fazer com a próxima versão de um aplicativo. Cada etapa ou compilação (como se costuma dizer neste setor) pode ser completamente diferente das compilações anteriores. Isso porque a equipe de desenvolvimento coleta comentários, revisa-os cuidadosamente e faz as alterações no aplicativo com base nesses comentários do usuário. Essa metodologia traz uma importante vantagem e uma importante advertência sobre seu uso do CTP.
Vídeo
Assista à demonstração de Don Jones sobre os novos recursos de gerenciamento remoto no CTP2 do Windows PowerShell 2.0.

A vantagem é que, ao usar o CTP, você pode fornecer comentários (por meio do site connect.microsoft.com) sobre o produto durante seu desenvolvimento, ocasião em que a equipe pode fazer alguma coisa a respeito! Se você esperar pela versão beta ou, pior, pela versão RC, dificilmente seus comentários serão incorporados. Durante o CTP, tudo pode acontecer e a equipe pode fazer alterações grandes e abrangentes, se necessário.
Isso nos leva à advertência. O CTP não está pronto para produção. Sim, o Windows PowerShell™ 2.0 CTP2 pode ser um dos produtos mais estáveis de pré-lançamento que você já viu, mas lembre-se de que a próxima compilação dele pode ser um aplicativo completamente diferente. Portanto, não comece a contar com o CTP2, porque a próxima versão poderá exigir que você comece do zero.
Observe que o CTP não pode ser instalado em paralelo com o Windows PowerShell 1.0. Para uma configuração ideal, o sistema também deve ter o Microsoft® .NET Framework 3.5 instalado para habilitar todos os recursos disponíveis. Caso contrário, alguns recursos serão limitados.
Além disso, como o CTP é um código muito recente, a Microsoft, até agora, deu mais ênfase ao funcionamento do aplicativo nos sistemas operacionais mais recentes, isto é, Windows Vista® e Windows Server® 2008. A compatibilidade do SO atual não corresponde à compatibilidade do SO que você pode esperar para o código final lançado. O transporte de pacotes entre versões recebe atenção em uma fase posterior no ciclo de desenvolvimento.

Dois tipos de comunicação remota
No mundo do gerenciamento remoto, normalmente encontramos dois tipos de comunicação remota: fan-in e fan-out. A comunicação remota do tipo fan-in engloba vários administradores que fazem conexões shell seguras com um único servidor. O Windows PowerShell foi projetado para permitir isso de maneira segura e particionada para que, por exemplo, uma empresa de hospedagem com o Exchange Server possa fornecer a seus clientes acesso administrativo às suas partes em um servidor. Com a comunicação remota do tipo fan-in, você obtém acesso seguro, remoto e interativo à cópia do Windows PowerShell (versão 2.0 apenas!) instalada em um servidor remoto.
A comunicação remota do tipo fan-out é quando você envia, de uma só vez, um conjunto de comandos a um grupo inteiro de servidores remotos. Os comandos realizam "fan-out" da sua estação de trabalho para o grupo de servidores em paralelo. Os comandos são executados em cada servidor, e os resultados, na forma de objetos do Windows PowerShell, são retornados à sua estação de trabalho para que você possa revisá-los e trabalhar com eles. O Windows PowerShell oferece suporte a duas importantes tecnologias de comunicação remota do tipo fan-out: o Windows® Management Instrumentation (WMI) e o Windows Remote Management (WinRM), que primeiro foi fornecido com o Windows Server 2008 e depois foi atualizado no Windows PowerShell 2.0 CTP.

Síncrona versus assíncrona
Na verdade, o Windows PowerShell 1.0 também tinha alguns recursos básicos do tipo fan-out vinculados ao WMI. Por exemplo, você podia criar facilmente uma matriz de nomes de computador e recuperar uma classe WMI de cada uma delas:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
    –computer $names
Executar métodos, como reiniciar um computador, exigia um pouco mais de trabalho já que a versão 1.0 não oferecia nenhuma maneira de executar métodos WMI em massa. Contudo, isso mudou na versão 2.0 CTP graças ao cmdlet Invoke-WmiMethod:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot
Essa técnica, porém, apresenta um problema. Ela é síncrona, o que significa que os computadores são contatados individualmente e você precisa esperar a conclusão de cada um para executar outros comandos. Mas o CTP apresenta um novo conceito (trabalhos em segundo plano) que permite que comandos como esse sejam executados em segundo plano. Em sua forma mais simples, você pode executar um comando WMI em segundo plano simplesmente adicionando o parâmetro –AsJob:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob
É possível revisar o status do trabalho resultante executando Get-PSJob e exibir os resultados finais do trabalho executando Receive-PSJob. (Falarei com mais detalhes sobre o gerenciamento de trabalhos em uma futura coluna.) Entretanto, o cmdlet Invoke-Command fornece um meio mais fácil de executar comandos em segundo plano, como este:
$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob
Isso realmente envia por push o comando Get-WmiObject para cada computador especificado e o executa localmente. Em geral, ele é executado muito mais rápido e sem precisar contar com as conexões RPC (chamada de procedimento remoto) do WMI. Em vez disso, Invoke-Command utiliza WinRM, que por padrão usa a porta 80 ou 443. Essas portas facilitam a navegação em firewalls e são totalmente configuráveis. Invoke-Command também oferece suporte a parâmetros adicionais para credenciais alternativas e limitação, permitindo trabalhar com centenas de computadores, mas deixar apenas alguns executando em paralelo. Assim, é possível evitar sobrecarga de excesso e congestionamento.

Espaços de execução reutilizáveis
Se você planeja gerenciar remotamente um determinado conjunto de computadores mais de uma vez, deve considerar o uso de espaços de execução em vez de simples listas de nomes de computador. No Windows PowerShell, um espaço de execução é apenas uma instância do mecanismo do shell, quer ele seja executado no seu computador como a janela de console do shell ou em segundo plano em um computador remoto. É fácil iniciar um espaço de trabalho remoto:
$names = @("server1","server2","server2")
New-RunSpace –computer $names
Como os espaços de trabalho usam WinRM, também usam a porta 80 (ou 443, se você especificar o parâmetro –UseSSL) por padrão. Eles também podem aceitar credenciais alternativas e assim por diante. Se você recuperar os objetos dos espaços de execução resultantes, poderá passá-los para Invoke-Command, e o Windows PowerShell enviará por push o comando para os computadores nos quais esses espaços de execução existem:
$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob
A vantagem disso é que os espaços de execução permanecem ativos enquanto o shell está aberto, por isso, você pode simplesmente reutilizá-los para comandos adicionais.

Comunicação remota do tipo fan-in
Os espaços de execução também são essenciais à comunicação remota do tipo fan-in. Por exemplo, a Figura 1 mostra que criei um espaço de execução em um computador remoto, recuperei uma referência para esse espaço de execução e usei o cmdlet Push-Runspace para ativá-lo. Nesse ponto, executo comandos no computador remoto, da mesma forma que seria possível com utilitários como o SSH ou outros de shell remoto. A execução de Pop-Runspace recupera o meu espaço de execução "local" original, e o prompt do shell me ajuda a manter o controle sobre onde estou no momento.
Figura 1 Usando o espaço de execução para executar comandos em um computador remoto (clique na imagem para ampliá-la)
A seqüência exata dos comandos que executei é a seguinte:
PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>
Esta técnica é chamada de fan-in porque vários administradores podem abrir espaços de execução interativos remotos no mesmo servidor e ao mesmo tempo (eles realizam "fan-in" de suas estações de trabalho individuais para o servidor). Um novo modelo de segurança no Windows PowerShell 2.0 permite criar shells e cmdlets restritos, portanto, cada administrador pode ser impedido de fazer modificações globais. Eles são limitados à sua própria área do shell. Essas novas técnicas de segurança exigem certo desenvolvimento de software personalizado em uma linguagem orientada ao .NET Framework. Isso está além do escopo da coluna sobre o Windows PowerShell, mas é bom saber que esses recursos existem.

O aplicativo arrasador na versão 2.0
O Windows PowerShell 2.0 CTP possui uma lista notável de novos recursos. Na minha opinião, a comunicação remota é um aplicativo arrasador. Todo administrador, em quase qualquer ambiente, pode se beneficiar com ele.
Você deve se familiarizar com esses recursos para poder oferecer suas sugestões à equipe de produtos. Deseja que as portas padrão WinRM sejam gerenciadas por meio da Diretiva de Grupo? Os cmdlets devem funcionar de maneira diferente? Existem problemas de desempenho? O WinRM é fácil de configurar? Você pode ajudar enviando sugestões para connect.microsoft.com ou pode compartilhar seus comentários com os ganhadores do Prêmio MVP, inclusive comigo (para me contatar, poste seus comentários nos fóruns em ScriptingAnswers.com). Portanto, participe e ajude a criar o aplicativo arrasador para a próxima geração do Windows PowerShell!
Cmdlet do mês: Select-Object
Experimente isto: Get-Service | ConvertTo-HTML | Out-File Services.htm. Agora, veja o arquivo HTML resultante no seu navegador da Web. Há muita informação, não é mesmo? Se ao menos houvesse um meio de reduzir um pouco essa quantidade selecionando as informações que o interessam. É exatamente isso o que Select-Object faz para você. Por exemplo, digamos que você deseja uma lista de nomes de serviço e seus status atuais. Você pode usar isto: Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm.
Não se esqueça, porém, de que Select-Object descarta o objeto original (neste caso, serviços) e produz um objeto personalizado (literalmente um tipo de objeto PSCustom) que contém apenas as propriedades que você especificou. Qualquer funcionalidade do objeto original deixa de ser acessível, portanto, provavelmente você desejará manter Select-Object próximo ao fim do pipeline, trabalhando com o objeto original por tanto tempo quanto possível.

Don Jones é co-autor de Windows PowerShell v2.0: TFM e o instrutor por trás do curso em sala de aula "Forças Especiais" do ScriptingAnswers.com (scriptinganswers.com/training.asp). Você pode contatá-lo pelo email jeepdon@mac.com.


Ei, Equipe de Scripts! Tomando a via expressa
A Equipe de Scripts da Microsoft

Nos últimos meses, um membro da Equipe de Scripts conheceu uma novidade na área de Seattle. É um programa que está sendo testado em várias cidades dos Estados Unidos, o chamado pedágio eletrônico. Entretanto, no estado de Washington, ele é conhecido como Good to Go!
O programa funciona da seguinte maneira: você paga para obter um dispositivo eletrônico que é fixado ao pára-brisa do seu carro. Você também abre uma conta na qual deposita uma pequena quantia em dinheiro. Sempre que passa por um dos dispositivos monitorados na via expressa, a cobrança é automaticamente debitada da sua conta. Basicamente, você está pagando para andar na via expressa (em grande parte por ser "expressa") sem ter de parar na cabine do pedágio.
Agora, em muitos lugares em que se cobra pedágio, os veículos de transporte de passageiros não precisam pagar. Contudo, o mais interessante sobre o Good to Go! é que ele funciona apenas na pista reservada a esses veículos. Você deve estar se perguntando: qual é a vantagem? Então, além de ter de usar um veículo de passageiros, você ainda tem de pagar? Não, nada disso. Esse sistema efetua a cobrança apenas das pessoas que desejam usar a pista expressa, mas dirigindo seus próprios carros. O motivo óbvio para isso é que há muito menos veículos nessa pista; às vezes, na verdade, ela é a única pista que anda.
Conforme mencionamos, esse sistema ainda é experimental, embora milhares de pessoas já tenham se inscrito. Há muita gente na área de Seattle disposta a pagar uma taxa para usar a via expressa e chegar ao seu destino.
Na coluna deste mês, a Equipe de Scripts decidiu fazer uma experiência. Queremos lhe mostrar uma via expressa conhecida como Microsoft® Visual Basic® Express Edition. Começaremos dizendo que uma das coisas mais interessantes sobre essa via é que ela é realmente expressa; não será cobrado nenhum pedágio, não importa onde essas informações serão usadas, o número de pessoas que irá usá-las nem a hora do dia em que isso acontecerá. Parece bom, não é? Claro que há um pequeno preço a pagar, que é ter de aprender alguns conceitos novos, mas você poderá julgar que as vantagens valem a pena.
Antes de prosseguir, gostaríamos de dizer que sabemos que estamos saindo um pouco da nossa esfera. Em geral, os produtos do Visual Studio®, como o Visual Basic e o Visual C#®, são matéria para a MSDN® Magazine, e não para a TechNet Magazine. Mas, como o MSDN e o TechNet parecem estar prestes a se tornar uma grande e louca família... ôpa, quer dizer, uma grande e feliz família, esperamos que você nos dê uma chance. Além disso, muito embora estejamos trabalhando com o que, tradicionalmente, é considerada uma ferramenta de desenvolvedor, continuamos a nos dirigir aos administradores do sistema Windows®. Fique conosco por mais alguns minutos e verá do que estou falando.
A primeira coisa que você precisa fazer para nos entender é instalar o Visual Basic. Não, espere. Não vá dizer: "Eu não tenho!" ou "Não posso comprar!". A Microsoft fornece uma cópia do Visual Basic Express Edition que pode ser baixada gratuitamente em microsoft.com/express/download.
Não pretendemos falar em detalhes sobre o funcionamento do Visual Basic Express. Há tutoriais na Ajuda, e a própria Ajuda é realmente muito boa. (Difícil de acreditar, não?) Na verdade, pretendemos mostrar como usar o Visual Basic Express para resolver um problema específico no Windows Vista® (embora esse exemplo também funcione em versões anteriores do Windows); depois disso, você poderá continuar a explorá-lo por conta própria. O problema que iremos solucionar é o seguinte: como abrir uma caixa de diálogo de abertura de arquivo no Windows Vista?
Há alguns anos, explicamos como abrir uma caixa de diálogo de abertura de arquivo com um script (consulte a coluna "Como posso mostrar aos usuários uma caixa de diálogo para selecionar arquivos?" em microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx). Esse artigo foi publicado em janeiro de 2005, muito antes da existência do Windows Vista. A solução usa o controle UserAccounts.CommonDialog do ActiveX® para abrir uma caixa de diálogo de abertura de arquivo, que permite procurar um arquivo para abri-lo. Infelizmente, esse controle foi removido do Windows a partir do Windows Vista, portanto, essa solução não funcionará nos sistemas mais recentes. (Não, ninguém nos perguntou se essa era uma boa idéia.) Enfim, isso significa que, pelo que sabemos, não há como abrir uma caixa de diálogo de abertura de arquivo usando VBScript. Então, em vez de escrever um script, usaremos o Visual Basic para escrever um aplicativo. Uma das funções desse aplicativo será abrir uma caixa de diálogo de abertura de arquivo.
Sim, é isso mesmo, o exemplo que iremos mostrar cria uma aplicativo completo no Visual Basic. À primeira vista, é um pouco assustador, mas você verá que, usando o Visual Basic Express, escrever um aplicativo completo pode ser tão fácil quanto escrever um script. Esse aplicativo consistirá em uma janela, ou formulário, que permite clicar em um botão para abrir uma caixa de diálogo de abertura de arquivo. Assim, você poderá selecionar os arquivos de texto dessa caixa de diálogo para que nosso aplicativo os leia e exiba um conjunto selecionado do conteúdo do formulário.
Muito bem, agora mãos à obra. Começamos abrindo o Visual Basic Express. A primeira coisa a fazer é criar um novo projeto, o que fazemos selecionando New Project (Novo Projeto) no menu File (Arquivo). A caixa de diálogo New Project é exibida. Observe que, se você estiver usando uma versão do Visual Basic Express anterior à 2008, encontrará pequenas diferenças daquela apresentada aqui. Criaremos um Aplicativo do Windows Forms, portanto, selecione o modelo Windows Forms Application e digite o nome que deseja dar ao seu projeto. Nomeamos o nosso como ReadFiles, que é mostrado na Figura 1.
Figura 1 Criando um novo projeto no Visual Basic (clique na imagem para ampliá-la)
Quando é criado, o projeto automaticamente fornece um novo formulário no qual trabalhar. O aplicativo que iremos criar apresentará um formulário ao usuário semelhante ao da Figura 2. Como mencionamos, o formulário inclui um botão que, quando clicado, exibe a caixa de diálogo de abertura de arquivo, aberta na pasta C:\Scripts. O usuário pode selecionar um ou mais arquivos de texto de qualquer lugar no sistema de arquivos. O aplicativo lê a primeira linha de cada arquivo de texto selecionado e exibe os resultados na caixa de listagem do formulário. Se isso lhe parece familiar, provavelmente você participou da Divisão de Iniciantes nos Jogos de Script de 2008: microsoft.com/technet/scriptcenter/funzone/games/games08/bevent3.mspx.).
Figura 2 O formulário ReadFiles que será apresentado aos usuários
Para criar nosso formulário, precisamos arrastar os controles da Caixa de Ferramentas para o formulário do projeto. Por padrão, a Caixa de Ferramentas é aberta no lado esquerdo da janela do Visual Basic. Se ela não abrir, clique no botão Toolbox (Caixa de Ferramentas) no lado esquerdo do espaço de trabalho do Visual Basic e expanda All Windows Forms (Todos os Windows Forms). Clique em Button (Botão) na Toobox e arraste o mouse sobre o formulário para criar o botão do tamanho desejado. Para adicionar um rótulo ao botão, clique no botão que você acabou de adicionar ao formulário e digite o nome desejado. Se preferir, edite a propriedade Text na caixa de diálogo Properties (Propriedades), por padrão no lado inferior direito do espaço de trabalho do Visual Basic. Rotulamos nosso botão como Browse for Files (Procurar Arquivos). Em seguida, clique em ListBox (Caixa de Listagem) e no formulário novamente, e arraste o mouse para criar a caixa de listagem. Usaremos a caixa de listagem para exibir as linhas que lemos nos arquivos de texto.
Isso é tudo o que precisamos fazer para criar o formulário. Agora vem a parte divertida: fazer algo acontecer quando clicamos no botão. Comece clicando duas vezes no controle Button (Botão) no formulário. Isso abrirá um editor de código com uma nova sub-rotina já criada para você, a sub-rotina Button1_Click:
Private Sub Button1_Click _
  (ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
  Handles Button1.Click
End Sub
Ela será executada sempre que o botão do formulário for clicado. Como você pode ver, a sub-rotina está vazia no momento; precisamos adicionar o código que dirá ao aplicativo o que fazer quando o botão for clicado. E o que exatamente queremos fazer? Bem, primeiro queremos fazer aquilo que prometemos lhe mostrar no início desta coluna: abrir uma caixa de diálogo de abertura de arquivo. Para tanto, e em quase tudo que fazemos no Visual Basic, usaremos o Microsoft .NET Framework.
Começaremos adicionando duas instruções Imports acima da sub-rotina:
Imports System
Imports System.IO
Essas instruções especificam namespaces do .NET Framework. Usaremos as classes que estão nesses namespaces e as importaremos aqui para podermos referenciá-las quando desejarmos. Observe que dissemos para inserir essas instruções acima da sub-rotina. As instruções Imports são globais, o que significa que não podem estar dentro de uma sub-rotina ou função; elas precisam ficar fora, sozinhas.
No VBScript, a menos que você adicione a instrução Option Explicit na parte superior do seu script, não é necessário declarar variáveis explicitamente. No Visual Basic, ela é adicionada automaticamente, por isso é necessário declarar todas as variáveis. Precisaremos de uma variável para manter uma referência ao objeto OpenFileDialog (que por acaso representa a caixa de diálogo de abertura de arquivo):
Dim dlg As Windows.Forms.OpenFileDialog
Agora que declaramos (com Dim) uma variável do tipo OpenFileDialog, podemos criar uma nova instância desse objeto, desta forma:
dlg = New OpenFileDialog()
Contudo, ainda não exibimos a caixa de diálogo. Primeiro, precisamos definir algumas propriedades:
dlg.Multiselect = True
dlg.InitialDirectory = "c:\scripts"
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
A propriedade Multiselect especifica se o usuário terá permissão para selecionar mais de um arquivo da caixa de diálogo de abertura de arquivo. Queremos que ele tenha essa permissão, por isso definimos essa propriedade como True. Definimos a propriedade InitialDirectory como C:\Scripts. Se você não defini-la, a caixa de diálogo abrirá o diretório principal do computador.
E, por último, mas não menos importante, definimos a propriedade Filter:
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
Aqui estamos filtrando quais arquivos a caixa de diálogo exibirá ao usuário. Iremos mostrar-lhes somente os arquivos .txt. A definição dessas propriedades fornecerá uma caixa de diálogo de abertura de arquivo semelhante à da Figura 3.
Figura 3 A caixa de diálogo Abrir mostrando somente arquivos de texto (clique na imagem para ampliá-la)
Agora, finalmente chegou a hora de exibir a caixa de diálogo. Fazemos isso com o método ShowDialog:
dlg.ShowDialog()
O método ShowDialog retorna um valor indicando se o usuário clicou em Abrir para abrir os arquivos selecionados ou clicou em Cancelar para fechar a caixa de diálogo. Se ele clicou em Cancelar, não fazemos nada. Portanto, antes de continuarmos, inserimos a chamada a ShowDialog em uma instrução If para garantir que eles clicaram em Abrir:
If dlg.ShowDialog() = _
  Windows.Forms.DialogResult.OK Then
Sim, sabemos que marcamos a propriedade OK em vez de Open. Nos bastidores, o botão Abrir é na verdade o mesmo que OK (a única diferença é que faz mais sentido exibir Abrir ao usuário).
Agora precisamos saber qual arquivo ou quais arquivos o usuário selecionou na caixa de diálogo. Os nomes de arquivo estão contidos na propriedade FileNames do objeto OpenFileDialog, por isso configuramos um loop For Each para lê-los:
For Each strName In dlg.FileNames
Opa! Esquecemos de declarar strName:
Dim strName As String
Agora precisamos abrir cada um desses arquivos para lê-los. No Visual Basic, fazemos isso com um bloco Using:
Using sr As StreamReader = File.OpenText(strName)
Os criadores de script do VBScript não estão acostumados ao bloco Using, já que ele não existe de fato no VBScript. O Visual Basic é um pouco melhor (está bem, em geral, é muito melhor) que o VBScript para gerenciar recursos do sistema. O propósito de uma instrução Using é fazer com que os recursos do sistema sejam liberados quando encerramos o bloco. Neste caso, estamos evitando usar o conteúdo do arquivo e grandes blocos de memória.
Sabemos que parece complicado. Mas tente olhar para isso como uma instrução Set. Estamos apenas criando uma instância de um novo objeto, neste caso, um objeto StreamReader, e atribuindo-lhe o fluxo de texto retornado do método File.OpenText. Observe que passamos a OpenText o nome do arquivo que desejamos abrir, o arquivo da nossa coleção FileNames na qual estamos fazendo o loop no momento.
Assim, a nossa variável StreamReader, sr, inclui o conteúdo do arquivo. Agora precisamos de outra variável:
Dim strLine As String
Usaremos essa variável para armazenar a primeira linha do arquivo de texto que acabamos de abrir:
strLine = sr.ReadLine()
Lemos a primeira linha do arquivo chamando o método ReadLine no objeto StreamReader. Lembre-se de que o objeto StreamReader inclui o conteúdo do arquivo. Armazenamos essa linha de texto na variável strLine.
Agora basta chamar o método Add no objeto ListBox para adicionar essa linha à nossa caixa de listagem:
ListBox1.Items.Add(strLine)
Para este exemplo, só queremos a primeira linha do arquivo para podermos fechar o StreamReader (não queremos mais usar o texto completo do arquivo de texto) e fechar o bloco Using:
sr.Close()
End Using
Depois disso, fazemos um loop para localizar o próximo arquivo selecionado na caixa de diálogo de abertura de arquivo até lermos todos os arquivos selecionados e adicionarmos todas as linhas à caixa de listagem. O código completo é semelhante ao da Figura 4.
Figura 4 Código ReadFiles completo
Imports System
Imports System.IO

Public Class Form1

  Private Sub Button1_Click _
   (ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
   Handles Button1.Click
    Dim dlg As Windows.Forms.OpenFileDialog
    Dim strName As String

    dlg = New OpenFileDialog()

    dlg.Multiselect = True
    dlg.InitialDirectory = "c:\scripts"
    dlg.Filter = "txt files (*.txt)|" & _
      "*.txt|All files (*.*)|*.*"

    If dlg.ShowDialog() = _
     Windows.Forms.DialogResult.OK Then
      For Each strName In dlg.FileNames
        Using sr As StreamReader = _
         File.OpenText(strName)
          Dim strLine As String
          strLine = sr.ReadLine()
          ListBox1.Items.Add(strLine)
          sr.Close()
        End Using
      Next
    End If
End Sub
End Class
Está vendo? Como dissemos, criar um aplicativo é quase como criar um script.
Você pode testar seu aplicativo pressionando F5 ou o botão Start Debugging (Iniciar Depuração) na barra de ferramentas Debugging (Depuração). Quando você clica no botão e seleciona um ou mais arquivos na caixa de diálogo de abertura de arquivo, os resultados são semelhantes ao da Figura 5.
Figura 5 As primeiras linhas dos arquivos selecionados exibidas na caixa de listagem
Quando o aplicativo for executado exatamente como você deseja, selecione Build ReadFiles (Compilar ReadFiles), ou outro nome que você tenha dado ao seu projeto, no menu Build (Compilar). Isso criará um arquivo .exe chamado ReadFiles.exe, que você poderá executar como faria com qualquer outro aplicativo e distribuir aos seus usuários.
Sabemos que essa via pode não parecer a via "expressa" para usar a caixa de diálogo de abertura de arquivo. Mas, considerando o fato de que é impossível fazer isso escrevendo um script no Windows Vista, escrever um simples aplicativo pode ser um pequeno preço a pagar. É como ter de pagar uma taxa para poder de fato chegar a algum lugar usando a via expressa: é um pouco difícil mas, no fim, você alcança o seu destino.
Outra vantagem de usar o Visual Basic nesses casos é que agora você começou a trabalhar com uma ferramenta mais poderosa do que o VBScript, que permite criar aplicativos com facilidade e uma bela interface do usuário; só isso já vale muito a pena. Os administradores de sistema encontrarão ainda muitas outras utilidades para o Visual Basic.
E lembre-se de que não é preciso reaprender a dirigir para usar a nova via do pedágio; basta se acostumar ao fato de que os carros à sua frente estão realmente em movimento. Da mesma forma, se você conhece VBScript não terá de aprender uma linguagem totalmente nova para usar o Visual Basic; basta se acostumar ao fato de que pode fazer muito mais.
O desafio de script do Dr. Scripto
O desafio mensal que testa não apenas sua habilidade de resolver quebra-cabeça, mas também de criar scripts.

Agosto de 2008: alfabeto de script
No desafio deste mês, você precisa inserir as letras de A a Z nos espaços em branco para revelar uma palavra que se relacione de alguma forma ao script. Cada letra (de A a Z) deve ser usada apenas uma vez, e as letras não aparecem na ordem alfabética. A letra inserida pode estar no início, no fim ou em algum ponto no meio da palavra. Por exemplo, na primeira linha, inserimos a letra C para completar a palavra SCRIPT:

RESPOSTA:
O desafio de script do Dr. Scripto
Resposta: alfabeto de script, agosto de 2008

A Equipe de Scripts trabalha na – quer dizer, é contratada pela – 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.


Os arquivos da área de trabalho Serviços de Implantação do Windows 101
Wes Miller

Sumário
WDS no Windows Server 2003
WDS no Windows Server 2008
Fazendo uma escolha
Considerações
Introdução ao WDS
Imagens de captura
Capturando 101
Migração da imagem
Instalação autônoma
A coluna do mês passado examinou o histórico das ferramentas de implantação baseadas no PXE (Pre-Boot eXecution Environment) da Microsoft. Neste mês, mergulharei no WDS (Serviços de Implantação do Windows), mais especificamente abordando as versões fornecidas com o Windows Server 2003 e a versão atualizada fornecida com o Windows Server
2008. Em seguida, colocarei o WDS em funcionamento para você.
Pensando bem, o WDS pode ser considerado a reformulação do RIS (Serviços de Instalação Remota). Muito embora ambos compartilhem alguns componentes essenciais e, de fato, a versão do WDS no Windows Server® 2003 conta com um modo herdado cuja funcionalidade é idêntica à do RIS, a infra-estrutura real do WDS em execução no modo nativo e nos 50 por cento do modo misto é totalmente nova.

WDS no Windows Server 2003
Quando o Windows Vista® foi lançado, o WDS foi oferecido ao mesmo tempo. Essa etapa foi necessária porque a instalação do Windows Vista foi totalmente reformulada usando a arquitetura WIM (Windows® Imaging Format), tornando o RIS incapaz de implantar o Windows Vista (e também o Windows Server 2008). Assim, o WDS foi disponibilizado como um download fora de banda para clientes com o Windows Server 2003 SP1 em execução. Com o SP2, o RIS foi totalmente suplantado pelo WDS.
Você deve se lembrar de que, como o WDS no Windows Server 2003 tem total compatibilidade com versões anteriores, você não precisa migrar para o modo nativo ao instalar o WDS no(s) sistema(s) Windows Server 2003 SP2. É possível continuar executando no modo herdado – execução funcional como um servidor RIS – ou no modo misto, o que possibilita a inicialização do WDS ou do RIS.
Além de poder implantar o Windows Vista e o Windows Server 2008, a execução do WDS no modo nativo ou na metade nativa do modo misto tem vários recursos adicionais. Em vez de usar o mecanismo de configuração em modo kernel do Windows e o núcleo de instalação tradicional que abordei no mês passado (technet.microsoft.com/magazine/cc645015), o WDS usa o Windows PE como ambiente de pré-instalação de inicialização e implanta imagens baseadas no WIM, e não usa as instalações baseadas em RISetup ou RIPrep. Isso torna a implantação mais rápida, simples e confiável.
Além disso, muitas das limitações que mencionei no mês passado como a necessidade do uso de caracteres ANSI (American National Standards Institute) desaparecem, porque o Windows PE é capaz de exibir os mesmos conjuntos de caracteres como uma instalação completa do Windows.
E o WDS ganhou algumas ferramentas que faziam muita falta no RIS – um snap-in do MMC (Console de Gerenciamento Microsoft®) para ajudar no gerenciamento e uma ferramenta de configuração de linha de comando muito abrangente que possibilitam recursos de configuração que vão muito além do RIS.
Como os modos herdado e misto permitem a implantação de imagens baseadas em RISetup e RIPrep do Windows, você talvez precise ter uma coisa em mente. Historicamente, o RIS usava um componente chamado SIS (Single Instance Storage) para otimizar o armazenamento da imagem em disco. O SIS, que mais tarde passou a ser fornecido como parte do Windows Storage Server 2003, usava um serviço chamado Groveler, executado em segundo plano nos servidores RIS (e WDS), procurando arquivos idênticos. Caso o tamanho e o hash de algum arquivo seja correspondente, o SIS salva uma cópia na pasta de armazenamento comum do SIS e cria um vínculo real com cada uma das versões originais encontradas.
O SIS foi projetado para causar um impacto mínimo sobre o uso do processador ao mesmo tempo em que possibilita uma economia de armazenamento significativa. Esse foi um conceito excelente usado pela primeira vez pelo RIS e, em seguida, amplamente na plataforma Windows Server. Mas o SIS deixou de ser usado para que o WDS pudesse seguir adiante.
Como o WDS no Windows Server 2003 em execução no modo nativo – e sempre no Windows Server 2008 – usa imagens do WIM na instalação, ele conta com uma compactação própria e – o mais importante – o modelo de armazenamento de instância única próprio, sem usar o SIS para nada. O armazenamento de imagens substitui o modelo de armazenamento usado pelo RIS por um novo design baseado no WIM destinado ao WDS. Há mais informações disponíveis sobre o SIS em go.microsoft.com/fwlink/?LinkId=120302.

WDS no Windows Server 2008
No Windows Server 2008, o WDS se tornou um superconjunto e um subconjunto da funcionalidade no Windows Server 2003. Agora ele pode implantar imagens via multicast no modo autônomo usando o servidor Transporte, um novo servidor TFTP (Trivial File Transfer Protocol) com melhor desempenho, suporte a sistemas x64 baseados em EFI (Extensible Firmware Interface) e relatórios de métricas de instalação aprimorados. Abordarei isso na coluna do mês que vem.
Você deve observar que existe um recurso do WDS no Windows Server 2003 que foi descontinuado no Windows Server 2008 – o suporte à instalação herdada. A possibilidade de implantar imagens RISetup/RIPrep ou de usar o OS Chooser do RIS herdado para iniciar a instalação não está mais disponível.

Fazendo uma escolha
Uma das perguntas que mais tenho recebido desde o lançamento do Windows Server 2008 é: "Qual versão do WDS devo usar?". A resposta depende da possibilidade de implantação de versões do Windows anteriores ao Windows Vista e, assim, da disponibilidade para que você faça a transição de imagens baseadas em RISetup e/ou RIPrep para um uso explícito usando uma instalação baseada no WIM.
O WDS, mesmo no Windows Server 2008, é capaz de implantar o Windows até o Windows 2000 caso esteja em uma imagem do WIM – e pode fazer isso usando multicast. Dessa forma, se estiver fazendo a transição do RIS para o WDS agora e pensando no Windows Server 2008 na infra-estrutura – além de estar disposto a migrar das imagens baseadas no RIS para as baseadas no WDS –, uma migração para o WDS no Windows Server 2008 poderá ter sentido para você.
Você também poderia migrar do RIS para o WDS no próprio sistema Windows Server 2003, o que acontece essencialmente quando você instala o SP2, e fazer a migração para as imagens baseadas no WDS. Assim, bastaria atualizar para o WDS do Windows Server 2008 e seguir em frente.
Porém, esse não é o modelo que eu recomendaria. Assim como acontece com muitas versões do Windows Server anteriores à 2008, a Microsoft recomenda a migração (em comparação com a atualização in loco) de uma versão do Windows Server para outra.
E, como já mencionei, levar em consideração as versões x64 do Windows Server 2008 deve fazer muito mais sentido na infra-estrutura do que as versões x64 do Windows Server 2003. Se você fizer essa transação, uma migração de servidor para servidor do WDS no Windows Server 2003 para o Windows Server 2008 será relativamente fácil e muito mais confiável em comparação com uma atualização in loco.

Considerações
Eis alguns pontos que você deve ter em mente ao trabalhar na implantação do WDS. Observe que eles não são, na realidade, novos requisitos do WDS – o RIS apresentava muitas dessas mesmas considerações –, mas você precisará levá-las em conta independentemente de estar criando um servidor WDS único ou uma infra-estrutura completa:
Privilégios Existem dois itens principais a serem lembrados quando você está gerenciando um servidor WDS. Você deve autorizar um servidor WDS no Active Directory® da mesma maneira usada com o RIS. Para isso, você deve ser um administrador de domínio no domínio raiz da floresta, um administrador de rede ou ter os privilégios apropriados delegados. Você também precisa ser um administrador de domínio para administrar o servidor WDS e, obviamente, também deve ser um administrador no próprio servidor WDS.
Virtualização Durante a execução em uma instância virtualizada do Windows Server 2003 ou do Windows Server 2008 no Microsoft Virtual PC ou no Virtual Server e a comunicação com um PC cliente na mesma instalação do Virtual PC ou do Virtual Server, pode ocorrer uma condição de corrida começando na inicialização PXE, levando a uma lentidão muito grande ou possível parada do cliente. É recomendável virtualizar clientes ou servidores, mas não ambos – especialmente no mesmo sistema de host. Particularmente, não recomendaria a virtualização de um servidor WDS para uso da produção – isso basicamente por conta do próximo aspecto.
Outros serviços O WDS, assim como o RIS, nem sempre se adapta aos demais serviços da produção. Pessoalmente, já vi problemas com o RIS/WDS em execução em um sistema de produção que também estava executando o Microsoft Exchange Server, o SMS (Systems Management Server) e o SCCM (System Center Configuration Manager).
Em geral, recomendo que o WDS seja a única função do servidor, caso você o esteja usando na produção destinada à maioria dos clientes. Essa não é uma exclusividade do WDS – você deve considerar se deve ou não misturar funções de produtos de servidor do Windows e testá-las antes da implantação.
Links de baixa ou alta latência Assim como acontece com o RIS, o WDS não foi criado para ser usado em uma conexão com pouca largura de banda ou de alta latência como um link via satélite; o handshake PXE pode ser problemático, e o download das imagens tende a ser difícil, caso funcione.

Introdução ao WDS
Mais sobre o WDS

  • Guia passo a passo sobre o WDS no Windows Server 2003
  • Guia passo a passo dos Serviços de Implantação do Windows (Windows Server 2008)
  • Implantando e gerenciando a atualização do WDS no Windows Server 2003
  • Documentação dos Serviços de Implantação do Windows no Windows Server 2008
  • Referência técnica: Serviços de Implantação do Windows (Windows Server 2008)
Para começar, você precisa decidir se usará o WDS no Windows Server 2003 ou no Windows Server 2008. Caso você esteja usando o Windows Server 2003, recomendo começar com o SP2, em que o WDS está incluído nativamente como um componente opcional (substituindo o RIS), em vez de usar o SP1 e o download opcional anteriormente disponível do WDS incluído no WAIK (Kit de Instalação Automatizada do Windows).
Independentemente da versão do Windows Server, você desejará criar o sistema de servidor. Você deve usar uma NIC (placa de interface de rede) de alta qualidade, capaz de suportar pelo menos 100 Mbps ou mais. Não use o agrupamento NIC (NIC teaming), pois a infra-estrutura PXE do WDS pode apresentar problemas com ele. Observe que, usando o Windows Server 2008, é possível instalar o WDS no Núcleo do Servidor ou na instalação completa do Windows Server 2008.
O WDS é instalado no Windows Server 2003 como um componente opcional (como era o RIS antes dele). É possível instalá-lo durante a configuração do sistema operacional ou depois, executando Adicionar/Remover Programas | Adicionar/Remover Componentes do Windows (ou sysocmgr.exe na linha de comando). O WDS é instalado no Windows Server 2008 como uma função, podendo ser instalado por meio do assistente de configuração inicial (clique em Adicionar funções | Avançar | e selecione Serviços de Implantação do Windows), pelo Server Manager (as mesmas etapas do assistente de configuração inicial) ou na linha de comando executando ServerManagerCmd –install WDS.
Depois de instalar o WDS, você precisa configurá-lo. No menu Iniciar do Windows, vá até Ferramentas Administrativas e selecione Serviços de Implantação do Windows. Quando o MMC for inicializado, clique com o botão direito do mouse no servidor e selecione "Configurar Servidor" no menu para iniciar o assistente de configuração.
Se estiver instalando o Windows Server 2003 e atualizando um servidor RIS existente, você desejará especificar o diretório RemoteInstall existente para que a instalação herdada possa ser atualizada para o modo misto. Nessa situação, você deve verificar se o diretório RemoteInstall não está localizado na partição Sistema, o que pode ter impacto no desempenho.
A Figura 1 mostra o console do WDS no Windows Server 2008 antes da conclusão do assistente de configuração. A Figura 2 mostra a Página de Boas-vindas do assistente de configuração do WDS no Windows Server 2008. A Figura 3 mostra a etapa de configuração do PXE do assistente de configuração do WDS. Nessa etapa, é possível especificar se o servidor deve responder a algum cliente (algo útil na compilação inicial), responder apenas a computadores cliente conhecidos (apenas os preparados antecipadamente no Active Directory) ou responder a todos os clientes (e se deve manter todos os clientes desconhecidos como opção para que um administrador possa escolher mais um curso de ação).
Figura 1 WDS instalado, mas ainda não configurado
Figura 2 O assistente de configuração do WDS
Figura 3 Escolhendo uma política de resposta para o servidor PXE
A Figura 4 mostra um servidor WDS totalmente configurado no Windows Server 2008 (ainda sem imagens instaladas) com a página Propriedades aberta. Caso você esteja usando um servidor que já seja DHCP (Dynamic Host Configuration Protocol), não se esqueça de definir a opção DHCP 60 como PXEClient e definir o WDS para Não escutar a porta 67. Isso permitirá que o servidor WDS ignore uma etapa durante o processo de descoberta PXE (como abordei na coluna do mês passado).
Figura 4 Um servidor WDS totalmente configurado no Windows Server 2008
Depois que o assistente for concluído, será possível adicionar novas imagens. Dois tipos de imagens podem ser adicionados a um servidor WDS em execução no modo misto ou nativo:
  • Imagens de inicialização: são imagens que contêm o Windows PE 2.x, geralmente copiadas do DVD de instalação do Windows Server 2008 ou do Windows Vista SP1. Observe que você desejará usar o arquivo \Sources\Boot.wim do Windows Server 2008 para as imagens de inicialização (mesmo que esteja implantando o Windows Vista ou um sistema operacional herdado) se estiver usando multicast. As imagens de inicialização normalmente consistem no Windows PE, no Windows Setup.exe e em outras dependências.
  • Imagens de instalação: consistem em imagens do sistema operacional Windows, normalmente o arquivo \Sources\Install.wim do Windows Vista ou do Windows Server 2008.
Para adicionar uma imagem de inicialização padrão ou de instalação padrão, as etapas são praticamente iguais. Você começa cada processo clicando com o botão direito do mouse no tipo da imagem e optando por adicionar uma imagem daquele tipo.
Para uma imagem de instalação, você precisa especificar um nome para o grupo de imagens (considerando que um WIM padrão no DVD do Windows contém mais de um tipo de sistema operacional). Em seguida, navegue até o boot.wim ou install.wim apropriado que deseja adicionar e clique em Abrir. Para imagens de instalação, é possível desmarcar qualquer imagem do volume (imagens do sistema operacional) que você não deseja adicionar ao servidor WDS. Por fim, é possível instalar com PXE clientes usando essas imagens padrão.

Imagens de captura
Para criar imagens personalizadas do sistema operacional, você precisa criar uma imagem de captura – uma imagem do Windows PE projetada que permite capturar um sistema Windows como uma imagem WIM. A forma mais fácil de fazer isso é usando uma imagem boot.wim instalada anteriormente.
Clique com o botão direito do mouse na imagem desejada e clique em Criar Imagem de Inicialização de Captura. Especifique o nome e a descrição a serem usados para a imagem, além do local para salvar uma cópia do arquivo .wim em caso de problemas na conectividade de rede ao implantar a imagem de captura. Depois, siga o assistente para terminar e clique em Concluir.
Em seguida, clique com o botão direito do mouse na pasta Imagem de Inicialização no MMC do WDS e clique em Adicionar Imagem de Inicialização. Assim como antes, siga as instruções do assistente. Quando concluir, você estará pronto para capturar uma imagem de instalação do Windows.

Capturando 101
Antes de capturar a imagem de um sistema operacional, você deve, é claro, instalar o Windows e verificar se ele inclui todos os aplicativos, personalizações e atualizações que deseja. O próximo passo é executar Sysprep no sistema; só é possível capturar imagens de instalação do Windows de sistemas preparados com Sysprep. Você deve especificar um local válido para salvar a nova imagem (para evitar possíveis danos) e uma extensão de arquivo *.wim.
Depois de configurar o sistema e copiar a versão correta de sysprep.exe para o sistema, você deve seguir estas etapas:
  1. No prompt de comando no computador de referência, altere o diretório em que sysprep.exe está localizado.
  2. Inicie Sysprep (também é possível iniciar clicando duas vezes em sysprep.exe e especificando manualmente as opções). Nos computadores com o Windows Vista ou o Windows Server 2008 em execução, execute o comando sysprep /oobe /generalize /reboot. Nos computadores com versões anteriores do Windows em execução, execute sysprep -mini –reseal –reboot.
  3. Quando o computador é reiniciado, o PXE o inicia (o processo pode variar de acordo com o sistema cliente).
  4. No menu de inicialização, selecione a imagem de captura do WDS e clique em Avançar.
  5. Escolha a unidade, o nome e a descrição da imagem.
  6. Como mencionado, apenas os sistemas com Sysprep permanecerão visíveis. Isso acontece por design, e não existe uma forma de ignorá-lo.
  7. Clique em Procurar e vá até a pasta local em que deseja armazenar a imagem de instalação capturada. O local escolhido pode ser uma unidade de rede mapeada.
  8. Selecione Carregar imagem para servidor WDS.
  9. Digite o nome do servidor WDS e clique em Conectar.
  1. Na lista Grupo de Imagens, selecione o grupo de imagens em que deseja armazenar a imagem e clique em Concluir.
Agora essa imagem está pronta para ser implantada com o servidor WDS. Há uma coisa que vocês, veteranos do RIS, talvez tenham observado: não capturei essa imagem do Windows online. O WDS exige que o sistema capturado esteja offline.
O RIPrep, no RIS, conseguia capturar (na verdade, exigia a captura de) um sistema online. Esse processo era frágil demais. Imagino que você achará o processo de captura do WDS relativamente fácil e certamente mais eficiente.

Migração da imagem
Caso já esteja usando o RIS há algum tempo, você deve ter algumas imagens por aí. Para as imagens baseadas em RISetup (uma instalação com script), esse é o fim da linha. No entanto, é possível migrar imagens RIPrep para imagens baseadas no WIM do WDS. Na verdade, o WDS permite até mesmo que você migre as imagens por meio de WDSUtil (explicarei isso mais detalhadamente no mês que vem).
Só costumo recomendar isso caso você tenha passado muito tempo em uma imagem que não deseja perder. O processo funciona muito bem, mas já ouvi falar de alguns erros ocorridos durante a conversão – o que geralmente quer dizer que você precisa recompilar a imagem do zero de qualquer forma.

Instalação autônoma
A criação de uma imagem como a que criei anteriormente proporciona uma imagem que pode ser instalada manualmente. Para obter uma instalação mais automatizada ou totalmente automatizada, você precisa usar dois arquivos de configuração autônomos. O próprio WDS exige um arquivo de resposta (unattend.xml, armazenado no diretório \RemoteInstall\WDSClientUnattend do servidor WDS) que automatize o processo de instalação do WDS. O segundo é um arquivo autônomo da imagem real. Para o Windows Vista ou posterior, esse é um arquivo unattend.xml. Para imagens do Windows mais antigas, ele é um arquivo sysprep.inf armazenado em uma estrutura de diretório $OEM$ ou em \Unattend no diretório de cada imagem. Esse arquivo é usado para automatizar a instalação real do Windows após a conclusão do WDS.
Para criar o arquivo autônomo do WDS, crie um arquivo unattend.xml para o WDS usando o WAIK. Copie esse arquivo para o diretório RemoteInstall ou um subdiretório. Clique com o botão direito do mouse na imagem de instalação para a qual deseja usar o arquivo autônomo e clique em Propriedades. Na guia Cliente, selecione Habilitar instalação autônoma e forneça o arquivo unattend.xml especificado anteriormente.
Para criar o arquivo autônomo de imagens anteriores ao Windows Vista, copie o arquivo sysprep.inf para o diretório $OEM$ da imagem – por exemplo, D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf. Para imagens do Windows Vista, especifique a imagem que deseja associar, clique em Propriedades e, na guia Geral, clique em Permitir que a imagem seja instalada no modo autônomo. Em seguida, especifique o arquivo unattend.xml a ser usado na instalação.
Isso já é meio caminho andado. Esta coluna deve colocar o WDS em funcionamento para você. No mês que vem, entrarei em mais detalhes sobre o WDSUtil, as especificações do armazenamento de imagens e o multicast. Depois, concluirei a série com uma análise detalhada de como e por que você deve avaliar a possibilidade de criar uma solução em implantação personalizada usando o WDS. Até lá, dê uma olhada na barra lateral "Mais sobre o WDS" que acompanha esta coluna.

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

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


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

Sumário
Processo do pseudologon multifator
O problema dos suplementos do navegador
O autenticador nunca deve mudar
Fazendo downgrade para senhas menos seguras
Ignorando o pseudologon multifator
Problemas com senhas comprometidas
Algumas vantagens
Enganando os usuários com colírio para os olhos
Abrir ou não abrir
Fornecendo comunicação segura
É sobre privacidade
Bem-vindo à segunda parte da série de três sobre como o setor de TI confunde os consumidores em vez de ajudá-los quando se trata de problemas de segurança. Na edição de julho de 2008 da TechNet Magazine, falei sobre o aviso de segurança inacionável e incorreto, e sobre fluxos de trabalho de logon confusos. (Se você ainda não leu a Parte 1, poderá encontrá-la
em technet.microsoft.com/magazine/cc626076.) Discuti como o aviso de segurança, que é extremamente comum e, no entanto, ineficiente, e os fluxos de trabalho de logon inválidos confundem os consumidores e acabam com seus esforços para proteger as informações pessoais.
Nesta edição, continuarei essa discussão com mais exemplos reais tirados do mundo da segurança do consumidor. A última parte desta série, que incluirá um "alerta" aos profissionais de segurança do mundo, aparecerá na próxima edição da TechNet Magazine.

Processo do pseudologon multifator
Em outubro de 2005, o FFIEC (Comitê de Investigação de Instituições Financeiras Federais) publicou as diretrizes para "Autenticação em um ambiente bancário na Internet" (consulte www.ffiec.gov/press/pr101205.htm). O cronograma de implementação era de apenas 14 meses e as instituições financeiras dos Estados Unidos começaram a ter dificuldade em encontrar um meio de cumprir essas novas diretrizes.
A maioria delas não conseguiu cumprir o cronograma. Muitas que finalmente conseguiram cumprir as diretrizes fizeram-no com medidas que não servem a nenhuma outra finalidade a não ser essa. Em outras palavras, as instituições tomaram medidas que não oferecem mais segurança aos clientes (são apenas práticas no "espetáculo da segurança"). Alguns dos exemplos mais interessantes de soluções inúteis são aqueles que tentam criar uma autenticação multifator que, na verdade, não é multifator.
Por exemplo, considere a tecnologia que mede a cadência da digitação quando um usuário digita uma palavra. Usada em um site, essa solução apresenta uma caixa de diálogo de logon com a aparência exata da antiga caixa de diálogo de logon. No entanto, essa nova caixa é um objeto Adobe Flash.
O objeto Flash registra a cadência da digitação do usuário, incluindo características como em quanto tempo as teclas são pressionadas e qual o tempo decorrido entre os pressionamentos de teclas. Esses dados são enviados ao site junto com a senha, onde são comparados com os valores armazenados. Contanto que os dados da cadência da digitação estejam de acordo com algumas variações dos dados armazenados e a senha seja igual, o logon é aceito. A idéia geral é que isso permite ao site usar um método de autenticação pseudobiométrico, sem ter de instalar hardware de terceiros no cliente.
Chamarei isso de pseudo-autenticação multifator. Não é uma verdadeira autenticação multifator, que mede dois ou mais dos seguintes fatores canônicos:
  • Algo que o usuário possui (como um cartão inteligente)
  • Algo que o usuário conhece (como uma senha)
  • Algo que faz parte do usuário (como uma impressão digital)
Em vez de realmente incluir vários fatores no processo de autenticação, a pseudo-autenticação multifator lê vários parâmetros a partir de um único fator: a senha. Então, ela usa esses parâmetros adicionais para fazer inferências sobre algo que faz parte do usuário.
A tecnologia usada na pseudo-autenticação multifator apresenta várias falhas. Juntas, elas podem fornecer uma tecnologia extremamente ineficiente para resolver os problemas de segurança que se propõe a resolver.

O problema dos suplementos do navegador
Os sistemas de pseudo-autenticação multifator contam com suplementos do navegador para fornecer o processamento sofisticado do lado do cliente de que precisam. Todo software, é claro, possui bugs, e alguns desses bugs causam vulnerabilidades. Essas vulnerabilidades se tornam um grande problema quando o software é difícil de atualizar e o usuário não tem certeza de que uma atualização foi instalada.
Os suplementos do navegador apresentam essas duas características: eles são difíceis de atualizar e não fornecem ao usuário informações amplas sobre se a versão instalada está atualizada. Conseqüentemente, o usuário deve expor uma parte do software à Internet que, de outra forma, não seria necessário.
Em alguns casos, manter o suplemento atual significa fazer visitas regulares ao site do suplemento para obter as atualizações. Não é preciso dizer que muitos usuários não farão isso. Qualquer sistema que exija que um usuário final exponha um software adicional, não relacionado, à Internet simplesmente para fornecer a funcionalidade de segurança deve ser seriamente reavaliado.

O autenticador nunca deve mudar
O fator "algo que faz parte de você" apresenta uma característica, ou talvez até uma falha, que não afeta os outros dois fatores. Embora você possa alterar as senhas (algo que você conhece) e criar novos tokens de segurança (algo que você possui), o número de autenticadores biométricos que você pode usar é extremamente limitado. Com as impressões digitais, por exemplo, normalmente você tem dez a vida inteira. E, se perder um dedo em um acidente, dificilmente poderá substituí-lo.
Agora considere a maneira como isso se aplica ao exemplo do pseudologon multifator. A métrica coletada como parte de outro fator não pode ser facilmente substituída ou modificada. Sem dúvida, quando a senha é alterada, a forma como o usuário a digita é alterada, mas não a maneira como ele em geral pressiona as teclas no teclado. Essa técnica conta exatamente com isso. Se essa métrica ficar comprometida, será possível sintetizá-la. No mínimo, um invasor conseguirá capturá-la e reproduzi-la.

Fazendo downgrade para senhas menos seguras
É uma boa idéia usar senhas longas e alterá-las com freqüência. E, conforme discuti na Parte 1 desta série, também é recomendável (ao contrário do que dizem) registrar suas senhas, de maneira segura, é claro. Entretanto, essas práticas não são condizentes com a digitação da senha à mão. Uma senha longa é mais difícil de digitar, e uma senha registrada é muito mais útil quando você pode copiá-la e colá-la. Uma das melhores maneiras de manter o controle de cem ou mais senhas é usar um utilitário de software como o Password Safe (em sourceforge.net/projects/passwordsafe). Com esse tipo de ferramenta, você pode gerar senhas totalmente aleatórias, armazená-las de forma criptografada e colá-las direto nas caixas de diálogo de logon. Na verdade, com esse tipo de ferramenta, você nem precisa saber qual é a sua senha.
Mas tem um problema: não é possível medir a cadência da digitação a menos que o usuário digite uma senha. E se você não tiver de digitar a senha em um objeto que mede a cadência da digitação, essa técnica de gerenciar senhas começará a falhar. Digitar uma senha de 15 caracteres totalmente aleatória de maneira correta não é uma tarefa simples. E por isso os usuários geralmente optam por simplificar as senhas diante desse tipo de sistema. No entanto, por si só, uma senha de 15 caracteres totalmente aleatória é muito mais segura do que uma senha mais curta com um sistema de pseudo-autenticação multifator.
Realmente, a pseudo-autenticação multifator, implementada exclusivamente, força os usuários a usar senhas menos seguras. Infelizmente, como você verá em breve, acomodar usuários que usam técnicas de gerenciamento de senhas apropriadas praticamente anula qualquer vantagem oferecida pelos sistemas de pseudo-autenticação multifator.

Ignorando o pseudologon multifator
Mesmo que um site implemente a pseudo-autenticação multifator, ele ainda deve oferecer suporte a uma forma de ignorar o pseudo-sistema multifator. Primeiro, alguns sites podem exigir que todos os usuários instalem uma tecnologia de uma "quarta parte" para poder acessar o site. Parte dos usuários (alguns autores da TechNet Magazine, por exemplo) sempre se recusará a usar esse tipo de software.
Em segundo lugar, a cadência da digitação pode ser alterada por vários motivos e, portanto, os sites devem se acomodar a isso. Por exemplo, digamos que um usuário torça o pulso e sua cadência de digitação seja temporariamente alterada. Como ele fará para acessar o site se este, ao analisar sua cadência, achar que uma pessoa diferente está tentando fazer logon com as credenciais desse usuário? Se a lesão for permanente, o usuário poderá redefinir o valor de cadência armazenado. Entretanto, no caso de uma lesão temporária, provavelmente ele não desejará redefinir esse valor, supondo que sua cadência de digitação logo voltará a ser como antes.
Finalmente, nem todos os usuários são capazes de usar sistemas de pseudo-autenticação multifator. Por exemplo, um usuário portador de deficiência física que interage com o computador por meio de uma interface de reconhecimento da fala talvez não consiga preencher a caixa de diálogo se ela impedir a entrada programática. Nesse caso, um sistema alternativo que acomode usuários portadores de deficiência provavelmente será exigido por lei.
A maneira mais simples e direta de acomodar todos esses cenários é também oferecer suporte à autenticação padrão baseada em senha.

Problemas com senhas comprometidas
Os sistemas de pseudo-autenticação multifator têm o propósito de resolver vários problemas associados à autenticação baseada em senha. Entretanto, eles não conseguem impedir completamente todas as maneiras significativas pelas quais as senhas podem ficar comprometidas. Os sistemas que dependem da autenticação baseada em senha podem ficar comprometidos de cinco maneiras básicas, sendo que "comprometido" significa sofrer um ataque de um invasor que obteve e usou a senha de outro usuário:
  • Adivinhação de senha
  • Agentes coletores de pressionamentos de teclas
  • Ataques de phishing
  • Pedir ao usuário
  • Invadir qualquer sistema que armazene a senha ou um pedaço dela
A adivinhação de senha não é mais um método de ataque muito comum dos criminosos e foi quase que totalmente suplantado por agentes coletores de pressionamentos de teclas e pelo phishing. A adivinhação de senha também é apenas parcialmente minimizada pela pseudo-autenticação multifator. Uma abordagem de adivinhação de senha convencional provavelmente não funcionará contra um sistema de pseudo-autenticação multifator já que o invasor deve adivinhar a senha, bem como a cadência da digitação. Embora, em teoria, seja possível sintetizar a métrica da digitação, raramente é necessário, porque os dados reais em geral podem ser capturados por um ataque de phishing ou um agente coletor de pressionamentos de teclas. Além disso, se o sistema também fornecer uma interface padrão de logon somente de senha, o invasor poderá simplesmente usar esse sistema para a adivinhação de senha.
Também, os ataques de adivinhação de senha são muito bem protegidos por senhas fortes. Se pudermos ensinar os usuários a usar senhas mais fortes, provavelmente com a ajuda de ferramentas, a pseudo-autenticação multifator não será necessária. Por outro lado, as senhas mais simples que em geral são usadas com os sistemas de pseudo-autenticação multifator, na verdade, tornam a adivinhação de senha uma abordagem viável. Assim, qualquer vantagem que seja oferecida aqui para minimizar a adivinhação de senha só será realmente válida se a implementação não oferecer suporte a logons somente de senha. E, como ressaltei, isso raramente é possível. Em outras palavras, se os usuários utilizarem senhas mais fracas na presença de sistemas de pseudo-autenticação multifator, a adivinhação de senha novamente se tornará um método de ataque viável; a pseudo-autenticação multifator reduz a segurança em vez de aumentá-la. Essa questão requer uma pesquisa mais profunda.
A pseudo-autenticação multifator também não consegue resolver o problema dos agentes coletores de pressionamentos de tecla. Embora não conheça nenhum agente coletor de pressionamentos de teclas de uso comum atualmente que capture a cadência da digitação, isso não significa que ele não venha a existir. Um agente coletor de pressionamentos de teclas é um hardware que fica entre o teclado e o computador ou um software que captura pressionamentos de teclas. Seja como for, agente coletor tem acesso total a todos os dados usados pela solução da pseudo-autenticação multifator.
Na verdade, ele pode acessar até mais dados já que uma solução de autenticação é executada no modo de usuário enquanto que o agente coletor de pressionamentos de teclas está muito além disso. Sem um caminho confiável entre o teclado e o objeto baseado na Web usado para capturar a senha, não é possível evitar esse tipo de comprometimento. Se as soluções de pseudo-autenticação multifator se tornarem bastante comuns, pode ter certeza de que alguém criará um agente coletor de pressionamentos de teclas desse tipo.
Da mesma forma, os ataques de phishing não são impedidos pela pseudo-autenticação multifator. Em vez de usar apenas uma tela de logon falsa, o invasor pode usar um objeto Flash para capturar a senha, bem como a cadência da digitação.
Sem dúvida, a pseudo-autenticação multifator pode ajudar em alguns cenários em que a técnica do invasor forneça apenas a senha do usuário. Por exemplo, a maneira mais fácil de obter uma senha de um usuário é pedir para ele. Por incrível que pareça, essa é comprovadamente uma técnica eficiente, seja pedindo pessoalmente, por telefone ou por mensagens de phishing.
É claro que pedir a um usuário para fornecer a sua cadência de digitação não será tão eficiente. Da mesma forma, se um banco de dados de senha corporativo for comprometido, o invasor provavelmente ganhará acesso apenas às senhas. Mas, novamente, esses ataques só serão minimizados se o sistema não fornecer nenhuma autenticação padrão somente de senha.
Também devo ressaltar que, se o banco de dados de senha em si ficar realmente comprometido, é bem provável que o invasor comprometa o sistema de uma forma muito mais profunda do que seria possível com uma única senha ou mesmo várias senhas de conta de usuário comuns. Portanto, não é muito válido tentar minimizar o que um invasor em posse de um banco de dados de senha é capaz de fazer.

Algumas vantagens
Certamente, há alguns problemas que a pseudo-autenticação multifator pode ajudar a resolver (supondo que o sistema não forneça nenhuma opção de logon padrão somente de senha). Por exemplo, ela pode ser usada para evitar o compartilhamento de senha. Contudo, isso pode ser uma desvantagem para sistemas em que seja legítimo a vários usuários compartilhar contas, como em contas de banco conjuntas.
Além disso, uma caixa de diálogo de logon interativa (e não um logon de site) construída de maneira adequada pode forçar um usuário a executar etapas de autenticação adicionais se a cadência da digitação não for a mesma. Essa pode ser uma medida de segurança adicional para uma conta comprometida em um ambiente altamente confidencial.

Enganando os usuários com colírio para os olhos
Uma das melhores maneiras de confundir os usuários é dar indicações de segurança imprecisas. A mais comum provavelmente é a imagem do cadeado exibida em uma página da Web, como mostra a Figura 1. Essa página ainda exibe a palavra "Seguro" pelo cadeado.
Figura 1 Um exemplo de uso indevido do ícone de cadeado, uma tendência preocupante (clique na imagem para ampliá-la)
Como você deve saber, simplesmente colocar uma imagem de cadeado e a palavra "Seguro" em uma página não a torna segura. No entanto, infelizmente essa prática é comum, mesmo entre os sites mais respeitáveis e visitados. O resultado é que muitos usuários são treinados para procurar essas pistas visuais de segurança no corpo da página em vez de olhar para onde realmente importa: na barra de endereços. (A W3C Web Security Context Wiki tem uma entrada sobre esse problema, disponível em w3.org/2006/WSC/wiki/PadlockIconMisuse.)
É uma pena que ainda haja tantos exemplos de uso indevido. Pesquisas mostram que os usuários são incapazes de identificar sites mal-intencionados mesmo quando os certificados são muito óbvios (consulte www.usablesecurity.org/papers/jackson.pdf). Trata-se da capacidade de distinguir facilmente o falso do verdadeiro, mesmo quando não se tem o verdadeiro para comparar. Isso requer habilidade; um colírio para os olhos de segurança enganador em páginas da Web compromete o desenvolvimento dessa habilidade já que os usuários são atraídos pelas informações erradas.
Uma variação especialmente perturbadora desse problema é mostrada na Figura 2. Nesse caso, a página que exibe as informações, na verdade, não é segura. Se você olhar para a barra de endereços, verá o "http" indicando o protocolo. Esse site usa uma técnica de otimização bastante comum: em vez de criptografar a página que contém o formulário de logon, somente o envio do formulário é criptografado. O logon é seguro, exatamente como a página declara, contanto que você entenda que "seguro" é igual a "criptografado". Entretanto (e isso é extremamente importante), o usuário não tem como verificar se as credenciais estão sendo enviadas antes de serem enviadas de fato! O site não mostra um certificado autenticando o site para o usuário antes que o formulário seja enviado. É uma questão de confiança, como cair de costas supondo que a pessoa atrás de você irá ampará-lo. No momento em que o formulário é enviado, o dano já ocorreu.
Figura 2 Colírio para os olhos de segurança em uma página não segura (clique na imagem para ampliá-la)
O protocolo SSL que fornece a segurança em HTTPS, serve a duas finalidades importantes. Primeiro, ele autentica o servidor para o usuário. Em segundo lugar, ele fornece um mecanismo fácil para negociar uma chave de criptografia de sessão que pode ser usada entre cliente e servidor.
Quando apenas o envio do formulário é criptografado, o principal objetivo não é alcançado. Os sites que empregam essa otimização usam o SSL apenas para negociar chaves. Ironicamente, eles poderiam fazer isso simplesmente empregando um protocolo de negociação de chaves padrão, evitando assim o custo e a sobrecarga do SSL.
O site mostrado na Figura 2 não é uma raridade. Muitos sites fornecem proteção SSL apenas para o envio do formulário, mas não para o formulário em si. Este site específico, porém, demonstra uma característica muito mais perturbadora. Se você digitar https://www.<site>.com (observe o indicador de https seguro) na barra de endereços do navegador, o site o redirecionará para a versão não-SSL do site! Mesmo que você tente inspecionar um certificado antes de enviar suas credenciais ao site, este se recusará a mostrá-lo.
Nem todos os sites são tão ofensivos, mas há muitos que são. E dois dos maiores emissores de cartão de crédito nos Estados Unidos estão entre os ofensores. Na verdade, das três maiores empresas de cartão de crédito que utilizo, somente a American Express oferece um certificado no formulário de logon. A American Express inclusive redireciona as solicitações HTTP para HTTPS. Parabéns!
Uma consideração final sobre o colírio para os olhos de segurança inútil e a falta de certificados no formulário de logon. Talvez você esteja se perguntando por que um site faria isso. O motivo é simples: por economia. Para apresentar certificados, é necessário criptografar a página, e a criptografia da página cria uma sobrecarga de processamento. Sobrecarga de processamento significa que mais computadores são necessários para atender à mesma carga. E mais computadores significa um custo maior. Infelizmente, quando se trata de escolher entre proteger a privacidade do cliente e aumentar os lucros, muitas organizações optam pelo segundo.

Abrir ou não abrir
Recentemente, recebi uma mensagem de email impressionante de minha empresa de seguro saúde. Qualquer pessoa que use um computador há 10 anos deve saber que nunca se deve abrir anexos de email não solicitado. Então, imagine a minha surpresa quando recebi a mensagem mostrada na Figura 3.
Figura 3 Mensagem de email contendo um "anexo seguro" (clique na imagem para ampliá-la)
Aparentemente, fiz uma pergunta no site da empresa de seguro saúde (e me esqueci disso quando a mensagem suspeita chegou). Foi assim que a empresa me respondeu. A princípio, pensei que era um esquema de phishing inteligente. Quando percebi que era uma mensagem legítima, fiquei de cabelo em pé.
A primeira instrução é para clicar duas vezes no anexo para começar a descriptografar a mensagem. A comunidade de segurança e os administradores de TI em massa passaram os últimos 10 anos tentando ensinar as pessoas a NÃO clicar duas vezes nos anexos. E, então, vem uma empresa (minha empresa de seguro saúde, a propósito, não é a única a usar essa abordagem) e diz que devo clicar no anexo para minha segurança. O que o usuário deve fazer nessa situação? Que comportamento ele aprende ou desaprende?
Em seguida, usei o recurso de visualização no Microsoft® Office Outlook® 2007 para exibi-lo. Como você pode ver na Figura 4, o Outlook achou que essa mensagem era um invasor e me advertiu a não abri-la!
Figura 4 O Outlook 2007 considera o documento de segurança hostil (clique na imagem para ampliá-la)
É irônico e ao mesmo tempo trágico ver uma empresa de seguro saúde violar as verificações básicas de segurança usadas nos clientes de email mais conhecidos do mundo. Considerando que ela nem mesmo se preocupou em testar sua nova solução de segurança com o Outlook, fico imaginando o que mais ela está deve estar fazendo com o intuito de proteger minhas informações particulares. Ou, para ser mais direto, que outras soluções estão sendo implementadas pela empresa apenas para não ser acusada de não proteger de maneira adequada a privacidade do cliente? É como o espetáculo da segurança criado pelas instituições financeiras. Nesse caso, acho que evitar uma acusação, em vez de realmente proteger os clientes, é o principal objetivo da solução.
Quis ver o que era aquele anexo. Na verdade, era um objeto de controle ActiveX®. Para ver o anexo, tive de abri-lo no Internet Explorer® e instalar o objeto. Foi exibida a tela de confirmação mostrada na Figura 5. Como você pode ver, os designers trabalharam muito para fazer a mensagem parecer um envelope de correio comum; ele inclusive contém um selo dizendo que o envelope é confiável.
Figura 5 O documento Seguro mostra um envelope com o selo "Confiável" (clique na imagem para ampliá-la)
Esse tipo de tecnologia é preocupante por vários motivos. Primeiro, ele reforça um comportamento nada saudável por parte do usuário: abrir anexos não solicitados. Em segundo lugar, na mensagem em si, ele apresenta uma orientação perigosa de configurar o sistema para sempre abrir anexos sem avisar. Em terceiro lugar, diante de mensagens conflitantes do computador, em que o email diz que é confiável e o Outlook diz que não é, a mensagem parece muito suspeita. Finalmente, o verdadeiro anexo contém um colírio para os olhos de segurança inútil para convencer o usuário de que é realmente confiável. Se o usuário aprender a confiar nesse tipo de mensagem, estará a um passo de confiar em mensagens mal-intencionadas com uma aparência semelhante.

Fornecendo comunicação segura
Sem dúvida, o problema que essa tecnologia se propõe a resolver é muito importante. É difícil comunicar-se com os clientes de maneira confiável. Entretanto, essa solução específica foi mal planejada. Provavelmente, ela causará confusão no cliente e criará exatamente o problema que deveria solucionar: o comprometimento do sistema do cliente.
Sites melhor planejados agora usam um "centro de mensagens". Nesse projeto, quando a empresa precisa se comunicar com o cliente, ela envia uma mensagem de email que diz algo como: "Você possui uma mensagem no centro de mensagens. Visite nosso site, faça logon e clique no link Centro de Mensagens para exibi-la". Uma empresa ganhará pontos se usar S/MIME (Secure Multipurpose Internet Mail Extensions) para assinar todas as mensagens de email do cliente para que o usuário possa autenticar a fonte. Ela ganhará mais pontos se a mensagem não incluir nenhum item "clique neste link" no email. O usuário deve digitar a URL da empresa à mão para garantir que está visitando o site esperado.
Com um centro de mensagens e uma mensagem assinada, uma empresa pode encontrar um meio confiável para se comunicar com o cliente. Tudo o que o cliente vê durante o fluxo de trabalho da mensagem é autenticado, e a empresa não promove práticas de segurança não recomendáveis.

É sobre privacidade
Até agora, na duas primeiras partes desta série, descrevi como os profissionais de segurança estão na verdade prestando um desserviço aos usuários. A nossa tarefa é manter a segurança. Mas muitas das decisões tomadas e soluções implementadas estão confundindo os usuários, ensinando-os a tomar péssimas decisões e dando-lhes uma falsa sensação de segurança. Não deveríamos sobrecarregar os usuários com essas idéias conflitantes.
Conforme mencionei anteriormente, para os usuários em geral, segurança significa apenas proteger senhas e números de cartão de crédito. Eles querem uma tecnologia que funcione e seja confiável. Infelizmente, eles têm de tomar decisões, e cabe a você garantir que o façam bem informados.
Na última parte desta série, discutirei sobre algumas das mais importantes tecnologias disponíveis aos consumidores que não deixam a desejar. Também apresentarei meu alerta. Portanto, não perca a coluna Security Watch de setembro de 2008.

Jesper M. Johansson é arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele é Ph.D. em sistemas de informações sobre gerenciamento, tem mais de 20 anos de experiência em segurança e é MVP (Most Valuable Professional) da Microsoft em segurança corporativa. Seu livro mais recente é o Windows Server 2008 Security Resource Kit.

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


Computação sustentável Filtrando o greenwashing
Dave Ohara

Sumário
A necessidade dos números
Medindo o uso da energia
Fator de potência
Medindo na produção
O Microsoft Enterprise Engineering Center
Conclusão
Existe um número incrível de produtos e soluções sendo comercializados como ecológicos, econômicos em termos de energia e mais eficientes. Todo esse marketing gera uma confusão no mercado quanto ao que realmente é amigável ao meio ambiente. Mesmo depois de avaliar as especificações de vários produtos, é difícil, se não impossível, para um profissional de TI
determinar qual equipamento deve ser usado quando o impacto ambiental é uma grande preocupação. Quando você assiste a todas as demonstrações, as grandes economias de energia são sempre realçadas, e isso o leva a pensar ser fácil justificar a atualização com base no ROI (retorno do investimento). Afinal, as economias de energia devem reduzir o TCO (custo total de propriedade).
A migração feita por empresas de todos os tipos para rotular praticamente tudo como ecológico e explorar o interesse atual em soluções ecológicas acarretou o conceito de "greenwashing", que se refere a uma promessa excessiva de benefícios ao meio ambiente. E o que há de verdade nas economias de energia? Isso não é tão evidente quanto, digamos, instalar novas lâmpadas econômicas na sua casa.
À medida que aumentam os esforços de uma TI sustentável e o mercado de equipamento de TI ecológico se expande, muitas pessoas e organizações passam ao resultado final da implantação de laptops, desktops e servidores que economizam energia e do uso da virtualização tendo em vista a redução no consumo de energia. Ainda são poucas as organizações que realizam auditorias de energia para determinar os benefícios reais daquilo que compraram.
Embora o cenário ideal seja medir ativamente o ambiente de produção, isso também pode ser caro. Se você não estiver pronto para iniciar a medição na produção, ainda poderá obter um avanço fazendo a auditoria de energia no início do processo, nos seus laboratórios de desempenho e avaliação. (A maioria das empresas conta com um laboratório ou grupo responsável por testar e avaliar equipamentos antes de fazer uma aquisição.) Assim é possível agregar desempenho em termos de energia como um dos critérios de teste e, em seguida, levar esses resultados em conta nas decisões de compra sem depender dos números fornecidos pelos fabricantes. Assim, enquanto testa, você cria seu próprio banco de dados de consumo de energia de dispositivos. Dessa forma, é possível ignorar o greenwashing e ver, você mesmo, o que funciona.
Obviamente, devo ressaltar que, se quiser números muito precisos da operação sob a carga real, você precisará monitorar o ambiente de produção. Quanto mais rápido você começar a monitorar o ambiente de produção, melhor para a organização e os resultados finais. Esse processo será essencial para o sucesso a longo prazo.

A necessidade dos números
Em uma situação ideal, haveria testes independentes que avaliariam o desempenho por watt dos dispositivos de hardware sob cargas de usuário reais. Mas o setor se encontra nos estágios iniciais de desenvolvimento e implantação de testes como esses. E os que já estão disponíveis, como, por exemplo, o parâmetro de comparação SPEC Power, ainda são incipientes. A eficácia com que esses testes de energia funcionarão, uma vez prontos, é algo ainda a ser observado. Mas, assim como acontece com qualquer teste, os fabricantes aprenderão como modificar seus equipamentos tendo em vista os melhores resultados.
Profissionais de TI experientes aprenderam a questionar testes realizados por laboratórios de testes. E assim como as empresas automobilísticas se preocupam em enviar seus melhores carros para os testes em pista, os fornecedores de TI não se esquecem de mandar as configurações mais eficientes de seus equipamentos para os testes de energia.
Considere os testes de virtualização em uso na comparação de um grupo de servidores provisionados em excesso, onde não foi feita nenhuma consolidação de servidor para demonstrar os benefícios da virtualização. Os fornecedores negligenciam a informação de problemas como, por exemplo, os potenciais efeitos de reverberação em projetos de economia de energia como a virtualização. Basicamente, isso se refere ao momento em que a eficiência energética diminui e a demanda cresce em decorrência disso, o que motiva e aumenta o uso da energia. Ao ver uma solução como, por exemplo, a virtualização propalada como a solução para todos os problemas em termos de economia de energia, você deve suspeitar. De fato, você precisa saber como tudo funciona em conjunto e quais serão os efeitos em cascata com o passar do tempo.
E como você descobre o caminho certo para a organização? Há muitos consultores prontos para realizar avaliações a um determinado custo. Mas existem algumas desvantagens importantes nessa abordagem. Você realmente deseja passar a experiência da eficiência para alguém fora da organização? Você quer contar com um consultor que deseja manter um contrato de longa duração e criar uma dependência em relação ao serviço que ele presta?
Você poderia transformar isso em um projeto enorme e ter dezenas de pessoas envolvidas na determinação da estratégia de sustentabilidade ambiental. Não ceda à tentação de escolher um espaço no ambiente e começar a medir. Embora a intenção esteja no lugar certo, a abordagem não tem lógica, uma vez que se trata apenas de uma ação aleatória. Você precisa saber a verdade sobre onde está o consumo de energia e em que ponto é possível obter um impacto.

Medindo o uso da energia
Você precisa pensar de um modo novo no que está funcionando. Os profissionais de TI sabem quando uma peça de hardware não está funcionando se, digamos, um serviço está desativado. Mas e quando uma peça do hardware não está funcionando corretamente em relação ao consumo de energia? É provável que isso não seja detectado porque a maioria das organizações não tem dados para estabelecer um parâmetro de eficiência energética.
Como você consegue esses números? Algumas pessoas sugerem a necessidade de um controle de energia. No entanto, isso requer alguém que possa transitar pela organização da empresa e seja técnico em assuntos de energia. Um método mais simples e viável é adicionar ferramentas de medição da energia a funções existentes em laboratórios de desempenho.
Existem vários dispositivos de medição de energia. Infelizmente, no momento, não há nenhum perfeito para um laboratório de desempenho de TI. Em um cenário mais simples, é possível usar um Watts Up Pro. Trata-se de um dispositivo USB que fornece medição de energia embutida em 120 V. Outro dispositivo é o Smart-Watt, um dispositivo para consumo de energia que pode ser usado em rede cuja tensão é de 100 a 240 V e a amperagem, de 15 a 30 A. Os dispositivos Smart-Watt também estão disponíveis com sensores de temperatura e umidade para medir fatores ambientais. Na seqüência, temos os dispositivos para análise de energia industriais como, por exemplo, o Extech Appliance Tester 380801 e o Fluke 345 Power Clamp. Você não deve enfrentar nenhum problema para encontrar dispositivos como esses que atendam às suas necessidades dos testes em laboratório.

Fator de potência
Caso seja novato na medição de energia, é importante que você compreenda o conceito do fator de potência. O fator de potência de um sistema elétrico CA é definido como a razão entre a potência real e a potência aparente, sendo fornecido em um número entre 0 e 1. Potência real (watts) é a capacidade do circuito de realizar o trabalho. A VA (potência aparente) é o produto da corrente e da tensão no circuito.
Você talvez esteja se perguntando por que isso é importante. Observe a Figura 1. A fotografia mostra um dispositivo de monitoramento de energia da Smart Works sendo usado para comparar a eficiência energética de um laptop, uma lâmpada e um capacitor. Uma lâmpada apresenta uma carga de 50 watts e 50 VA para um fator de potência igual a 1,0. Um capacitor com carga capacitiva total usa 2 watts de carga e 193 VA para um fator de potência igual a 0,01. O laptop está usando 22 watts de potência, mas apresenta 48 VA, o que resulta em um fator de potência de 0,47. O baixo fator de potência do laptop se dá por conta de um projeto de alimentação ineficiente e possivelmente é resultante de uma meta em termos de custo de produção.
Figura 1 Consumo de energia de um laptop, uma lâmpada e um capacitor (Clique na imagem para ampliá-la)
Com tanto interesse na eficiência energética, os fornecedores agora estão procurando melhorar o desempenho de fontes de alimentação sob condições esperadas. Caso compare o fator de potência de um equipamento existente com o de um novo equipamento, você talvez descubra ser possível conseguir mais potência simplesmente escolhendo soluções com fontes de alimentação mais eficientes e fatores de potência maiores.

Medindo na produção
O objetivo da medição dos resultados no laboratório de desempenho é prever o desempenho no ambiente de produção. O problema na medição do consumo de energia na produção é o custo obrigatório à medição de todos os dispositivos. No entanto, uma estratégia para reduzir o custo da medição de energia em produção é medir a PDU (unidade de distribuição de energia) e agregar várias leituras de equipamento. A Figura 2 mostra uma leitura de energia de exemplo feita em uma PDU com várias peças do mesmo equipamento em uma só unidade. Como o consumo de energia médio por servidor pode ser calculado, esse meio de medição proporciona números do consumo de energia para produção.
Figura 2 Medindo uma unidade de distribuição de energia (Clique na imagem para ampliá-la)
Assim que cada peça do equipamento é medida, as informações sobre a alimentação devem ser integradas ao banco de dados para gerenciamento da configuração. Caso isso seja muito difícil, é possível criar um banco de dados próprio ou pelo menos uma planilha do Excel® que liste os dispositivos e seu consumo de energia. À medida que começa a acumular mais dispositivos, você poderá preencher estimativas quanto aos demais para criar um cálculo de capacidade geral de energia. Tenha em mente que um novo servidor econômico consumirá menos da metade da carga de energia quando ocioso em comparação com o pico. E se você tiver servidores antigos com soluções obsoletas em execução, eles consumirão uma quantidade significativa de energia, mesmo quando ociosos. Trata-se de um dos objetivos mais fáceis para recuperar capacidade em termos de energia.
Caso queira dar continuidade aos esforços de melhoria, a próxima etapa é calcular a potência por rack usada no data center. Você também deve compreender as capacidades quanto à potência e à refrigeração ao alterar o ambiente. Com o passar do tempo, você começará a ver o equipamento em termos de potência, e não apenas observando o espaço que ele exige. Espaço é um conceito simples: é estático e visual. Profissionais de TI podem prontamente analisar servidores 1U, 2U e 4U, mas basta começar a falar sobre servidores de 200 watts em comparação com servidores de 450 watts, e você verá que os mesmos profissionais de TI não se sentem tão confortáveis em relação ao assunto. Essa é uma nova linguagem para equipamentos de TI, evidente nos data centers atuais. Muitos têm bastante espaço para mais equipamentos, mas já atingiram a capacidade máxima quanto à potência.

O Microsoft Enterprise Engineering Center
O EEC (Microsoft Enterprise Engineering Center) adicionou recentemente recursos para medição de energia a suas instalações. Localizado no campus corporativo da Microsoft em Redmond, Wash., o EEC (microsoft.com/windowsserver/evaluation/eec/default.mspx) é um campo de teste avançado para os ambientes de computação mais complexos.
Com mais de US$ 40 milhões em equipamentos de hardware e sistema de rede (consulte a Figura 3), o EEC é capaz de suportar as mais complexas recriações de ambientes de produção corporativos reais. O grupo tem parcerias com muitos fornecedores líderes de soluções em sistema de rede, armazenamento e cliente/servidor para oferecer uma combinação de tecnologias de ponta e plataformas herdadas. O objetivo é garantir que cada teste seja um reflexo preciso do ambiente atual do cliente. O mais recente serviço em desenvolvimento nas instalações são relatórios sobre o consumo de energia das soluções para fornecer um parâmetro de comparação por watt.
Figura 3 Uma das muitas fileiras no laboratório do EEC (Clique na imagem para ampliá-la)
Nos últimos anos, o EEC viu muitos operadores de data center ficarem sem energia e refrigeração para o equipamento. Um equipamento avançado normalmente carrega uma grande demanda de energia, o que coloca as instalações sob mais risco. A equipe do EEC compreendeu inicialmente os custos e o tempo envolvidos na atualização da infra-estrutura de energia e refrigeração. Assim, para operar de maneira mais eficiente e ser mais econômico, o EEC agregou a possibilidade de medir a energia por dispositivo.
Algumas das ferramentas e dos equipamentos usados pelo EEC não estavam à disposição no momento em que este artigo foi escrito. Por se tratar de uma nova solução, o EEC continuará desenvolvendo técnicas melhores, trabalhando com clientes, fornecedores e equipes de desenvolvimento da Microsoft. O EEC compartilha os métodos já desenvolvidos até agora diretamente com os clientes para já conhecer seus comentários, o que permite aos clientes criar parâmetros de comparação próprios.
E não pressuponha a obviedade dos resultados. O EEC compartilhou alguns dos resultados mais interessantes obtidos pelo grupo ao usar recursos para monitoramento da energia nos laboratórios de desempenho do EEC:
  1. Desligar um dispositivo não necessariamente reduz tanto o consumo de energia quanto você poderia esperar (consulte a Figura 4). Em um caso envolvendo um hardware de servidor, o EEC descobriu um dispositivo que consumia, de fato, 100 watts quando desligado, mas ainda conectado. Isso surpreendeu muitas pessoas, e o EEC testou a configuração várias vezes. Eles acabaram usando um termômetro infravermelho para medir as temperaturas interna e externa e notaram que o dispositivo, realmente, consumia 100 watts quando desligado.
  2. O software pode apresentar um impacto significativo sobre o consumo de energia. Em comutadores de rede idênticos, com hardware e configurações de BIOS idênticos, a execução de softwares de rede diferentes apresentava 21 por cento de diferença no consumo de energia. Soluções de alta tecnologia com mais processos e recursos habilitados como ferramentas de segurança e monitoramento costumam consumir mais do que similares inferiores.
  3. Em cenários de virtualização, o EEC mediu o consumo de energia em comparação com o uso de E/S e da CPU para determinar quando uma determinada peça do hardware maximiza o desempenho por watt. O EEC descobriu que menos atenção no uso da CPU poderia acarretar o carregamento de muitas máquinas virtuais em uma máquina física, o que acaba diminuindo o desempenho geral por watt.
  4. Dispositivos de maior densidade, como já esperado, têm mais problemas de energia e refrigeração. Durante a implantação de sistemas de maior densidade, a equipe nas instalações de energia e refrigeração deve ser consultada com a maior antecedência possível. Esses dispositivos podem ser bons candidatos a contarem com dispositivos para monitoramento de energia próprios, caso você saiba que o ambiente terá restrições quanto à potência.
  5. Fontes de alimentação duplas podem consumir consideravelmente mais energia do que uma fonte de alimentação única.
  6. Peças de hardware aparentemente idênticas com configurações idênticas podem apresentar uma diferença significativa no consumo de energia. As diferenças observadas foram significativas o suficiente para a equipe do EEC verificar novamente o hardware e garantir que elas estavam configuradas realmente da mesma forma.
  7. As classificações em watts na placa de identificação do produto não são números de consumo reais, e sim a capacidade estimada para fontes de alimentação.
  8. Manter um banco de dados de testes e resultados de consumo de energia por dispositivo e subcomponente é essencial para que haja informações e dados comparativos.
  9. Configurações diferentes de quantidades equivalentes de RAM consomem volumes de energia distintos. Menos DIMMs normalmente consomem menos energia – por exemplo, 4 DIMMs de 2 GB em comparação com 8 DIMMs de 1 GB. Mas houve casos em que menos DIMMs consumiram menos energia.
Figura 4 Comparação de energia entre ligado e desligado (Clique na imagem para ampliá-la)

Conclusão
Adicionando a possibilidade de medir o consumo de energia nos laboratórios de desempenho, é possível começar a acumular um banco de dados próprio do consumo de energia por dispositivo com números precisos referentes a cargas reais. Ao implantar essas soluções, você deve auditar os resultados usando comentários fechados a fim de determinar a precisão dos testes em laboratório de desempenho. Como o EEC aprendeu executando testes de medição próprios, existem alguns detalhes realmente interessantes que podem ser observados para ajudar você a filtrar o greenwashing e descobrir a verdade.
Esse método de medição em laboratórios de desempenho influenciará o mercado como um todo a começar a identificar o que é verdadeiramente mais econômico. E, com o passar do tempo, os fabricantes acharão necessário fornecer dados mais precisos quanto ao que se considera econômico de energia. Da mesma forma, com o tempo, os profissionais de TI falarão normalmente sobre watts por dispositivo como critério de aquisição. Isso precisa ser uma prática comum, especialmente para empresas que compram grandes quantidades de servidores. No entanto, é possível dar o primeiro passo, começando a pensar hoje mesmo na energia como um dos recursos de TI mais importantes.
Mantendo a refrigeração no data center
A refrigeração do data center oferece um enorme potencial para reduzir o consumo de energia. É impressionante o calor que pode ser gerado em um data center e quanta energia se usa para manter o hardware refrigerado. Mas se quiser gerenciar a refrigeração com êxito, corrigir problemas e desenvolver soluções em refrigeração mais eficientes, você precisará de uma solução em monitoramento de temperatura. Considere a solução usada nos data centers da Microsoft.
A Divisão de Pesquisa da Microsoft criou uma rede de sensores de temperatura destinada aos data centers que proporciona um melhor controle de temperatura e também permite a avaliação de vários aperfeiçoamentos de refrigeração. Por exemplo, um data center da Microsoft estava avaliando as cortinas de ar ao final do corredor para melhorar a divisão entre ar quente e ar frio. Depois que as cortinas foram instaladas, alguns servidores começaram a enviar alarmes de superaquecimento. Naturalmente, os engenheiros de operação aumentaram o fluxo de ar saído do sistema de refrigeração para proporcionar mais ar frio. Para sua surpresa, porém, mais servidores enviaram alarmes de superaquecimento. E todos esses servidores estavam na parte inferior do rack – a parte de baixo, claro, costuma ser a área mais refrigerada em um sistema de refrigeração acima do chão.
Usando a rede de sensores, os engenheiros confirmaram que os racks estavam mais refrigerados na parte de cima, com a parte inferior do rack permanecendo mais quente. E logo imaginaram que o ar quente estava saindo do corredor quente entre a parte inferior do rack e o chão – resultado do princípio de Bernoulli. Eles corrigiram facilmente o superaquecimento vedando a parte inferior do rack e diminuindo a velocidade do fluxo de ar.
É exatamente esse tipo de dados que o Microsoft Enterprise Engineering Center coleta e analisa ao fazer o teste de desempenho. Assim, o EEC notificou recentemente a Divisão de Pesquisa da Microsoft de que estavam prontos para um teste de implantação. Em um dia, o sistema foi implantado em 10 racks, e a instalação demorou apenas uma hora para ser concluída. Agora o EEC pode estudar e compreender melhor os problemas de refrigeração e sua relação com o desempenho do software.
Obviamente, o simples monitoramento não é uma solução em si. O ganho real está na possibilidade de encontrar áreas com problemas que possam ser corrigidas, fazer alterações e avaliar várias soluções para ver se elas apresentam os resultados esperados. Afinal, você não desejará ser surpreendido quando a nova solução em refrigeração causar superaquecimento nos racks inesperadamente.

Dave Ohara tem 26 anos de experiência em tecnologia. Atualmente ele trabalha com várias empresas na implementação de iniciativas ecológicas.

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


Anotações de campo IMAP salva o mundo
R'ykandar Korra'ti

Às vezes, as soluções para novos e pequenos problemas podem resolver grandes e antigos problemas também. É o caso desta.
No início do ano, nossa administradora da Web trouxe um MacBook. Ela executava o Windows® de forma exclusiva, mas agora ela teria o OS X e, em uma máquina virtual, o Windows XP para sincronizar seus dispositivos Windows Mobile® e outras pequenas tarefas.
Ela precisava de acesso a todos os arquivos de email dos dois sistemas operacionais. Mas não queria executar o Entourage no Mac (isso seria muito fácil). Não, ela queria executar o Mail.app, o cliente de email incluído no OS X. Por acaso, ela mantinha tudo no armazenamento local de seu laptop, sem espelhamento. Minha tarefa: recuperá-los.
Fazer com que os arquivos possam ser lidos em qualquer lugar apresentava apenas um pequeno problema mencionado anteriormente, pois (e essa é a primeira moral de nossa história) tudo, inclusive o Exchange Server, o Microsoft® Office Outlook® e o Mail, usa IMAP4, que é um protocolo de sistema de mensagens para manipular armazenamentos de mensagens no servidor em clientes finos. Ele possui menos recursos do que os usuários do Exchange gostariam de ter, mas funciona (consulte Como funciona: IMAP4 na edição de março-abril de 2006 da TechNet Magazine em technet.microsoft.com/magazine/cc161016).
Alteramos então algumas configurações para colocar o IMAP4 sobre SSL online, copiamos todas as suas pastas locais para o servidor e ping! Ela conseguiu acessar o email em todos os clientes e manter os dispositivos do Windows Mobile atualizados. Problema resolvido.
Mas apresentar uma solução simples para um problema potencialmente complexo é como ter uma nova serra de mesa. De repente, você começa a buscar mais madeira e, quando vê, tem um palco inteiro pronto para encenar "Romeu e Julieta".
Nosso pequeno ISP executa Windows, OS X, Mac OS, Linux e tem inclusive um antigo e solitário sistema AmigaOS à espreita, procurando um amigo. Muito tempo atrás, hospedávamos notícias Usenet e email UUCP no Amiga. Ele criava arquivos mortos armazenados em um formato RFC-733/AmigaUUCP. Também temos arquivos mortos do Microsoft Mail (formato .mmf) e alguns arquivos mortos de email UNIX igualmente antigos (formato .mbox). Eles estavam todos quietos ali, zombando de nós – um problema que consideraríamos eventualmente e do qual fugiríamos assustados.
Este cenário nos leva à segunda moral da nossa história, o sábio provérbio da Danger Hacker: nunca apague o que não pode ser substituído.
Resolvemos nos dedicar aos arquivos mortos do Microsoft Mail primeiro. O Outlook já não é capaz de importar os arquivos .mmf há algum tempo. Mas, ao atualizar os clientes com o passar dos anos, mantivemos pelo menos uma licença de cada produto antigo por via das dúvidas. Assim, nossa pilha de licenças representa uma linha do tempo da Microsoft Corporation. Precisamos de MS-DOS®? OS/2 1.31? Microsoft Mail? Office 95? Não tem problema! Você quer em inglês ou em francês?
O Outlook 2000 importava .mmf, mas seu suporte a IMAP era estranho e ocasionalmente descartava dados de cabeçalho. Além disso, ele não se comunicava com os servidores IMAP4 e Exchange ao mesmo tempo. Isso era irritante, mas não um impedimento. Importamos os arquivos .mmf usando o Outlook 2000, atualizamos para a licença mantida do Outlook 2003 e, depois de algumas horas arrastando e soltando, arquivos mortos de 15 anos estavam online e podiam ser exibidos em qualquer lugar. Da mesma forma que para .mbox, iniciamos um servidor IMPA compatível com mbox em um computador Linux e colocamos os arquivos mortos no formato .mbox em seu diretório de trabalho. Em seguida, usamos o suporte a IMAP do Outlook para conectar e copiar as pastas para o servidor de produção escolhido.
Para os arquivos mortos do Amiga, porém, foi preciso escrever um pequeno pacote de código C para converter os cabeçalhos RFC-733 em RFC-822, eliminar os antigos divisores de mensagens SysV e recuperar os dados estranhos da linha De: do grande caos em que residiam. Esse é o preço a pagar por deixar os problemas sem solução por muito tempo. Mas, depois de resolvido, o formato AmigaUUCP tornou-se .mbox. E, colocado no mesmo diretório de trabalho, o IMAP4 do Outlook recuperou todo o email, como se fosse recente. Ele até empacotou os anexos direitinho para nós.
Agora, temos os arquivos mortos de 1990 online em um formato unificado, e estamos procurando mais... só porque podemos. Isso é saudável?

R'ykandar Korra'ti, postmaster de um pequeno ISP cooperado, vive perto de Seattle com sua companheira, Anna. Anteriormente trabalhou para a Microsoft fornecendo produtos de email. Agora escreve artigos técnicos quando não está trabalhando em alguma intrincada letra de música para bandolim. Os agentes que desejarem poderão contatá-la pelo email darako@murkworks.net.


Segredos do Windows Expandindo o passado
Raymond Chen

Um colega meu resgatou uma máquina Alpha AXP de um armário empoeirado. Ao inicializar o sistema, descobriu que ela estava executando uma versão 64 bits do Windows® desde o início de 2000. Como isso é possível?"
Por acaso, eu tinha uma dessas máquinas no meu escritório. Basicamente, essa máquina era uma força a ser respeitada. Era aproximadamente do tamanho de uma geladeira pequena e gerava um ruído semelhante ao de um aspirador de pó. Ela contava com quatro – isso mesmo, quatro! – processadores Alpha AXP, cada um operando a incríveis 400 MHz, e possuía um gigabyte de RAM e treze gigabytes de espaço no disco rígido, sem contar uma dezena de unidades SCSI rápidas. Isso pode parecer insignificante hoje, mas, nos anos 90, essas máquinas Alpha AXP eram o objeto mais cobiçado e faziam de você o garoto mais popular na hora do intervalo.
Em 1999, quando a Compaq anunciou que não ofereceria mais suporte ao Windows na Alpha AXP, muitos sistemas Alpha AXP acabaram sendo descartados na Microsoft sem nenhuma cerimônia. Porém, algumas dessas máquinas passaram a realizar várias tarefas não oficiais. Usei o meu sistema Alpha AXP para indexar todo o código-fonte do Windows. É possível imaginar como pode ser prático para um programador poder identificar todos os chamadores de uma função em apenas alguns segundos ou localizar no código-fonte uma função ou caixa de diálogo exibida em um rastreamento de depuração.
Mas, mesmo para a tarefa simples de indexar o código-fonte do Windows, a Alpha AXP foi rapidamente superada pelas máquinas de classe x86. Elas eram mais baratas e mais rápidas, além de oferecer muito mais espaço em disco e ter muito mais memória. Por esse motivo, a minha máquina logo se juntou aos irmãos esquecidos. Pressupunha-se que o fim do suporte à Alpha AXP fosse o fim dessas máquinas, mas elas logo tiveram a oportunidade de vivenciar mais uma vez o sucesso, dando os últimos suspiros a serviço da próxima geração.
O projeto Windows de 64 bits já estava bem adiantado e os processadores de 64 bits estavam sendo analisados; somente a Alpha AXP estava realmente disponível em termos físicos. O Intel Itanium ainda estava em desenvolvimento e só operava em simulador, e a arquitetura AMD64 sequer havia sido inventada. Dessa forma, o Windows de 64 bits foi inicialmente desenvolvido na Alpha AXP.
Quando a Compaq anunciou que não daria mais suporte ao Windows na Alpha AXP, todas essas máquinas Alpha AXP que tinham sido usadas no desenvolvimento e nos testes do Windows 2000 de 32 bits ganharam uma outra finalidade e começaram a prestar o serviço secreto como máquinas de teste para sistemas operacionais de 64 bits que jamais saíram dessa forma. A Alpha AXP era apenas uma plataforma de verificação do conceito.
As máquinas Alpha AXP cumpriram bem essa função, oferecendo à equipe do Windows de 64 bits um hardware real com o qual trabalhar, em vez de precisar executar o sistema operacional em um simulador Itanium. (Você não tem idéia de como era lento.) É claro que a Alpha AXP não era o hardware final desejado, mas ajudou muito. E quando as CPUs físicas Itanium começaram a aparecer, o nicho preenchido pelas Alpha AXPs desapareceu, e elas mais uma vez foram recolhidas a armários empoeirados.
Meus colegas que trabalham nos Arquivos da Microsoft tiraram a minha boa e velha Alpha AXP do armário empoeirado para esta foto, posando com um dos produtos que ela ajudou a tornar possível: a edição de 64 bits do Microsoft Windows Server® 2003. E, sim, a poeira é de verdade.

O site de Raymond Chen, The Old New Thing, e o livro homônimo (Addison-Wesley, 2007) tratam da história do Windows e da programação Win32. Ele prefere não ser guardado em um armário empoeirado.