Artigo original publicado na terça-feira, 26 de junho de 2012
Uma das primeiras ações que a maioria dos Administradores do Exchange geralmente fazem ao resolver problemas suspeitos com a Indexação de Conteúdo do Exchange será recompilar os arquivos de índice de conteúdo do Banco de dados da Caixa de correio impactada (manualmente ou usando o script ResetSearchIndex.ps1 encontrado no diretório \Exchange Server\Scripts). Eu também trabalhei com vários administradores do Exchange em vários anos que escolhem recompilar proativamente os índices de pesquisa em vários pontos durante o ano ou como várias etapas dentro de um projeto (como um projeto de migração, como exemplo).
Independente da justificativa para redefinir os índices, a maioria dos administradores, quando perguntados, não poderão fornecer estimativas reais de quanto tempo este processo levará. As consequências não desejadas de não estimar este tempo com precisão irão diferir de acordo com a organização. Alguns departamentos de TI podem desencorajar não ter índices laterais do servidor disponíveis para os usuários durante o dia comercial citando perdas na produtividade do usuário final e pequenos aumentos nos problemas escalados no Atendimento ao Cliente. De uma perspectiva operacional, não ter o conhecimento do tempo de recompilação antecipadamente também pode evitar que os administradores do Exchange sejam alertados sobre potenciais problemas com o próprio processo de recompilação. Seja qual for a justificativa, ter uma total compreensão de quanto o tempo vai levar é valioso.
É certo que há pouca informação sobre a quantidade de tempo que leva (ou melhor ainda, o tempo que deve levar) para recompilar o índice de conteúdo do Exchange disponível hoje. Aparentemente, isto ocorre porque os tempos de recompilação reais são sempre variáveis. Pode haver vários fatores que influenciam as taxas de recompilação e o tempo para concluir. Principalmente:
Na Microsoft (em nossa implementação empresarial, assim como em várias ofertas do Office-365), utilizamos uma Estrutura de recompilação de pesquisa desenvolvida pelo meu colega Anatoly Girko e eu. Esta estrutura foi projetada originalmente para oferecer para nossa equipe de operações internas um conjunto de etapas de validação completas e indicadores de progresso que eles podem analisar ao realizar recompilações de índices de conteúdo. Estas técnicas são utilizadas em várias etapas fundamentais dentro do processo de recompilação geral para garantir a conclusão com sucesso.
Como a estrutura evoluiu, decidimos adicionar uma funcionalidade que nos permite rastrear e armazenar um histórico de métricas de resultados para toda e qualquer operação de recompilação. Como estes conjuntos de dados cresceram, e como os dados de tendências subsequentes apareceram, descobrimos que podemos fazer estimativas mais informadas e mais precisas sobre quanto tempo uma determinada operação de recompilação pode levar. Isto, por sua vez, nos permitiu como uma equipe operacional tomar melhores decisões sobre quando programar recompilações para que possamos minimizar a interrupção para nossa base de clientes do usuário final. Desde o início, esta estrutura foi utilizada para supervisionar as operações de compilação para milhares de índices de conteúdo dentro dos vários ambientes que suportamos.
Em uma série de artigos, discutiremos nossa “Estrutura de recompilação” para que as partes interessadas possam aplicar uma metodologia semelhante em seus próprios ambientes caso seja necessário. Cada etapa da estrutura será detalhada, incluindo as discussões sobre os vários conjuntos de ferramentas que criamos para ajudar neste processo. Esta série será concluída com uma série de gráficos e tabelas que detalham nossas estatísticas de recompilação do índice de conteúdo e conclusões até o momento. Para os clientes que não rastrearam as estatísticas nesta área anteriormente, esperamos que isso sirva como um ponto de referência valioso. Provavelmente fornecerá a habilidade de realizar estimativas mais informadas sobre o tempo de recompilação do índice de conteúdo do Exchange em seus próprios ambientes. Isso dito, vale observar que devido a todos os ambientes do Exchange serem únicos, suas métricas de recompilação podem diferir drasticamente das taxas que observamos e apresentamos aqui.
Antes de mergulhar a "cabeça primeiro", é importante mencionar que esta série não é destinada como um guia de resolução de problemas. Nossa expectativa é que sua própria resolução de problemas que levou a decisão de realizar a recompilação em resposta a um problema ou como uma medida proativa. Todos os exemplos apresentados nesta série focalizarão no Exchange 2007. Tomei a decisão de concentrar no 2007 para esta publicação porque a probabilidade de recompilar índices de 2007 são significantemente maiores quando contrastado com o 2010 (diferente do 2007, o 2010 possui a capacidade de semear novamente Índices de conteúdo de fontes redundantes íntegras, criando a necessidade de realizar recompilações de índice completas muito mais raramente em arquiteturas de múlti-cópias). Nas próximas semanas, Anatoly e eu lançaremos uma publicação complementar fornecendo a referência de script para a versão de Exchange 2010 do script Analisador de Recompilação do Índice de Conteúdo, conforme acumulamos exemplos correspondentes para seu uso.
Dentro da Microsoft, o principal conjunto de ferramentas que usamos ao recompilar Índices de Conteúdo é o script IndexRebuildAnalyzer. Este script foi criado por Anatoly e eu especificamente para estabelecer as linhas de base de recompilação do Índice de Conteúdo. Como observado anteriormente, existem duas versões deste script; uma versão do Exchange 2007 e uma versão do Exchange 2010. Para calcular suas estatísticas adequadamente, sempre use o script que corresponde a versão do Banco de dados de Caixa de correio do Exchange cujo índice será recompilado. O script IndexRebuildAnalyzer gera dois tipos de métricas dependendo do modo de operação passado pelo operador. Internamente, mencionamos estes dois modos como “métricas pré-compiladas” e “métricas pós-recompilação” (todas as propriedades estão documentadas dentro da seção de Referência do Script abaixo).
Embora este script seja primariamente nivelado para rastrear as operações de recompilação do Índice de Conteúdo, os Administradores do Exchange podem certamente utilizar o script no “pré-modo” para obter estatísticas Point-In-Time (PIT) para vários objetivos centralizados na caixa de correio (por exemplo, “Número de caixas de correio”, “Número de itens em um banco de dados”, “Tamanho médio da mensagem” para toda sua organização, etc.). Isto pode, por exemplo, oferecer óticas adicionais e capacidades para tendenciar a ferramenta do usuário ser nivelada regularmente dependendo dos seus próprios requisitos ou necessidades comerciais.
Os parâmetros E2K7_IndexRebuildAnalyzer.ps1 script, assim como os exemplos para uso podem ser obtidos passando o parâmetro -Help na sessão do PowerShell antes da execução do script.
A tabela a seguir destaca cada parâmetro:
“MailboxServerName\StorageGroupName\DatabaseName”
Estatísticas para vários bancos de dados podem ser calculadas pela vírgula separando os nomes dos bancos de dados.
Como definido acima, o "modo de operação" do script é determinado pela presença ou ausência da opção -PostRebuild. Para obter métricas pré-compilação, a opção -PostRebuild não será utilizada. Quando o script é instanciado no pré-modo, os seguintes Cabeçalhos serão apresentados com as métricas correspondentes:
Quando a opção -PostRebuild é utilizado, o IndexRebuildAnalyzer tentará calcular as métricas de resultado para as operações de recompilação do Índice de Conteúdo. Faz a análise do Log de eventos de aplicativo para obter o horário inicial (denotado pela ID do evento 109) e conclusão da recompilação (denotado pela ID do evento 110) para cada banco de dados da caixa de correio no servidor da caixa de correio. Para calcular as métricas pós-recompilação com sucesso, o par da ID de Evento completo deve estar presente no Visualizador de eventos para cada banco de dados da caixa de correio cujo Índice de Conteúdo correspondente foi reiniciado. Em situações onde o par da ID de evento não está disponível, o script não poderá calcular as estatísticas. Nestas situações, a cadeia “NoEventsFound” será retornada. Os motivos mais comuns porque esta cadeia deve ser retornada são:
Todos os cabeçalhos “pré-recompilados” e métricas também são calculados sempre que a opção -PostRebuild é passada para a execução do script. O uso da opção -PostRebuild incluirá a adição dos seguintes cabeçalhos e métricas:
Cabeçalho
Descrição
Tempo inicial de recompilação do índice de conteúdo
A Hora inicial de quando o serviço do Indexador de pesquisa começa o Rastreamento completo do banco de dados da caixa de correio.
Tempo final de recompilação do índice de conteúdo
O Tempo de conclusão de quando o serviço do Indexador de pesquisa concluiu o Rastreamento completo do banco de dados da caixa de correio
Tempo total de recompilação: H:Min:Seg
Tempo total em Horas:Minutos:Segundos necessários para o serviço do Indexador de pesquisa concluir o Rastreamento completo do banco de dados da caixa de correio.
Tempo total de recompilação: Min Total
Tempo total em Minutos necessários para o serviço do Indexador de pesquisa concluir o Rastreamento completo.
Tempo total de recompilação: Seg Total
Tempo total em Segundos necessários para o serviço do Indexador de pesquisa concluir o Rastreamento completo.
Recompilar: Por média da caixa de correio: Seg
Tempo médio em Segundos para concluir o Rastreamento completo por caixa de correio.
Recompilar: MB por/seg
Indexador de pesquisa Rastreamento completo média de resultado em MB/por segundo.
Recompilar: Itens por/seg
Indexador de pesquisa Rastreamento completo resultado em Correio Itens/por segundo.
É possível baixar o script do analisador de recompilação de índice do Exchange 2007 aqui.
Na parte 2 desta série, discutirei a estrutura de recompilação de pesquisa e na parte 3 desta série, discutirei o que vimos até o momento dentro da Microsoft.
Eric Norberg Engenheiro de ServiçoExclusivo do Office 365
Esta é uma publicação localizada. Encontre o artigo original em Establishing Exchange Content Index Rebuild Baselines – Part 1
Artigo original publicado na quarta-feira, 27 de junho de 2012
Na Parte 1 desta série, eu expliquei o script E2K7_IndexRebuildAnalyzer.ps1. Neste artigo, eu discutirei a Estrutura da recompilação de pesquisa que Anatoly Girko e eu desenvolvi. Esta estrutura foi projetada originalmente para oferecer a nossa equipe de operações internas com um conjunto de etapas de validação completas e indicadores de progresso que podem analisar quando realizar recompilações de índices de conteúdo.
Em nosso ambiente, sempre que uma decisão é feita para recompilar arquivos do Índice de conteúdo do banco de dados de caixa de correio do Exchange, o Operador começa o primeiro cálculo de estatísticas de pré-compilação para o repositório impactado. estas estatísticas são sempre gravadas no CSV para fins de documentação e são eventualmente inseridas em nosso histórico de conjunto de dados. No entanto, como discutido, o uso do parâmetro -CSVFile é opcional. Em situações onde o parâmetro -CSVFile não é passado, o resultado correspondente será gravado na janela de console do shell. Para melhor leitura, você deve ajustar a Largura do tamanho de armazenamento da tela e a Largura do tamanho da janela do console para acomodar adequadamente todos os cabeçalhos e métricas que serão resultados. Isto permite você ler os valores de forma mais fácil na sessão do console. Desde ponto, eu geralmente "canalizo" o resultado para a Tabel-Format (ft) com o parâmetro -AutoSize (-a).
Exemplo de Console:
.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 | ft -a
Resultado:
Exemplo de CSV:
.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -CSVFile c:\ericnor\NA-1ERICNOR-1_PreRebuild.csv
As pré-métricas são contrastadas contra o conjunto de dados históricos e um tempo médio para concluir a estimativa de recompilação é derivada. Levamos em conta a localização regional do banco de dados da caixa de correio e as caixas de correio do usuário final correspondente. Com base na geografia e o tempo estimado para concluir a programação do trabalho de recompilação para a data e hora onde a atividade do usuário está armazenadas é minimizada.
Os operadores no seu ambiente continuam a reinicialização do Índice de Conteúdo para o banco de dados de caixa de correio utilizando as técnicas documentadas em Como recompilar o catálogo de índice de texto completo.
Nos exemplos que seguem, eu irei redefinir os arquivos do Índice de Conteúdo para dois bancos de dados de caixa de correio dentro do meu ambiente. Estes dois repositórios também tem grandes contagens de caixas de correio, tamanhos de arquivo EDB e contagens do item do banco de dados coletivas no servidor da caixa de correio agrupada NA1-ERICNOR-1:
Após os arquivos de Indexação de Conteúdo existentes serem removidos do sistema de arquivos e o serviço do Indexador de pesquisa do Microsoft Exchange ter sido subsequentemente reiniciado, é responsabilidade do thread MonitorAndUpdateMDBList determinar o estado atual dos Índices de Conteúdo para todos os bancos de dados de caixa de correio no servidor de caixa de correio habilitado para o Índice de Conteúdo. Quando o thread MonitorAndUpdateMDBList determinar o Estado de integridade do índice de conteúdo para cada banco de dados de caixa de correio, coloca cada valor do Estado de integridade do banco de dados de caixa de correio na memória. Se o valor do Estado de integridade do índice de conteúdo é igual a “Novo”, o Serviço do indexador de pesquisa da Microsoft determinou que o Rastreamento completo é necessário para trazer os arquivos do Índice de Conteúdo para um estado de Integridade (“Integridade” sendo o ponto onde o índice é mantido atualizado através da Notificação de Repositório). É neste momento que o serviço do Indexador de pesquisa do Exchange inicia a operação Rastreamento completo no banco de dados da caixa de correio impactado.
O momento que a operação Rastreamento completo realmente começa é observado no log de Evento de Aplicativo pela ID de Evento 109.
Para garantir que todas as operações de Rastreamento completo tenham começado no sistema, o operador realizando o trabalho irá validar a presença da ID de Evento 109 em cada banco de dados de caixa de correio cujo Índice de conteúdo foi anteriormente redefinido na Etapa 2.
Como ilustrado no exemplo anterior dos arquivos de Índice de Conteúdo para o NA1-ERICNOR-1-DB1 e NA1-ERICNOR-1-DB18 foram reiniciados utilizando o script ResetSearchIndex. Para validar que o serviço do Indexador de pesquisa do Microsoft Exchange tenha começado as operações de Rastreamento completo, uma ID de evento 109 exclusiva deve estar presente em cada banco de dados de caixa de correio no servidor de caixa de correio. Este parece ser o caso:
Tipo de evento: Informação Fonte de evento: Indexador de pesquisa do MSExchange Categoria do evento: Geral ID de Evento: 109 Data: 10/5/2012 Hora: 14:22:19 horas Computador: NA1-ERICNOR-1-A Descrição: O Indexador de Pesquisa do Exchange criou um novo índice de pesquisa e realizará um rastreamento completo para o Banco de dados de caixa de correio NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).
Tipo de evento: Informação Fonte de evento: Indexador de pesquisa do MSExchange Categoria do evento: Geral ID de Evento: 109 Data: 10/5/2012 Hora: 14:22:20 horas Computador: NA1-ERICNOR-1-A Descrição: O Indexador de Pesquisa do Exchange criou um novo índice de pesquisa e realizará um rastreamento completo para o Banco de dados de caixa de correio NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).
Nota: Ao invés de inspecionar o Log de eventos visualmente, outra técnica viável deve ser simplesmente nivelar o cmdlet Get-EventLog e gravar os eventos Iniciais para o CSV. Exemplo:
Get-EventLog "Application" | Where-Object {$_.EventID -eq 109} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_StartEvents.csv
Tendo validado que as operações de Rastreamento completo iniciaram (através da presença da ID de Evento 109) o Operador monitora o progresso de recompilação geral através do Monitor do Sistema. Especificamente, os seguintes Objetos e Contadores devem ser monitorados:
Revisando o objeto MSExchangeSearchIndexer, um Operador pode facilmente determinar quantos Índices de Conteúdo no servidor estão atualizados e quantos estão sendo rastreados ativamente. Quando um Servidor da Caixa de Correio está completamente atualizado atualizado, o valor para o contador “Número de bancos de dados sendo rastreados” sempre será igual a 0 e o valor do contador “Número de bancos de dados sendo atualizados por notificações” será igual ao número de Bancos de dados de caixa de correio que estão habilitados para Indexação de Conteúdo no servidor.
No meu exemplo, eu tenho dezoito Bancos de dados de caixa de correio total no meu servidor de email e dois deles estão atualmente passando pelo Rastreamento completo. Portanto, o valor para “Número de bancos de dados sendo rastreados” deve ser igual a 2 e o valor de “Número de bancos de dados indexados sendo atualizados por notificações” deve ser igual a 16, nos quais são:
Quando os bancos de dados de caixa de correio individuais concluírem o Rastreamento completo, você observará alterações específicas em vários contadores de objeto no Monitor do sistema.
No nível do Indexador de Pesquisa do MSExchange:
No nível de Índice do banco de dados de caixa de correio:
Em um Exchange Server onde todos os Índices de conteúdo estão completamente atualizados, você deve esperar ver o seguinte:
No meu exemplo, todos estes valores são Verdadeiros, portanto, eu posso assumir que os índices foram recompilados com sucesso e que por uma perspectiva de Índice de Conteúdo que o servidor está completamente Íntegro:
Quando todos os Índices de Conteúdo parecem estar atualizados através do Monitor do Sistema, o Operador realizando o trabalho deve continuar a revisar o Log de Eventos de Aplicativo e validar a presença do ID de evento 110 que é o evento de conclusão do Indexador de pesquisa do Microsoft Exchange para o Rastreamento completo. Semelhante a ID de Evento 109, haverá uma entrada de evento 110 exclusiva para cada Banco de dados de caixa de correio que concluir o Rastreamento completo:
Tipo de evento: Informação Fonte do evento: Indexador de Pesquisa do MSExchange Categoria do evento: Geral ID de Evento: 110 Data: 10/5/2012 Hora: 17:39:47 horas Computador: NA1-ERICNOR-1-A Descrição: Indexador de Pesquisa do Exchange concluiu um rastreamento completo (indexação) do Banco de dados de caixa de correio NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).
Tipo de evento: Informação Fonte do evento: Indexador de Pesquisa do MSExchange Categoria do evento: Geral ID do Evento: 110 Data: 10/5/2012 Hora: 17:11:47 horas Computador: NA1-ERICNOR-1-A Descrição: Indexador de Pesquisa do Exchange concluiu um rastreamento completo (indexação) do Banco de dados de caixa de correio NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).
Nota: Ao invés de inspecionar o Log de Eventos visualmente, outra técnica viável seria simplesmente aproveitar o cmdlet Get-EventLog e gravar os eventos de Conclusão para o CSV. Exemplo:
Get-EventLog "Application" | Where-Object {$_.EventID -eq 110} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_CompletionEvents.csv
Na Etapa 5, é assumido que o operador tenha validado a conclusão do Rastreamento completo de cada Banco de dados de caixa de correio. Neste ponto que o operador deve coletar as métricas Pós-recompilação para determinar as características do resultado para cada Banco de dados de caixa de correio que passou pelo rastreamento.
Para coletar estas métricas, o script E2K7_IndexRebuildAnalyzer é utilizado nivelando a opção -PostRebuild.
Como mencionado anteriormente, o -PostRebuild analisa os logs do Evento de Aplicativo para a presença da ID de Evento 109 e ID de Evento 110. No caso da Replicação de Cluster Contínuo, o Log de Evento de Aplicativo para cada nó no Cluster CCR é avaliado. Se o script pode localizar estas IDs de evento, calculará o tempo total (em vários incrementos de tempo) necessários para concluir o Rastreamento completo em cada Banco de dados de caixa de correio. Retornará para o operador as características de resultado para cada operação de recompilação.
É novamente importante observar que todos os Bancos de dados de caixa de correio no Servidor de caixa de correio serão avaliados independente se todos os Bancos de dados de caixa de correio tiveram seus Índices de Pesquisa recompilados. Além disso, se instanciado sem a opção -CSVFile, o conjunto de resultados serão encaminhados para a janela de console. Ao calcular as estatísticas Pós-recompilação, eu incentivo nivelar o -CSVFile, pois realiza o relatório, classificação, filtragem e dinamização muito facilmente quando o Excel é nivelado.
.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -PostRebuild -CSVFile c:\ericnor\NA1-ERICNOR-1_PostRebuild.csv
Após o E2K7_IndexRebuildAnalyzer ter concluído a execução, o arquivo CSV pode ser inspecionado. A revisão do CSV mostra que todos os Bancos de dados de caixa de correio do Exchange no Servidor de caixa de correio foram processados. A cadeia “NoEventsFound” está sendo devolvida para vários Bancos de dados de caixa de correio do Exchange porque a combinação do par da ID de Evento do Indexador de pesquisa não pode ser localizada. Neste exemplo, existem 16 Bancos de dados de caixa de correio relatando “NoEventsFound” e dois Bancos de dados de caixa de correio com métricas de pós-recompilação válidas:
Este conjunto de resultados pode ser ainda mais refinado aplicando um filtro baseado em texto simples no Excel. Aplicando o filtro para qualquer cabeçalho da coluna de pós-recompilação e desmarcando a cadeia “NoEventFound”, apenas os bancos de dados com métricas de pós-recompilação válidas serão exibidos:
O resultado de aplicar este filtro no conjunto de resultados de exemplo mostra agora apenas NA1-ERICNOR-1-DB1 e NA1-ERICNOR-1-DB18 (por exemplo, os Bancos de dados de caixa de correio que tinham seus Índices de conteúdo redefinidos). Também está claro que as métricas de pós-recompilação foram verificadas com sucesso, pois há valores válidos para os vários cabeçalhos de pós-recompilação:
Aplicativo do Filtro de Pós-Cadeia:
A Etapa 6 na Estrutura de recompilação valida que cada caixa de correio hospedada nos Bancos de dados de caixa de correio com seus Índices de Conteúdo redefinidos podem agora retornar respostas de pesquisas válidas. Este objetivo pode ser obtido nivelando a funcionalidade principal contida dentro do cmdlet Test-ExchangeSearch. A validação final é concluída apenas quando todas as caixas de correio retornam uma resposta Verdadeiro para o cmdlet.
Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG1\ NA1-ERICNOR-1-DB1 | Test-ExchangeSearch | ft -a
Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG18\ NA1-ERICNOR-1-DB18 | Test-ExchangeSearch | ft -a
Este processo levará algum tempo para concluir dependendo do número de caixas de correio contidas dentro de um banco de dados. Também vale a pena observar que ao realizar operações em lote com o Test-ExchangeSearch que as propriedades ResultFound e SearchTime estarão visíveis na janela de console apenas após todas as caixas de correio tiverem sido processadas (independente dos resultados Verdadeiro ou Falso). Em alguns casos, não faz sentido armazenar todos os resultados no CSV para fins de documentação.
Qualquer caixa de correio do usuário final relatando Falso para o teste Test-ExchangeSearch é tratada como problemas 1 menos e solucionado da mesma forma.
Para fins de leitura, irei exibir as várias métricas no formato de tabela ao invés de exibir as métricas nativamente em colunas do Excel. Como observado anteriormente, existem dois Bancos de dados de caixa de correio do Exchange no Servidor de caixa de correio agrupado NA1-ERICNOR-1 que tinham seus Índices de conteúdo recompilados: NA1-ERICNOR-1-DB1 e NA1-ERICNOR-1-DB18
Pós-recompilação da métrica de caixa de correio:
Métricas de recompilação do Banco de dados de caixa de correio:
As várias métricas de recompilação e métricas de pré-compilação são adicionadas ao histórico do conjunto de dados para que eles possam contribuir com os históricos de média para exercícios de recompilação futuros.
Na segunda publicação da série, eu abordei as etapas da Estrutura de recompilação de pesquisa. Minha próxima publicação final abordará as médias observadas que vimos dentro de nossas implantações na Microsoft.
Eric Norberg Engenheiro de Serviço Exclusivo do Office 365
Esta é uma publicação localizada. Encontre o artigo original em Establishing Exchange Content Index Rebuild Baselines – Part 2
Artigo original publicado na segunda-feira, 02 de julho de 2012
Na Parte 1 desta série, eu expliquei o E2K7_IndexRebuildAnalyzer.ps1 script e na Parte 2, eu discuti a Estrutura de recompilação de pesquisa que Anatoly Girko e eu desenvolvemos. Antes de concluir esta série, eu desejo oferecer uma série de gráficos, assim como uma tabela de “médias observadas” que ilustra as características de recompilação observadas desde o início da estrutura. Esperamos que isto permita uma melhor conceitualização, assim como uma capacitação para estimar melhor ao calcular suas próprias taxas de recompilação..
Anatoly e eu discutimos muito sobre como apresentar isso. Como você pode imaginar, existe um número infinito de possibilidades para a apresentação. Decidimos mirar os gráficos e a tabela no tamanho da mensagem que a maioria dos Arquitetos de Armazenamentos do Exchange estão projetados: 150 KB por item de correio. Realizamos um filtro secundário na Contagem de caixa de correio e levamos em conta apenas Bancos de dados de caixa de correio dentro de nossos conjuntos de dados que tinham 100 ou mais caixas de correio ativas para compilar as médias. Ao concluir, removemos 10% do melhor desempenho e 10% do pior desempenho das operações de recompilação dentro do nosso conjunto para derivar as médias usadas para compilar os gráficos e as tabelas.
Nota: Nos vários gráficos e na tabela a seguir, Tamanhos médios da caixa de correio em vários incrementos de intervalo estão ausentes. Este dado não foi ignorado ou omitido propositalmente. A ausência de dados estatísticos destes intervalos é devida ao fato que não existe nenhum dado válido em nossos conjuntos históricos. Coloque outra forma que nunca realizamos as operações de recompilação do Índice de conteúdo realizado e/ou métricas de Pós-recompilação coletadas de bancos de dados onde os Tamanhos Médios da Caixa de correio das caixas de correio do usuário final estejam nos seguintes intervalos:
Iremos apresentar quatro Gráficos Pivô do Excel que refletem as características do resultado que observamos até o momento com base no conjunto filtrado descrito acima. Estes Gráficos Pivô são destinados a ilustrar o relacionamento que existe entre várias propriedades, conforme ocorrem dentro e ao redor do Repositório de Caixa de correio (por exemplo, contagem de caixa de correio, contagem de item e tamanhos de arquivo EDB) e contratar com o histórico dos tempos de resultado necessários para concluir o Rastreamento Completo nos Repositórios de Caixa de correio com características semelhantes.
Para exibir o conteúdo do Gráfico 1 especificamente, apesar do relacionamento entre Contagens de caixa de correio por banco de dados, o tamanho relativo dos Bancos de dados de caixa de correio em gigabytes e como isto impacta o tempo total para concluir a recompilação do Índice de conteúdo dos Repositórios de caixa de correio em minutos.
Este gráfico realiza um argumento claro de que o aumento do número total de caixas de correio ativas no Banco de dados de Caixa de correio do Exchange também terão tendência a ser um relacionamento paralelo para aumentar o tamanho do arquivo EDB no subsistema de armazenamento. Este relacionamento subsequentemente possui um impacto no tempo geral para concluir um Rastreamento completo de um índice de conteúdo. Isto é realmente apenas uma forma elegante de dizer que: com mais caixas de correio ativas, geralmente vem mais itens de correio; com mais itens de correio vem tamanhos de arquivos EDB maiores no disco; maior um tamanho de arquivo EDB no disco, mais tempo "geralmente" levará para recompilar um Índice de conteúdo. A única situação onde esta hipótese nunca será verdadeira é no caso de um Banco de dados de Caixa de correio que possui uma grande quantidade de espaço em branco presente no arquivo. Em tal caso, o tempo geral para concluir uma recompilação do Índice de Conteúdo será muito mais rápido do que o esperado. Esta situação anormal ocorreu dentro de ambientes que suportamos, mas as estatísticas foram removidas do nosso conjunto ao nivelar a técnica de filtragem discutida acima.
Gráfico 2 representa a relação existente entre o Tamanho médio de caixa de correio (para caixas de correio existentes em bancos de dados contidos dentro do mesmo conjunto de amostra filtrado) e como impacta o resultado da recompilação do Índice de Conteúdo a nível do Banco de dados de Caixa de correio em Segundos por/caixa de correio.
Este gráfico essencialmente declara o argumento apresentado no Gráfico 1 embora o nível de caixa de correio ativa. Especificamente, conforme as médias de tamanho da caixa de correio ativa aumenta, também aumenta o número de itens de email dentro destas caixas de correio. Em média, quanto mais itens de email dentro de uma caixa de correio, mais tempo levará para o Indexador de Pesquisa concluir o rastreamento em uma determinada caixa de correio, que por sua vez, impacta quanto tempo levará para concluir o Rastreamento completo de todas as caixas de correio dentro do banco de dados.
Gráfico 3 representa a relação existente entre o Tamanho médio de caixa de correio (para caixas de correio existentes em bancos de dados contidos dentro do mesmo conjunto de amostra filtrado) e como impacta o resultado da recompilação do Índice de conteúdo em Megabytes por/segundo.
Gráfico 3 compila a hipótese inicial mencionada no Gráfico 2. Especificamente, mostra que conforme o Tamanho médio da caixa de correio e a Contagem média de item dentro de um Banco de dados de caixa de correio aumenta, há uma relação negativa entre o resultado do Indexador de Pesquisa. O Gráfico 3 mostra essa relação em megabytes por segundo.
Gráfico 4 representa a relação existente entre o Tamanho médio de caixa de correio (para caixas de correio existentes em bancos de dados contidos dentro do mesmo conjunto de amostra filtrado) e como impacta o resultado da recompilação do Índice de conteúdo em Itens por segundo (com base no Tamanho médio da mensagem de 150 KB):
Como foi o caso com o Gráfico 3, o Gráfico 4 mostra o impacto de desempenho negativo em relação ao resultado em Itens por/segundo.
Para apresentar a tabela, utilizamos o mesmo conjunto filtrado (descrito acima e apresentado nos gráficos), mas decidimos criar médias focalizadas com base no Tamanho médio da caixa de correio. Estas linhas são delineadas subsequentemente como linhas independentes em aumentos de 99 megabytes. A característica do resultado de cada linha representa a média agregada para todos os bancos de dados dimensionados semelhantemente que concluíram as operações de recompilação em nosso conjunto. Especificamente, onde o Tamanho médio da mensagem era de 150 KB e o Tamanho médio da caixa de correio para todas as caixas de correio ativas nestes bancos de dados estavam dentro dos intervalos definidos pela Coluna A.
O histórico de médias apresentado nesta tabela (pelo menos para mim) produz três formas potenciais de estimar o tempo de recompilação do Índice de conteúdo:
Por exemplo, se tenho um Índice de Conteúdo que precisa ser recompilado para um banco de dados cujos usuários possuem um Tamanho médio da caixa de correio agregado no intervalo de 500-599 MB e assumindo que o Tamanho médio da mensagem é de 150 KB, se este banco de dados possuir 200 usuários, eu posso derivar a estimativa em uma das três formas:
A Tabela de Histórico de Médias:
200 caixas de correio * 63 segundos = 12.600 segundos total. Isto é igual a 210 ou 3,5 horas para concluir o Rastreamento completo.
A “Média Organizacional”:
200 caixas de correio * 108 segundos = 21.600 segundos total. Isto é igual a 360 minutos ou 6 horas para concluir o Rastreamento completo.
Média composta (Média do “Histórico” + “Organizacional”):
3,5 + 6,0 = 9,5 horas
9,5 / 2 = 4,75 horas
O tempo total que leva para recompilar um Índice de Conteúdo sempre será variável porque as populações de email e itens também são variáveis. Ao recompilar os Índices de Conteúdo, as estimativas mais precisas e robustas sempre virão do nivelamento das médias do histórico. Eu também desejo mencionar que quando eu/nós tomamos decisões para recompilar o Índice de Conteúdo internamente na MSFT, fazemos o melhor para programar para intervalos de tempo com "menor impacto no usuário". No entanto, nossas implementações são globais, portanto é mais ou menos impossível eliminar totalmente o impacto no usuário final. O melhor que podemos esperar é minimizar o impacto superficialmente. Além disso, dentro de nossos conjuntos de dados não temos um fator nos Atrasos da Aceleração do Indexador de Pesquisa. Todo e qualquer Atraso de Aceleração de Recompilação do Indexador de Pesquisa são abordadas e compreendidas dentro do momento e são representativas dentro dos tíquetes individuais conforme são apresentadas para as operações. Nivelando nossas técnicas de filtragem usadas nesta publicação, você isola seus números destas médias negativas (o mesmo é verdadeiro para operações de recompilação "com alto resultado"), tornando suas estimativas gerais consideravelmente mais precisas.
Se você é o tipo de pessoa propensa a apostar com médias, eu defendo nosso lado totalmente. Se uma ciência mais exata é necessária, eu gostaria de sugerir a implementação de uma estrutura como a descrita nesta série de publicações.
Esperamos que você ache esta série de publicações disponíveis e, ainda mais, tenha aprendido algo durante a jornada!
Felicidades!
Esta é uma publicação localizada. Encontre o artigo original em Establishing Exchange Content Index Rebuild Baselines – Part 3
Artigo original publicado na sexta-feira, 15 de junho de 2012
A Parte 2 desta série (A Parte 1 está aqui) detalha os eventos que ocorrem durante o backup de um banco de dados replicado ativo e montado em um Grupo de Disponibilidade do Banco de Dados do Exchange 2010 chamado, simplesmente, “DAG”. Neste exemplo, o servidor de backup é solicitado a criar um backup completo do banco de dados DB1 no servidor ADA-MBX1, usando instantâneos COW não persistentes:
(clique nas miniaturas para obter uma versão completa dos gráficos desta publicação)
O Evento 9606 indica que o solicitante VSS envolveu o gravador do Exchange e relata o GUID da instância para o trabalho de backup sendo iniciado. Neste caso, a instância é 830705de-32d9-4059-94ea-b9e9aad38615. Este GUID de instância persiste em cada trabalho e altera com cada subsequente. É possível usá-lo para rastrear a sequência de eventos de cada trabalho. Neste momento, o Gravador do Exchange oferece metadados sobre os bancos de dados e logs presentes no aplicativo de backup.
Os Eventos 2005 e 9811 indicam uma atribuição do número de instância para o ESE. Portanto, junto com o GUID de instância do gravador do evento 9606, também podemos rastrear um progresso de trabalho usando estes números de instância ESE que aumentam em um com cada trabalho. Nesta etapa, o banco de dados é marcado com “backup em andamento” no espaço da memória Informação do Serviço do Repositório.
Logo após o aplicativo de backup ter determinado quais discos precisam de instantâneos, com base nos locais de dados fornecidos pelo metadados do Gravador do Exchange, continua e solicita estes instantâneos. Conforme as solicitações de instantâneos chegam, o evento 9608 é gerado, indicando o reconhecimento do gravador do Exchange de que algo está para acontecer. Ele deve interromper as gravações nos bancos de dados e logs, também conhecido como "congelar" pela duração do processo de geração de instantâneos.
Quando o evento 2001 é gerado, o log de transação atual é fechado e o congelamento inicia. Gravações do STORE.exe para os discos são mantidas na memória.
Quando estes eventos aparecem, sabemos que os instantâneos foram criados e as gravações são permitidas nos blocos de dados do banco de dados novamente.
Quando estes instantâneos forem criados, o aplicativo de backup pode copiar os blocos de dados do subsistema VSS, obtendo os blocos de dados do armazenamento de sombra se eles foram preservados devido a uma alteração ou do volume de disco real caso contrário. O Gravador do Exchange aguarda pelo sinal de que a transferência de dados está concluída. Este fluxo de dados é representado pelas setas roxas, que neste caso indicam a obtenção de dados copiados dos instantâneos no armazenamento, pelo I/O do servidor do Exchange e para o servidor de backup.
Quando o aplicativo de backup finaliza a cópia dos dados, sinalizará que o VSS está concluído. Por sua vez, o VSS envia sinais para o gravador do Exchange, que inicia as etapas de pós-backup especificadas nos eventos acima. O evento 225 aparece para declarar que a truncagem de log não irá ocorrer, mas que o evento é incorreto. Para um banco de dados autônomo, após a conclusão do backup, o ESE continuará e limpará os logs da mesma forma. No entanto, quando um banco de dados replicado DAG é envolvido, uma verificação de outras cópias do banco de dados deve ser realizada em coordenação com o Serviço de Replicação do Exchange para garantir que a truncagem do log possa continuar. Quando esta verificação é concluída, os logs elegíveis para truncagem são excluídos. O cabeçalho do banco de dados é marcado com a informação sobre o backup e o backup no bit de andamento é desativado na memória. Neste caso, os instantâneos usados para o trabalho são destruídos como parte da conclusão. Em outros tipos de backup, como incremental, a persistência dos instantâneos varia, mas neste caso são removidos.
Na próxima publicação desta série iremos detalhar o backup de uma cópia de banco de dados replicado DAG passivo.
Jesse Tedoff
Esta é uma publicação localizada. Encontre o artigo original em Everything You Need to Know About Exchange Backups* - Part 2
Artigo original publicado na quarta-feira, 20 de junho de 2012
Atualização 22/6/12 - Este artigo e o download anexado foram atualizados.
A última versão da Calculadora de largura de banda de rede do cliente Exchange inclui várias atualizações, mas sem dúvida a mais significante é o suporte ao fuso horário. Eu tenho procurado sobre como lidar com o problema de fuso horário pelos últimos 12 meses e demorou um pouco para achar uma solução prática. No entanto, estou me antecipando, então vamos ver primeiro qual é o problema real com o fuso horário.
Eu irei assumir que todos saibam o que é fuso horário e porque temos eles. No entanto, para aqueles que desejam saber mais, recomendo ler o artigo abaixo no Wikipédia;
http://en.wikipedia.org/wiki/Time_zone
O problema real com fuso horários de uma perspectiva de previsão de largura de banda de rede é que podemos estar tentando modelar cargas de trabalho de usuários em diferentes partes do mundo que compartilham a mesma conexão de rede ou o mesmo serviço final. Isto nos causa um problema porque os tempos de pico de uso da maioria dos usuários está relacionado ao seu fuso horário local;
Por exemplo, se vermos um dia comercial normal para uma organização média de 1.000 usuários, vemos dois picos típicos, um na manhã por volta das 10 horas que dura por 2 horas e um pela tarde por volta das 14 horas que dura por 4 horas. Quando imprimimos isso, se parecerá com;
Agora, vamos imaginar que estamos modelando os requisitos para 5 locais diferentes no mundo, cada um suportando 1.000 usuários acessando um recurso compartilhado em Nova Iorque. Neste ponto, vamos assumir que o recurso compartilhado é um balanceador de carga do Exchange 2010 local (eu acho que escolheria um exemplo local para variar)
Se modelarmos usando nossa técnica herdada de prever o pico de cada conjunto de usuários e agrupá-los, obtemos o seguinte;
O que este gráfico está mostrando é que cada local de 1.000 usuários exige cerca de 1,56Mbits/seg de largura de banda no pico cada dia e, portanto, quando adicionamos todos em uma conta para todos os usuários compartilhando o balanceador de carga em Nova Iorque, obtemos um requisito de pico de 7,81Mbits/seg. Isto é como lidamos com o planejamento de largura de banda para usuários distribuídos, prevendo seus requisitos de pico e permanecendo com eles em uma tabela e agrupando-os.
O problema aqui é que os usuários na Europa irão para casa quando os usuários em Redmond estão acordando e os usuários em Jacarta irão dormir!
Se levamos os fusos horários destes locais em consideração, o gráfico muda muito;
Este gráfico mostra como as cargas de trabalho realmente combinariam para formar um perfil de uso muito diferente do que teríamos planejado. O que é realmente interessante é que nossa carga de trabalho de pico é muito menor a apenas 3,78Mbits/seg (nossa previsão original era de 7,81Mbits/seg). O perfil de uso também é muito diferente da nossa previsão original.
Bem, como você pode ter adivinhado nos gráficos acima, aumentamos a calculadora de rede para permitir incluir detalhes de fuso horário!
O que realmente fizemos para obter isso foi abandonar a ideia de prever apenas a carga de trabalho de pico e prevemos agora o uso por hora do dia com base nos padrões de uso fornecidos quando é o horário de pico matinal, o horário de pico da tarde, etc. Isto permite que a calculadora saiba não apenas quando seu pico de uso será, mas também qual será o uso no resto do dia. Quando conhecemos esta curva, é possível agrupar dados em uma conta para fuso horários.
Bem, a resposta simples é sim – várias organizações estão consolidando cargas de trabalho o máximo possível. Isto exige que as equipes de criação planejem cargas de trabalho de serviço de usuários muito distribuídos; frequentemente com perfis diferentes em fuso horários diferentes. Isto é especialmente comum quando a carga de trabalho é movida para a nuvem desde que o Office 365 ofereça apenas locais de inquilino regional único e para uma organização global usando o Office 365 terá que planejar uma grande proporção de seus usuários acessando o serviço em uma região/país e fuso horário totalmente diferente, frequentemente por uma infraestrutura compartilhada.
Vários clientes com quem trabalho também estão consolidando vários pequenos centros de dados em menos centros de dados maiores – estes locais consolidados podem lidar com a carga de trabalho dos usuários distribuídos anteriormente, frequentemente estes usuários estarão em fuso horários diferentes e portanto, quando tentamos acomodar sua carga de trabalho, precisamos de uma forma de descobrir como eles irão se combinar com outras cargas de trabalho distribuídas.
Obviamente, se todos os seus usuários estão no mesmo fuso horário, você não precisa se preocupar com tudo isso e apenas use a calculadora normalmente.
Ok, você tem o cenário que exige suporte de fuso horário. Como eu uso ele?
Primeiro, precisamos configurar a tabela de configuração TimeZone na folha de entrada. Os parâmetros inseridos aqui controlam a forma que a curva de uso é usada para combinar as cargas de trabalho. Os valores precisam refletir os padrões de uso médios dentro da sua organização. Eu geralmente olho para os dados de desempenho executando em servidores do Exchange para criar isso, combinado com perguntar ao cliente como eles acham que seus usuários trabalham e quais são seus horários de pico.
Quando a folha de entrada estiver concluída, movemos para a folha Mix do Cliente – onde temos duas novas áreas para configurar os dados de fuso horário.
Primeiro é o Modelo de Fuso Horário, que apresenta o fuso horário do recurso que estamos planejando, isto é, o link de rede ou balanceador de carga. No exemplo anterior, é possível ver que eu definir a zona de fuso horário para GMT-5 para Nova Iorque, que é onde está nosso balanceador de carga.
A seguir, temos uma nova coluna chamada TimeZone – isto representa o fuso horário de cada local em relação ao GMT (observe que eu sou inglês e coloquei GMT, mas podemos usar UTC no futuro se houverem muitas reclamações).
A previsão resultante é exibida em um gráfico abaixo da tabela mix do cliente mostrada anteriormente. Os valores nesta tabela são Mbits/seg e representa a previsão de uso de rede em cada hora do dia.
Um outro bom recurso é que a calculadora oferecerá uma tabela que pode ser copiada na Calculadora de Função da Caixa de Correio para ajudar com a previsão de replicação da rede DAG.
Se você olhar à direita da tabela de previsão (Folha de Mix do Cliente) na Calculadora de Rede, verá uma tabela que contém uma % de alterações por hora do dia... se copiar isto para sua área de transferência...
Role para a parte inferior da folha de Entrada na Calculadora de Função do Servidor de Caixa de Correio, você encontrará uma tabela para a Configuração de Replicação de Log. Cole os números da Calculadora de Rede nesta tabela.
Pronto, a Calculadora de Função do Servidor de Caixa de Correio poderá prever os requisitos de largura de banda para replicação DAG levando em consideração os dados da sua organização e a configuração de fuso horário!
Esperamos que este novo recurso ajude vários de vocês a prever com precisão seus requisitos de largura de banda de rede; não é necessário para todas as implantações, mas para aqueles arquitetos de grandes empresas que estão tendo dificuldades com este problema. Espero que o recurso de fuso horário ajude.
Continue a fornecer seus valiosos comentários - positivos e negativos para o endereço netcalc@microsoft.com. Adoramos ler seus comentários!
Neil Johnson Consultor Sênior, MCS RU
Esta é uma publicação localizada. Encontre o artigo original em Exchange Client Bandwidth Prediction – the time zone problem…
Artigo original publicado na quinta-feira, 28 de junho de 2012
Atualização 03/07/2012: Seção solução alternativa expandida para incluir mais detalhes.
Desejamos chamar a atenção para um problema que temos visto recentemente no CSS, onde várias caixas de correio no mesmo banco de dados de caixa de correio ficam em quarentena por nenhuma razão. Após a inspeção do log de aplicativos, você verá vários eventos 10018 com o texto contendo a seguinte informação.
Nome do Log: Aplicativo Origem: MSExchangeIS ID de evento: 10018 Categoria de tarefa: Geral Nível: Erro Descrição: A caixa de correio para o usuário <guid>: /o=Contoso /ou=Grupo Administrativo do Exchange (FYDIBOHF23SPDLT)/cn=Destinatários/cn=UserMailbox foi colocada em quarentena. O acesso a esta caixa de correio será restrita para os logins administrativos nas próximas 6 horas.
Além disso, a seguinte ID de evento 5410 aparecerá no log de eventos Microsoft-Exchange-Troubleshooters/Operational para cada caixa de correio em quarentena pela resolução de problemas de espaço do banco de dados:
Nome do Log: Microsoft-Exchange-Troubleshooters/Operational Origem: Espaço do banco de dados ID de evento: 5410 Nível: Aviso Palavra-chave: Clássico Descrição: A resolução de problemas do espaço do banco de dados colocou a caixa de correio em quarentena <guid> no banco de dados <DBName>.
A chave aqui é a última frase. “A resolução de problema de espaço do banco de dados”. Em ambientes onde o System Center Operations Manager foi implantado, um Monitor está no local por padrão para verificar o espaço livre em disco para o banco de dados e volumes de log. Este monitor usa o script do PowerShell Troubleshoot-DatabaseSpace.ps1, que é enviado com o Exchange 2010 por padrão. Para ler mais sobre o script Troubleshoot-DatabaseSpace.ps1, consulte o seguinte artigo TechNet:
Gerenciar o crescimento do log de banco de dados usando o script Troubleshoot-DatabaseSpace.ps1 no shell http://technet.microsoft.com/en-us/library/ff477617.aspx
A equipe do System Center lançou recentemente o Service Pack 2 para o Pacote de Gerenciamento do Exchange. Entre outras coisas, isto ajustou um valor de tempo de inatividade para executar o script. Antes do Pacote de Serviço, o valor de tempo limite era de 300 segundos e o monitor foi definido para disparar a cada 5 minutos. Isto significa que em várias organizações grandes, o script foi garantido virtualmente para tempo limite, casando a não conclusão. Após instalar a atualização, o novo valor de tempo limite é de 1.200 segundos. Além disso, o monitor executa uma vez por hora ao invés de a cada 5 minutos. Os efeitos desta alteração são que a solução de problemas é agora confiável executando o código que anteriormente não executou antes da atualização SP2. Isto fez com que a solução de problemas encontre um bug no contador perfmon de Repositório de Informações usado pela solução de problemas determinar a taxa de geração de byte de log para o banco de dados ou volume de log (a taxa de realização pode exceder 1.0E+19 Bytes/Hr). Quando a taxa por hora estimada da geração de log excede a capacidade do espaço livre em disco restante no banco de dados ou volume de log, a solução de problemas começa a colocar as caixas de correio em quarentena para parar a geração de log consumindo todo o espaço livre e fazendo com que o banco de dados seja desmontado. A solução de problemas parece tocar esta condição quando o contador perfmon possui um valor bogus (o contador perfmon é atualizado uma vez por minuto e não deve ter um valor bogus por mias de 1 min)… Portanto, não ocorre frequentemente, mas ocorre com probabilidade moderada.
Bem, conforme documentado no artigo TechNet, a função principal do script é manter um registro da taxa de geração de log e verificar o espaço livre em disco para o banco de dados e volumes de log. Quando o script é executado, usa um contador perfmon do repositório para determinar a taxa de geração de log e calcula se a taxa atual fará com que o disco fique sem espaço dentro do limite de horas (o padrão é 12 horas), e, caso sim, iniciará opcionalmente as caixas de correio em quarentena (até 150 por vez). O script irá também opcionalmente colocar caixas de correio em quarentena quando a porcentagem de espaço livre em disco vai abaixo de um valor especificado. O valor de porcentagem de espaço livre em disco padrão usado é 25%. Para poder colocar caixas de correio em quarentena quando estas condições são cumpridas, o parâmetro –Quarantine deve ser passado para o script.
O monitor utilizado pelo SCOM 2007 e superior usa o parâmetro Quarantine por padrão e não há opção suportada para alterar isto porque o Pacote de Gerenciamento é vedado. Isto significa que se o espaço livre de disco para o banco de dados ou volume de log para um banco de dados vai abaixo dos 25%, E se a taxa de geração de log é calculada para consumir o espaço restante em disco dentro das próximas 12 horas, os usuários mais pesados serão colocados em quarentena. Quando há várias caixas de correio em um banco de dados, isto significa que várias caixas de correio podem ser colocadas em quarentena em um curto período de tempo.
Obviamente, ter várias caixas de correio colocadas em quarentena não é um comportamento desejado, pois causa interrupções para estes usuários, embora ainda é melhor do que a alternativa de desmontar todo o banco de dados devido a falta de espaço em disco, que causará uma interrupção para todos os usuários neste banco de dados. Embora as caixas de correio em quarentena possam ser liberadas manualmente removendo o GUID da caixa de correio do Registro, esta não é a melhor solução, pois a próxima vez que o monitor for executado, as mesmas caixas de correio podem acabar sendo colocadas em quarentena novamente.
As caixas de correio em quarentena são identificadas no seguinte local:
Hkey_Local_Machine\SYSTEM\CurrentControlSet\Services\MSexchangeIS\Servername\Private-<D Bguid>\Quarantined Mailboxes\ {Mailbox GUID}
Queremos que saiba que estamos cientes desta situação e estamos trabalhando para implementar uma correção. Enquanto trabalhamos para identificar a melhor forma de resolver isso avançando, desejamos deixar você saber uma solução alternativa que pode ser implementada para evitar que as caixas de correio sejam colocadas em quarentena. Enquanto isso, para ajudar prevenir mais clientes de executar neste problema, removemos temporariamente o Pacote de Gerenciamento do Exchange 2010 SP2 do Centro de Download.
Criar uma substituição para desabilitar os monitores que verificam o espaço livre em disco. Isto evitará que o arquivo Troubleshoot-DatabaseSpace.ps1 seja executado.
Ao criar substituições, é recomendado colocá-las em um novo pacote de gerenciamento especificamente para personalizações dentro do System Center Operations Manager. Isto permite gerenciar de forma rápida e fácil suas substituições ou outras configurações personalizadas. Se você ainda não tiver um pacote de gerenciamento para isso, é possível criar um seguindo as etapas abaixo:
Ao designar um pacote de gerenciamento para substituição, você desejará criar para os 4 monitores listados aqui:
No System Center Operations Manager, vá para o módulo Autoria e em Monitores em Objetos do Pacote de Gerenciamento. Os monitores podem ser desabilitados configurando uma Substituição e escolhendo desabilitar o Monitor para todos os objetos da classe Copiar espaço de disco lógico do banco de dados DB (como mostrado abaixo):
Marque a caixa próximo a Habilitado e modifique o valor de substituição selecionando Falso:
Na caixa de diálogo Propriedades de substituição, certifique-se de selecionar o pacote de gerenciamento designado para personalizações.
Neste momento, sentimos que você está sendo impactado pelas caixas de correio em quarentena, a opção para desabilitar os Monitores está apenas disponível como solução alternativa. Reconhecemos que isto potencialmente evitará que os administradores recebam alertas quando o espaço de disco estiver baixo, mas sentimos que é a melhor opção para evitar que as caixas de correio sejam colocadas em quarentena até que uma correção seja lançada.
Observe que quando o espaço de disco do Banco de dados está baixo, um alerta ainda será recebido quando a unidade do log de transação coexiste com o banco de dados, pois é gerado por uma regra diferente do que apenas baseada em perfmon.
Ben Winzenz, Kevin Carker
Esta é uma publicação localizada. Encontre o artigo original em Mailboxes on a database are Quarantined in an environment with System Center Operations Manager
Como a publicação original sobre o lançamento OCAT era muito popular, desejamos avisar que acabamos de lançar a versão 2.0 da ferramenta, com vários recursos que você pediu!
Se você tem o OCAT v1 instalado, a instalação do OCAT v2 irá remover automaticamente o v1 para você.
Aqui estão os principais recursos adicionados no OCAT versão 2:
Conforme criamos novas regras para detectar problemas ou coletar informações adicionais sobre seu perfil do Outlook, publicaremos um arquivo de regras atualizados para a Internet. Com a configuração padrão do OCAT versão 2, o OCAT irá verificar automaticamente por um novo arquivo de regra e solicitar a atualização do OCAT se um novo arquivo é encontrado.
Conforme atualizamos e corrigimos o aplicativo principal OCAT, publicaremos um novo arquivo do pacote do Windows Installer (.Msi) para a Internet. Com a configuração padrão do OCAT versão 2, o OCAT irá verificar automaticamente por um novo arquivo de instalação e solicitará a atualização do OCAT se um novo arquivo é encontrado.
A Ferramenta de Verificação de Calendário (CalCheck) para o Outlook é um programa de linha de comando que verifica os Calendários do Outlook por problemas. Esta ferramenta é agora incluída no OCAT para procurar e relatar qualquer problema conhecido com itens no seu Calendário principal.
Para melhorar ainda mais a lista de problemas conhecidos detectados pelo OCAT, aproximadamente 75 novas regras foram adicionadas ao OCAT versão 2.
O OCAT v1 suportado para Outlook 2003 usando verificações offline. No entanto, a maioria das pessoas não percebem por causa do erro exibido ao tentar executar uma verificação online.
O OCAT versão 2 inclui uma versão de linha de comando do OCAT (OCATcmd.exe) que os administradores podem usar para verificar computadores em suas organizações. Consulte o arquivo OCAT v2 Supplemental Information Download.docx para obter detalhes sobre como usar a versão de linha de comando do OCAT.
O último item também é o que nos permitiu incluir o OCAT v2 no diagnóstico de linha de base do Outlook.
Se você deseja enviar seus comentários ou sugestões de melhorias para o OCAT, clique no link comentários na seção Ver também no painel esquerdo do OCAT. O link abre uma nova mensagem de email endereçada para o OCATsupp.
Greg Mansius
Esta é uma publicação localizada. Encontre o artigo original em Microsoft Outlook Configuration Analyzer Tool (OCAT) v2 released
Artigo original publicado na terça-feira, 19 de junho de 2012
Fizemos várias melhorias e correções de bug com base nos comentários da comunidade.
Vá para nossa página de rastreamento de atualizações da Calculadora de Requisitos da Função do Servidor de Caixa de Correio para ver esta nova versão!
Uma publicação explicando a calculadora está aqui e/ou você pode baixar a calculadora diretamente.
Comentários são bem-vindos!
Ross Smith IV Gerente de Programa PrincipalExperiência do Cliente do Exchange
Esta é uma publicação localizada. Encontre o artigo original em Released: v19.9 of the Exchange 2010 Mailbox Server Role Requirements Calculator
Artigo original publicado na quarta-feira, 04 de julho de 2012
Estamos felizes de anunciar as melhorias à experiência CAPTCHA do Analisador de Conectividade Remota. Vários de vocês nos disseram quão frustrante era a experiência anterior. Concordamos… é muito aborrecedor ter os campos de senha em branco se você errou o desafio. Enquanto não podemos remover este "recurso" totalmente, esperamos que as melhorias façam uma grande diferença.
A versão mais atual (V1.4) do Analisador de Conectividade Remota possui as seguintes melhorias:
(Já podemos ouvir os aplausos!!)
Alguns mais:
Aqui está um vídeo divertido de 1 minuto que demonstra algumas dessas melhorias.
Aproveite!
Brad, Nicole e Shawn
Esta é uma publicação localizada. Encontre o artigo original em Remote Connectivity Analyzer gets an updated CAPTCHA experience