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:

• Você está usando o novo serviço de CAPTCHA fornecido por uma equipe interna!
  • O desafio NÃO diferencia maiúsculas e minúsculas. Portanto, não importa se você digite as letras maiúsculas e minúsculas.  Também observamos isso na página da Web.
  • Os desafios CAPTCHA não incluirão a distinção de letras/números difíceis.  Por exemplo, 2 e Z ou O e 0.
  • Se você errar o desafio, a senha inserida não será removida.
  • Ao inserir uma resposta correta ao desafio, você será verificado por uma quantidade de tempo definida.  Isto significa que você não verá desafios CAPTCHA adicionais até o período limite expirar.

(Já podemos ouvir os aplausos!!)

Alguns mais:

• O teste SMTP de entrada agora insere o endereço IP do usuário realizando o teste na mensagem de email de teste. O IP também é inserido em um Cabeçalho SMTP (X-Originating-IP).
• Corrigido um problema no teste do ID do Remetente onde determinadas respostas DNS continuam a avaliar respostas enquanto o mecanismo "existir" foi tratado incorretamente como um TempError
• Os testes do ID do Remetente SMTP de saída agora está em conformidade com o limite especificado RFC de dez mecanismos baseados em DNS que podem ser usados durante a avaliação do registro SPF.
• E mais! Leia sobre isso aqui.

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

Artigo original publicado na quarta-feira, 27 de junho de 2012

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:

• Download automático de novas regras de detecção

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.

• Download automático dos arquivos de instalação do OCAT

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.

• Adição da ferramenta CalCheck

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.

• Adição de novas regras de detecção

Para melhorar ainda mais a lista de problemas conhecidos detectados pelo OCAT, aproximadamente 75 novas regras foram adicionadas ao OCAT versão 2.

• Melhor suporte para o Outlook 2003

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.

• Versão de linhas de comando do OCATcmd.exe

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 Principal
Experiê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, 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.

Qual é o problema com 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)

• Londres (GMT) = 1.000 usuários
• Warsaw (GMT+1) = 1.000 usuários
• Jacarta (GMT+7) = 1.000 usuários
• Redmond (GMT-8) = 1.000 usuários
• Nova Iorque (GMT-5) = 1.000 usuários

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.

Como podemos lidar com este problema?

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.

Alguém realmente faz uma única consolidação?

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.

Usando o novo recurso de fuso horário

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 bônus

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!

Conclusão

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.

O que isto significa para você?

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.

O que posso fazer?

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.

Solução alternativa

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:

1. No Console de Operações, clique no botão Administração. No painel Administração, clique com o botão direito em Pacotes de Gerenciamento e clique em Criar o Pacote de Gerenciamento. O assistente Criar um Pacote de Gerenciamentoé exibido.
2. Na página Propriedades gerais, digite um nome para o pacote de gerenciamento no Nome, o número de versão correta na Versão e uma descrição curta em Descrição. Clique em Avançar e em Criar.

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