Central Exchange

Entenda porque os clientes Outlook recebem a mensagem "O Outlook está tentando recuperar dados do Microsoft Exchange Server...”.

2006-07-17T22:07:00Z

O que significa a mensagem "O Outlook está tentando recuperar dados do Microsoft Exchange Server...”, conhecida também como Popup de RPC do Outlook?

As requisições do cliente Outlook para o servidor Exchange são chamadas do tipo RPC (‘Remote Procedure Call’). Sempre que o usuário quer ler uma mensagem, acessar o calendário ou qualquer outra atividade no Outlook, chamadas RPC são enviadas ao servidor Exchange ou a um servidor do tipo Global Catalag (por exemplo, se a chamada em questão for uma busca na Lista Global de Endereços).

As chamadas RPC devem ser respondidas por padrão em no máximo 5 segundos – após uma requisição, se o cliente não receber nenhuma resposta dentro dos 5 segundos, a mensagem "O Outlook está tentando recuperar dados do Microsoft Exchange Server...” será mostrada.

Nas versões anteriores ao Outlook XP, o cliente apresentava apenas uma parada momentânea, o aplicativo aparentava estar ‘travado’. Para melhorar a experiência do usuário, a Microsoft criou a mensagem de RPC “O Outlook está tentando recuperar...”, que tem como função informar ao usuário que o Outlook está levando um tempo excessivo para receber respostas do servidor Exchange (ou Global Catalog).

Na grande maioria dos casos, o tempo excessivo está ligado a problemas de performance no servidor Exchange. Podemos também listar outras causas, tais como:

- problemas de performance no Active Directory.

- problemas de rede.

- problemas causados por add-ins no cliente Outlook.

- Caixa postal com um grande número de sub-pastas e mensagens.

Se você está tentando resolver este comportamento no seu ambiente, o primeiro passo é identificar quem são os clientes afetados. Por exemplo, se a grande maioria ou todos os usuários recebem os popups com freqüência e o nome do servidor informado no popup é o nome do servidor que contém a caixa postal, então possivelmente o problema está localizado no servidor Exchange. Ou se os usuários afetados é apenas um conjunto de clientes separados do servidor Exchange por um link WAN de baixa velocidade, então possivelmente o problema está relacionado ao link (ou conectividade física.).

O popup pode informar um servidor de caixa postal, um servidor de ‘Public Folder’ ou um ‘Global Catalog’.

Tente primeiro determinar qual é o padrão para o acontecimento do problema e o que difere os clientes afetados dos demais (tipo de conectividade, existência de add-ins, tamanho da caixa postal, servidor informado, etc.)

Na minha experiência com suporte na Microsoft, a grande maioria dos casos estão diretamente relacionados com a má performance dos discos no servidor Exchange.

Para determinar se existem problemas de performance no servidor Exchange, você pode utilizar o Performance Monitor para monitorar o servidor, com os seguintes contadores:

Physical Disk (All Instances)
- Avg Disk Sec/Read
- Avg Disk Sec/Write
- Current Disk Queue Length

MSExchangeIS
- RPC Averaged Latency
- RPC Requests
- RPC Operations/Sec

Processor
- %Processor Time

Database (Information Store Instance)
- Log Record Stalls / sec

O contador ‘RPC Averaged Latency’ mostra o tempo em média que o servidor Exchange demora para responder os clientes Outlook. O valor deste contador deve estar abaixo de 20 ms sempre. Quando este contador está acima de 20 ms constantemente, isso significa que o ‘Information Store’ está demorando muito para processar requisições de usuários. Em 95% dos casos, se o ‘Information Store’ leva muito tempo para atender um cliente, o problema é um gargalo no subsistema de discos.

Os valores recomendados para ‘Avg. Disk Sec/Read’ e ‘Avg.Disk Sec/Write’ para os discos físicos são:

Boa performance < 20 ms

Performance regular < 30 ms

Má performance < 40 ms

Se o servidor possui ‘cache’ nas controladoras de discos os valores esperados são:

Cache/Excelente performance < 1 ms

Cache/Ótima performance < 2 ms

Cache/Boa performance < 4 ms

A Microsoft recomenda que a latência máxima para os discos onde os bancos de dados do Exchange estão localizados esteja sempre abaixo de 20 ms. Se o servidor atinge 20 ms ou mais constantemente, problemas como enfileiramento de mensagens na fila de ‘Local Delivery’ ou os Popups no cliente Outlook já começam a ficar evidentes.

É comum recebermos logs de performance para análise onde os discos apresentam latência de até 0.5 segundos ou mais. Imagine o quanto isso significa para um servidor Exchange (ou para qualquer outro servidor J) – 0.5 segundos para completar uma requisição de IO é um tempo infinitamente grande.

No dia a dia, é comum encontrarmos clientes com problemas de design de disco variados, como a colocação de logs de transação, banco de dados e filas SMTP no mesmo disco físico, arrays de disco sem o dimensionamento correto, ou mistura de dados como um banco de dados SQL com os bancos de dados do Exchange.

Se você determinou através do Performance Monitor que o discos do servidor Exchange estão apresentando gargalos de performance, os artigos abaixo podem ajudá-lo a corrigir o problema. Estes artigos são guias para o correto design dos discos no Exchange Server:

Optimizing Storage for Exchange Server 2003

http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/optimizestorage.mspx

Performance and Scalability Guide for Exchange Server 2003

http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/perfscalguide.mspx

Se você suspeita que a causa raiz está relacionada a conectividade, você pode utilizar a ferramenta ‘Network Monitor’ durante a reprodução do problema. Pelo ‘Network Monitor’ é possível verificar se existem retransmissões excessivas ou perda de pacotes, o que leva ao aparecimento do popup.

Se o problema é restrito para alguns usuários, e problemas de performance no ambiente ou problemas de rede já foram eliminados como causa raiz, você então deve verificar como está a caixa postal do usuário. Um número excessivo de itens (mensagens) ou sub-folders pode gerar este tipo de comportamento.

Mais informações:

905803 Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server

http://support.microsoft.com/default.aspx?scid=kb;EN-US;905803

Para saber mais sobre este assunto:

839862 How to troubleshoot the RPC Cancel Request dialog box in Outlook 2003 or in Outlook 2002

http://support.microsoft.com/default.aspx?scid=kb;EN-US;839862

Viviane Lopes

Conheça o Exchange Server 2007 – recursos disponíveis

2006-07-17T22:05:00Z

Learning Portal

O portal do Microsoft Learning Exchange Server 2007 encontra-se disponível no seguinte link:

www.microsoft.com/learning/exchange2007/default.mspx

Você já pode participar de dois treinamentos que estão disponíveis online (e gratuitos!):

Clinic 3053: What's New in Microsoft Exchange Server 2007 Administration

Este mini treinamento introduz a instalação baseada em funções de servidor do Exchange Server 2007 e também descreve cada uma das funções que estarão disponíveis na versão final do produto. O treinamento também cobre o básico da administração do Exchange Server 2007 através das ferramentas Exchange System Manager e Exchange Management Shell, além da introdução de conceitos chaves relacionados ao Unified Messaging.

Clinic 3054: Overview of Microsoft Exchange Server 2007 Architecture

Este mini treinamento descreve as mudanças mais significativas que foram realizadas na arquitetura do Exchange Server 2007, incluindo a forma como as cinco funções de servidores comunicam entre si e as mudanças no armazenamento de mensagens. Você também poderá conhecer cenários diferentes para instalação do produto.

Exchange Server 2007 versão Beta 2

Se você está interessado em conhecer o Beta 2 do Exchange Server 2007, você pode inscrever-se através do link abaixo para ser notificado quando o mesmo estiver pronto para distribuição:

http://www.microsoft.com/technet/prodtechnol/beta/exchange/default.mspx

Você também pode assistir um vídeo sobre o Beta 2 e as funcionalidades de mobilidade que estarão disponíveis no Exchange Server 2007. O vídeo é apresentado por Terry Myerson, General Manager do gupo de Exchange.

http://virtualteched.com/archive/2006/06/13/93.aspx

Demos do Exchange Server 2007 versão Beta 2

Você pode conferir os demos que se encontram disponíveis no seguinte link:

http://www.microsoft.com/exchange/preview/evaluation/demos.mspx

Alguns exemplos dos demos que você pode assistir:

ü Data Protection with Local Continuous Replication

ü Enabling Compliance with Ethical Walls

ü Enabling Compliance with Journaling

ü Enabling Compliance with Message Classification

ü Antivirus Protection with Attachment Filtering

Viviane Lopes

Estrutura de Anti-Spam no Exchange Server 2003 Service Pack 2 – Parte III

2006-07-17T21:55:00Z

Neste artigo, vamos conhecer o último nível de proteção anti-spam do Exchange 2003 Service Pack 2.

Filtro de Conteúdo

Depois que a mensagem passa pelo filtros de conexão e de protocolo, a próxima camada de defesa é o filtro de conteúdo, onde o conteúdo da mensagem será analisado.

1. Exchange Intelligent Message Filter

O Intelligent Message Filter, mais conhecido como IMF, é um filtro de conteúdo desenvolvido especialmente para o Exchange. O IMF é baseado em uma tecnologia patenteada pela Microsoft chamada Microsoft SmartScreen®. O SmartScreen é utilizado também pelo MSN, Hotmail e pelo Outlook 2003.

Diferente de outras tecnologias, o IMF utiliza uma amostragem estatística contendo exemplos de mensagens de SPAM para determinar se a mensagem é SPAM ou não. Adicionalmente, mensagens legitimas são incluídas nesta amostragem, reduzindo a possibilidade de erros. Como o IMF reconhece as características dos dois tipos de mensagens, legitima e SPAM, a precisão do IMF é aumentada.

O IMF deve ser instalado em servidores Exchange que aceitam mensagens da Internet. Quando um usuário externo envia uma mensagem para um Exchange com IMF habilitado, o conteúdo desta mensagem é analisado e uma pontuação é estampada no cabeçalho da mensagem indicando a probabilidade da mensagem ser SPAM.

A pontuação varia de 1 a 9. Esta informação fica armazenada em uma propriedade de mensagem chamada ‘SPAM Confidence Level’ (SCL). Esta propriedade é mantida na mensagem mesmo quando ela passa outros servidores Exchange dentro da organização.

Depois que o IMF estampa o SCL na mensagem, a mesma será avaliada por duas configurações definidas pelo administrador, conforme explicado à seguir:

Gateway blocking configuration: Block messages with an SCL rating greater than or equal to:

Se o SCL da mensagem for igual ou maior que o valor configurado aqui, uma das seguintes ações será tomada contra a mensagem:

Archive (arquivar a mensagem)
Delete (apagar a mensagem)
No action (nenhuma ação será tomada)
Reject (recusar a mensagem)

Store junk e-mail configuration: Move messages with an SCL rating greater than.

Se o SCL da mensagem for maior que o valor configurado aqui, a mensagem será entregue ao usuário, porém a mesma será colocada na pasta “Lixo Eletrônico” (a menos que o usuário tenha adicionado este remetente na lista de “remetentes seguros” do Outlook).

1.1 IMF Custom Weighting

O IMF possui uma funcionalidade denominada “Custom Weighting”, que permite aos administradores customizar o comportamento do IMF, baseado em frases encontradas no corpo da mensagem, no assunto ou em ambos.

Para implementar esta funcionalidade, é preciso criar um arquivo chamado MSExchange.UceContentFilter.xml e salvá-lo dentro do mesmo diretório onde os arquivos MSExchange.UceContentFilter.dll e .DAT se encontram. Tipicamente estes arquivos estarão no diretório “C:\Program Files\Exchsrvr\bin\MSCFV2”.

O arquivo MSExchange.UceContentFilter.xml define frases as quais o IMF dará maior ou menor ênfase. Isso permite a customização do funcionamento do IMF de forma a permitir ou negar mensagens baseado em frases, que de outra forma, receberiam um SCL diferente pelo IMF.

O IMF carrega o arquivo .XML durante a sua inicialização, e entende mudanças realizadas no arquivo sem que seja necessário reinicializar o serviço de SMTP no Exchange.

Exemplo de um MSExchange.UceContentFilter.xml:

<?xml version="1.0" encoding="UTF-16"?>

</CustomWeightEntries>

Durante o processamento da mensagem, o IMF lê o arquivo XML e então busca dentro da mensagem por uma string/palavra/frase que esteja listado na customização. Se algo for encontrado, o SCL da mensagem será ajustado de acordo com o “modificador” especificado.

Por exemplo, se a mensagem receber um SCL inicial de 4, e possuir a frase “Compre agora, o SCL será ajustado em mais 1 ponto. O valor final será SCL = 5.

Se você especificar MAX ou MIN no modificador para uma frase ou palavra específica, quando a mesma for encontrada em uma mensagem, o IMF irá mover o SCL para o valor máximo (9), ou mínimo (0).

Especificação dos campos do arquivo MSExchange.UceContentFilter.xml:

Type= BODY – busca da frase ou palavra no corpo da mensagem

Type= SUBJECT - Busca da frase ou palavra no assunto da mensagem

Type= BOTH – busca da frase ou palavra no corpo e assunto da mensagem

CHANGE – modificador que indica o ajuste a ser realizado no SCL da mensagem. Se você utilizar MAX, o SCL será ajustado para o valor máximo 9. Se você utilizar MIN, o SCL será ajustado para 0. Valores negativos decrementam o SCL, e valores positivos incrementam o SCL.

Na Microsoft, 38% da mensagens que passam o filtro de conexão e o filtro de protocolo são bloqueadas pelo IMF.

2. Lixo Eletrônico no Outlook 2003 e Outlook Web Access

Depois que a mensagem passar a linha de defesa baseada no servidor, o cliente Outlook 2003 pode atuar nas mensagens com o SCL maior ou igual a configuração especificada para armazenar lixo eletrônico no IMF. As mensagens que excederem a configuração especificada no servidor serão enviadas a pasta Lixo Eletrônico do cliente.

O Outlook 2003 e OWA permite ao usuário criar uma lista de remetentes seguros – esta lista contem endereços de e-mail de usuários os quais o clientes sempre irá aceitar mensagens. Também é possível criar uma lista de usuários bloqueados, ou seja, remetentes os quais o usuário não deseja receber mensagens.

Independente do SCL da mensagem, o Exchange sempre irá respeitar as listas criadas por usuários. Mensagens de usuários pertencentes a lista bloqueada serão sempre entregues a pasta lixo eletrônico, e mensagens de usuários permitidos serão sempre entregues na Caixa de Entrada.

Versões anteriores do Outlook não suportam as listas de usuários bloqueados ou permitidos. Qualquer mensagem estampada como SPAM é entregue diretamente na caixa postal do usuário, no folder Caixa de Entrada. Neste caso, o usuário pode definir as listas pelo Outlook Web Access.

Se você quiser conhecer mais sobre o IMF:

Microsoft Exchange Server Intelligent Message Filter v2 Operations Guide:

http://www.microsoft.com/downloads/details.aspx?familyid=B1218D8C-E8B3-48FB-9208-6F75707870C2&displaylang=en

Spam Confidence Level:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/ast_spam_confidence_level.asp

Fonte utilizada: http://www.microsoft.com/exchange/evaluation/features/antispam_framework.mspx

Viviane Lopes

Estrutura de Anti-Spam no Exchange Server 2003 Service Pack 2 – Parte II

2006-07-07T22:17:00Z

Neste artigo, vamos conhecer um pouco mais sobre o filtro de protocolo do Exchange 2003 Service Pack 2.

Filtro de Protocolo

Depois que a mensagem passa pelo filtro de conexão, a próxima camada de defesa é o filtro de protocolo SMTP. A conversa SMTP entre os servidores é analisada para verificar se o remetente e destinatário são permitidos, e para determinar o domínio SMTP do servidor remetente.

O filtro de protocolo pode ser configurado de duas formas:

1.1 Bloqueio do destinatário e remetente

Uma das formas de reduzir o número de mensagens de spam é definir remetentes ou domínios individuais dos quais você deseja recusar mensagens. O bloqueio de remetente permite que você especifique um endereço de e-mail individual ou domínios inteiros. Adicionalmente você pode configurar o filtro para recusar mensagens com remetente em branco.

O filtro de destinatário permite que você bloqueie mensagens enviadas para um destinatário em particular, ou que você filtre mensagens para usuários que não estão listados no Active Directory.

Uma ressalva ao filtrar mensagens para usuários que não estejam listados no Active Directory é que a sua organização pode se tornar vulnerável a um ataque SMTP denominado ‘directory harvest attack (DHA)’. Neste tipo de situação, as respostas ao comando RCPT TO: do servidor Exchange são pesquisadas para determinar se o endereço de e-mail de um usuário é válido ou não.

Se o recipiente for válido, o Exchange irá responder 250. 2.1.5.
Se o recipiente for inválido, o Exchange irá responder 550 5.1.1 User Unknown.

Desta forma, um ‘spammer’ pode escrever um script com um dicionário de nomes para construir endereços de e-mail de um domínio em particular. O script irá informar todos os endereços de e-mail que retornaram 250. 2.1.5 (o usuário existe e é válido) para o comando RCPT TO: e descartar todos os endereços de e-mail cuja resposta foi 550 5.1.1 User unknown (usuário inexistente).

A fonte geradora de mensagens do tipo spam então utiliza os endereços adquiridos através do ataque explicado anteriormente para enviar mensagens aos usuários.

Este tipo de ataque pode ser mitigado através de um método conhecido como ‘Tarpitting’. O SMTP do Windows 2003 Service Pack 1 possui uma forma de inserir um atraso nas respostas aos comandos SMTP. O servidor que está realizado o ataque não espera muito tempo pela resposta e a conexão é encerrada.

Mais informações sobre Tarpitting no Windows 2003:

SMTP tar pit feature for Microsoft Windows Server 2003
http://go.microsoft.com/fwlink/?LinkId=3052&kbid=842851

1.1 Sender ID

Sender ID é uma das grandes novidades do Exchange 2003 Service Pack 2. Sender ID é uma tecnologia que verifica se o servidor SMTP que está tentando enviar a mensagem é um servidor aprovado pelo domínio especificado no endereço SMTP do remetente.

Muitas mensagens de SPAM são falsificadas, de forma que a mensagem parece vir de um endereço SMTP legítimo. O usuário é “enganado”, pois ele pensa que a mensagem é de uma fonte legítima, como um banco, um prestador de serviço, etc, mas a mensagem na realidade é falsa, pois o endereço de e-mail foi plagiado. Este tipo de plágio é extremamente perigoso, pois o usuário pode informar dados importantes como conta bancária, endereço, etc,

Sender ID tenta basicamente eliminar ou reduzir este tipo de falsificação.

Para que o Sender ID funcione corretamente, é necessário a presença de duas partes.

01 – Um registro de DNS conhecido como “sender policy framework” ou SPF. O registro SPF define quais servidores estão autorizados a enviar mensagens de remetentes vindos do seu domínio SMTP.

02 – A segunda parte é um servidor SMTP, como o Exchange 2003 Service Pack 2, que suporta a tecnologia de Sender ID.

O registro SPF é adicionado a zona DNS para que outras organizações com o Sender ID possam verificar que mensagens de remetentes utilizando o seu domínio são realmente de servidores autorizados para tal.

O processo funciona da seguinte forma:

‘Spoofing’

1. Uma mensagem chega ao servidor Exchange, vinda do servidor SMTP fabrikam.com. O endereço de e-mail do remetente é susanf@nwtraders.com

2. O servidor Exchange faz uma query DNS para o registro SPF do domínio nwtraders.com.

3. Como nenhum registro SPF é encontrado, a mensagem passa pelo filtro do Sender ID.

Northwind Traders então adiciona um registro SPF na zona DNS nwtraders.com:

1. Uma mensagem chega ao servidor Exchange, vinda do servidor SMTP fabrikam.com. O endereço de e-mail do remetente é susanf@nwtraders.com

2. O servidor Exchange faz uma query DNS para o registro SPF do domínio nwtraders.com.

3. O endereço IP do servidor que está tentando enviar a mensagem (208.217.184.82) não está na lista de endereços IPs permitidos a enviar mensagens em nome de nwtraders.com. O registro SPF especifica que somente o servidor (131.107.76.156) pode fazer isso. Neste caso, a mensagem é recusada ou enviada a pasta de lixo eletrônico do usuário (depende da configuração do Sender ID).

Através da implementação do Sender ID você pode reduzir drasticamente o número de mensagens falsificadas (spoofed) de domínios que possuam o registro SPF.

Para habilitar o Sender ID, basta ir na guia “Sender ID” em propriedades de “Message Delivery”:

Na Microsoft, 59% das mensagens que possam do filtro de conexão são bloqueadas pelo filtro de protocolo.

Para ler a primeira parte deste artigo, clique aqui.

Fonte utilizada: http://www.microsoft.com/exchange/evaluation/features/antispam_framework.mspx

Viviane Lopes

Estrutura de Anti-Spam no Exchange Server 2003 Service Pack 2 – Parte I

2006-05-19T23:46:00Z

O Exchange Server 2003 Service Pack 2 utiliza diversos métodos para reduzir o volume de mensagens não solicitadas, popularmente conhecidas como ‘Spam’.

Nesta série de artigos apresentaremos uma visão geral dos métodos disponíveis no Exchange Server 2003 SP2 para controlar Spam e como este métodos trabalham juntos para reduzir o número total de mensagens indesejadas que chegam na caixa postal dos usuários.

O Exchange Server 2003 fornece proteção contra spam em três níveis diferentes:

§ Filtro de Conexão (Connection Filtering) - analisa o servidor de SMTP que está realizando a conexão.

§ Filtro de Protocolo (Protocol Filtering) – analisa o remetente e destinatário da mensagem.

§ Filtro de Conteúdo (Content Filtering) – analisa o conteúdo da mensagem.

Veja o exemplo à seguir:

Neste artigo, vamos conhecer mais sobre o Filtro de Conexão.

1 - Filtro de Conexão

A proteção oferecida pelo filtro de conexão é considerada a mais eficiente contra Spam, porque este tipo de filtro impede que a mensagem entre na organização Exchange. O filtro de conexão trabalha analisando cada tentativa de conexão SMTP entrante. Se o servidor que está tentando enviar a mensagem é identificado como uma fonte conhecida de spam, ou como um servidor que tipicamente não envia mensagens SMTP, então a conexão pode ser recusada, eliminando a necessidade de continuar o processamento da mensagem.

O Exchange 2003 Server possui dois tipos de Filtros de Conexão:

1.1 - Filtro de Conexão por endereço IP

Você pode definir se deseja recusar conexões SMTP baseado no endereço IP do servidor remoto. Este método de proteção é simples de ser configurado, porém a lista de endereços IP deve ser administrada manualmente.

Para incluir endereços IP na lista de bloqueio, basta ir no ‘Exchange System Manager’, propriedades de ‘Message Delivery’, e na guia ‘Connection Filtering’ selecionar ‘Deny’, como indicado na imagem abaixo:

Se incluirmos o endereço IP 10.0.0.200 na lista de endereços negados, qualquer tentativa de envio de mensagens provenientes deste endereço IP irá falhar com o erro:

550 5.7.0 Access Denied

Também é possível especificar endereços IP que são permitidos para conexões SMTP. Se você deseja receber mensagens de um servidor que foi identificado como origem de spam, basta você incluir o endereço IP na lista de “Accept”.

1.2 – Listas de bloqueio em tempo real (Real-Time Block lists)

Listas de bloqueio em tempo real são bancos de dados contendo endereços IPs de servidores já conhecidos como fonte de spam, open-relays, ou endereços IPs que fazem parte de um escopo que não deve incluir um servidor SMTP, por exemplo, um endereço IP fornecido por um provedor de Internet à um cliente de acesso discado.

Diversas empresas fazem a manutenção destes bancos de dados, coletando os endereços IPs que se encaixam nos perfis citados acima. Existem provedores RBL gratuitos, e também provedores RBL pagos.

O processo de filtro por RBL funciona da seguinte forma:

1 – Um servidor SMTP faz uma conexão ao servidor Exchange na porta TCP 25.

2 – O Servidor Exchange faz uma consulta DNS ao provedor RBL para verificar se o servidor SMTP que realizou a conexão está incluído na lista.

3 – Se o servidor SMTP não estiver incluído na lista, a conexão é permitida. Se o servidor SMTP estiver na lista RBL, então a conexão é cancelada.

A consulta DNS enviada ao provedor RBL é realizada utililizando o seguinte formato:

Se no exemplo acima, o endereço IP do servidor SMTP for 10.0.0.200, e o domínio SMTP do provedor RBL for contoso.com, a consulta realizada pelo servidor Exchange será:

200.0.0.10.contoso.com

O provedor RBL retorna uma das seguintes respostas:

§ ‘Host not found’ – o endereço IP solicitado não foi encontrado no banco de dados do provedor RBL.

§ ‘127.0.0.Status code’ – o endereço IP solicitado foi encontrado no banco de dados do provedor RBL. ‘Status code’ indica qual é o tipo de ofensa cometida por este servidor SMTP. O código pode variar entre provedores RBL, uma vez que não existe um padrão definido.

Você pode utilizar vários filtros de conexão para criar prioridades. Se você utilizar múltiplos servidores RBL, cada provedor será consultado seguindo a ordem em que eles aparecem na configuração do Exchange. Se uma resposta positiva for retornada, o Exchange não irá consultar nenhum provedor RBL adicional existente na lista.

Para configurar a listas RBL:

Na guia ‘Connection Filtering’, selecione ‘Add’ em ‘Block List Service Configuration’.

- ‘Display name’: nome para o filtro.

- ‘DNS Suffix of Provider’ – sufixo DNS fornecido pelo provedor RBL.

- ‘Custom Error Message to Return’ – você pode customizar a mensagem de erro que será mostrada ao servidor SMTP externo.

%0 – endereço IP do servidor SMTP externo

%1 – nome da regra do filtro de conexão

%2 – o provedor RBL

No exemplo acima, a mensagem de erro foi customizada para:

O endereço IP %0 foi rejeitado pelo provedor %2.

Em ‘Return Status Code’, você configurar como deseja configurar este filtro, de acordo com o ‘Status Code’ retornado pelo provedor RBL. O padrão é ‘Match Filter Rule to Any Return Code’.

Se o endereço IP 10.0.0.200 estiver presente no banco de dados do provedor RBL, qualquer tentativa de envio de mensagens provenientes deste endereço IP irá falhar com o erro:

550 5.7.1 Mensagem de erro customizada..

Na versões anteriores ao Service Pack 2, o filtro de conexão só está disponível se ‘firewalls’ ou servidores SMTP intermediários não existirem entre o servidor Exchange e o servidor SMTP externo. A razão é porque o filtro de conexão anterior ao Service Pack 2 considera somente o servidor realizando a conexão. Quando um servidor intermediário está posicionado entre o Exchange e o servidor SMTP externo, então apenas o endereço IP do servidor intermediário é analisado, o que praticamente inviabiliza o funcionamento do filtro de conexão.

Com a instalação do Exchange 2003 Service Pack 2, o servidor Exchange pode ser posicionado em qualquer lugar na organização – o filtro de conexão continua funcionando normalmente mesmo se houverem servidores intermediários, por exemplo, um servidor de antivírus, entre o servidor SMTP externo e o servidor Exchange. Isso é possível através da configuração dos endereços IPs ‘internos’ no Exchange System Manager. Desta forma, o endereço IP a ser analisado pelo RBL será efetivamente o endereço IP do servidor SMTP externo.

Na Microsoft, 25% das mensagens vindas da Internet são bloqueadas usando o filtro de conexão.

Nós próximos artigos, iremos explicar como funciona o Filtro de Protocolo e o Filtro de Conteúdo.

Se você deseja saber mais sobre o assunto, por favor verifique os seguintes links:

823866 How to configure connection filtering to use Realtime Block Lists (RBLs) and how to configure recipient filtering in Exchange 2003

http://support.microsoft.com/default.aspx?scid=kb;EN-US;823866

Fonte utilizada: http://www.microsoft.com/exchange/evaluation/features/antispam_framework.mspx

Viviane Lopes

Você está preparado para o Exchange Server 2007 ?

2006-05-16T23:14:00Z

A nova versão do servidor Exchange, nomeada oficialmente Exchange Server 2007 (previamente conhecido como “Exchange 12”), já está sendo testada por alguns clientes “Beta” da Microsoft.

O produto foi totalmente redesenhado, visando a redução de gastos e a complexidade de gerenciamento, ao mesmo tempo agregando mais valor e segurança para os usuários finais.

Leia à seguir um sumário de algumas mudanças introduzidas no produto.

Servidores Exchange 2007 serão baseados em funções:

§ “Hub” e “Edge Transport Server” – servidores responsáveis por enviar e receber mensagens dentro e fora da organização, incluindo mensagens de voz criadas por servidores do tipo “Unified Messaging”. Os servidores “Hub” e “Edge Transport” são também conhecidos apenas por “servidores de transporte”.

Os servidores “Edge” serão responsáveis por proteger a estrutura do Exchange contra mensagens contendo “spam” ou vírus. Uma vez que a mensagem tenha sido liberada pelo “Edge Server”, o “Hub Server” será responsável pela entrega final aos servidores de caixas postais.

§ “Unified Messaging Server” – servidor responsável por fornecer acesso do tipo “Outlook Voice Access”, assim como suporte para serviços de FAX.

§ “Client Access Server”  - servidor responsável por fornecer acesso via “Outlook Web Access”, “Exchange ActiveSync”, “Outlook Anywhere” (formalmente conhecido como “Outlook - RPC over Http”), e todos os outros protocolos de Internet, como POP3, etc.

§ “Mailbox Server” – servidor responsável por armazenar os dados de usuários, como caixas postais e pastas públicas.

Gerenciamento do servidor Exchange baseado no “Monad Shell”:

Primeiro, um pouco da história... O nome “Monad” vem de uma filosofia denominada “Monadism”, um idealismo criado pelo filosofo do século 18 chamado ‘Gottfried Wilhelm Leibniz’, que também é conhecido como co-inventor do Cálculo. A idéia por trás da filosofia “Monadism” é que o mundo é um agregado de substâncias simples, e a menor unidade existente é denominada “Monad”.

No que diz respeito ao sistema operacional Windows, “Monad” é um novo “shell” e ambiente de “scripting”. No Monad utilizamos comandos simples, também conhecidos como “Cmdlets” (“command-lets”), que combinados oferecem um forma rica e poderosa para administração de sistemas.

No Exchange Server 2007, toda a administração que pode ser realizada via interface gráfica, também será possível via linha de comando, através do Monad.

Veja alguns exemplos:

§ Configurar a cota de envio de mensagens para todos os usuários do tipo “mail-enabled” pertencentes a lista de distribuição “RemoteUsers” para 1000 KB:

Get-DistributionGroup “RemoteUsers” | Get-DistributionGroupMember | Set-Mailbox –ProhibitSendQuota 1000

§ Montar todos as bases de dados do servidor HONGKONG1:

Get-MailboxDatabase –server HONGKONG1 | Mount-Database

§ Mover todos os usuários do servidor PORTLAND para o servidor TUCSON (base de dados DB1):

Get-Mailbox –server PORTLAND | move-mailbox –targetDatabase “TUCSON\DB1”

Fonte: http://blogs.technet.com/exchange/archive/2005/08/16/409299.aspx

Para saber mais sobre o “Monad” visite:

http://encarta.msn.com/encyclopedia_761576058/Leibniz_Gottfried_Wilhelm.html

http://www.microsoft.com/technet/technetmag/issues/2005/11/Scripting/default.aspx

O servidor Exchange 2007 só estará disponível na versão 64 bits:

§ Os sistemas de correio eletrônico cresceram muito nos últimos tempos, e hoje é considerado aplicação de missão crítica para a maioria da empresas. A demanda cresce dia a dia, e por sua natureza, sistemas de 32 bits possuem limitações de memória que restringem a capacidade de suportar esta demanda. Por esta razão, a Microsoft disponibilizará a nova versão do Exchange Server apenas para sistemas de 64 bits, que fornece a arquitetura de sistema requerida para suportar a demanda crescente dos serviços de correio eletrônico.

§ Quais são os processadores 64 bits suportados pelo Exchange Server 2007 ? A maioria dos servidores fabricados atualmente oferecem suporte aos processadores 64 bits da Intel e AMD, incluindo a tecnologia Intel Extended Memory 64 Technology (EM64T) e o AMD64. O Exchange Server 2007 não irá suportar processadores Itanium (IA-64).

Leia mais sobre o Exchange Server 2007 em:

http://www.microsoft.com/exchange/preview/default.mspx

Viviane Lopes

Os erros 8197 - Free/Busy

2006-05-16T23:05:00Z

O seu servidor Exchange apresenta o erro 8197 a cada 25 minutos no log de aplicação? Se sim, este artigo poderá ajudá-lo a entender a causa deste erro. O evento 8197 é apresentado da seguinte forma:

Event Type: Error
Event Source: MSExchangeFBPublish
Event Category: General
Event ID: 8197
Description: Error initializing session for virtual machine MAIL-01. The error number is 0x80040111

Uma das razões mais comuns para ocorrência deste erro é que a tarefa em ‘background’ responsável por consultar o folder de sistema ‘Free/Busy’ para processar atualizações não conseguiu se conectar a um servidor de catálogo global, também conhecido como GC (Global Catalog - GC).

Ao contrário da maioria dos processos do Exchange, que utilizam o componente ‘DSAccess’ (Directory Access) para localizar servidores de catálogo global no Active Directory, o processo do ‘Free/Busy’ trabalha com o mecanismo de ‘referral’ existente no sistema operacional Windows.

O ‘Directory Access’ e o ‘referral’ do Windows utilizam algoritmos diferentes para determinar a ordem de preferência para utilização dos servidores de catálogo global. O resultado é que o processo do ‘Free/Busy’ pode eventualmente utilizar um servidor GC diferente do GC utilizado pelos demais processos do Exchange. Esta é a razão pela qual o processo do Free/Busy pode apresentar falhas, mesmo quando todos os serviços e demais processos do Exchange aparentam estar trabalhando normalmente.

Para investigar os erros 8197, você pode seguir os seguintes passos:

1. Determine qual é o servidor de catálogo global que o processo do ‘Free/Busy’ está tentando utilizar. Esta informação pode ser encontrada na seguinte chave de registro:

HKEY_USERS\.DEFAULT\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\ExchangeAdmin<nome do servidor> <GUID>

Nota: a chave acima só estará presente no registro se o serviço do ‘System Attendant’ estiver iniciado.

Uma vez estabelecido qual é o servidor de catálogo global que o processo do ‘Free/Busy’ está tentando utilizar, você deve investigar se este GC está trabalhando e respondendo corretamente. Ferramentas como DCDiag, NetDiag e Network monitor podem ajudá-lo nesta investigação.

2. Se o servidor de catálogo global aparentemente está funcionando sem problemas, o próximo passo é verificar se não existem entradas inválidas para este servidor no Active Directory (outra causa comum para os erros 8197). Para realizar esta verificação, você pode executar a seguinte consulta no prompt de comandos:

ldifde -f resultado.ldf -d "dc=dominio,dc=com" -t 3268 -p subtree -r "(&(objectclass=*)(name=meuservidor))”

Substitua o ‘meuservidor’ pelo nome do servidor determinado no passo 1, e ‘meudominio’ pelas informações do seu domínio.

Abra o arquivo gerado (resultado.ldf) e procure por entradas como:

dn: CN=MEUSERVIDOR,CN=Computers,DC=subdominio,DC=dominio,DC=com
…
distinguishedName: CN=MEUSERVIDOR,CN=Computers,DC=na,DC=dominio,DC=com

Entradas inválidas para servidores de catálogo global são comuns em muitos incidentes de suporte abertos na Microsoft. No caso acima, o servidor GC deveria estar localizado na unidade organizacional ‘Domain Controllers’, nunca em ‘Computers’. Portanto, o resultado esperado do comando ldifde deve ser algo como a entrada à seguir:

dn: CN=MEUSERVIDOR,OU=Domain Controllers,DC=dominio,DC=com
…
distinguishedName: CN=MEUSERVIDOR,OU=Domain Controllers,DC=dominio,DC=com

Quando ambas as entradas (a incorreta e a correta) estão presentes no Active Directory, uma consulta ao serviço de DNS para o servidor GC em questão pode resultar na entrada inválida – qualquer tentativa de conexão resultará em falhas.

Para resolver o problema, você deve apagar a entrada incorreta, e limpar o cache de DNS (ipconfig /flushdns). Entradas inválidas como o exemplo anterior podem ser criadas quando um servidor é membro de um domínio, e posteriormente este mesmo servidor é promovido a controlador de domínio/servidor de catálogo em um domínio diferente.

Se os erros 8197 continuarem a ser informados no log de aplicação depois da execução dos passos 1 e 2, então possivelmente você tem um problema diferente.

Por exemplo, uma outra causa comum para a ocorrência do erro 8197 é a instalação do cliente Outlook na mesma máquina onde o servidor Exchange está instalado. Você nunca deve instalar o cliente Outlook no servidor Exchange, nem mesmo para testes.

Bibliotecas de sistema (‘DLLs’) do Exchange como a mapi32.dll, emsabp32.dll e emsmdb32.dll são substituídas pelas versões do cliente Outlook, e os resultados são inesperados.

Este tipo de ambiente, Outlook e Exchange no mesmo equipamento, representa um cenário não suportado pela Microsoft.

Mais informações:

266418 Microsoft does not support installing Exchange Server components and Outlook on the same computer
http://support.microsoft.com/default.aspx?scid=kb;EN-US;266418

Vale a pena saber:

Adicionalmente, o componente do Exchange denominado ‘Mailbox Manager’ também utiliza o mecanismo de ‘referral’ do Windows para localização e utilização de GCs no Active Directory. Geralmente, quando o processo do ‘Free/Busy’ falha com o erro 8197, o ‘Mailbox Manager’ também apresenta os seguintes eventos de erro:

Event Type: Error
Event Source: MSExchangeSA
Event ID: 9175
Description: The MAPI call 'OpenMsgStore' failed with the following error: The information store could not be opened. The logon to the Microsoft Exchange Server computer failed. MAPI 1.0 ID no: 80040111-0286-00000000

Event Type: Error
Event Source: MSExchangeSA
Event Category: Mailbox Management
Event ID: 9200
Description: Failed to perform MAPI logon.

A instalação do cliente Outlook no servidor Exchange também pode causar falhas no componente do ‘Mailbox Manager’.

Qual é a razão para diferentes componentes do Exchange utilizarem mecanismos separados para localização de servidores de catálogo global no Active Directory?

A intenção da Microsoft foi possibilitar que a console de administração do Exchange (Exchange System Manager) pudesse ser instalada em computadores sem os serviços do Exchange, e independente do componente ‘Directory Access’.

Desta forma, vários processos como o ‘Free/Busy’ foram desenvolvidos para utilizar o mecanismo de localização de GCs existente no próprio sistema operacional.

Você deve então estar se perguntando porque todos os componentes não utilizam o mecanismo de localização de GCs do sistema operacional. A resposta é simples – por questões de performance.

Se o mecanismo de localização de GCs for utilizado por todos os componentes do Exchange, a performance não seria a mesma para uma determinada tarefa.

O componente do ‘Directory Access’ é otimizado para as consultas do Exchange Server ao Active Directory, e também serve como cache para os resultados destas consultas. O cache aumenta a performance do Exchange substancialmente, e reduz a carga nos servidores DC/GCs.

Viviane Lopes

Fonte utilizada: http://blogs.technet.com/exchange/archive/2005/07/29/408394.aspx

Update disponível para aliviar o evento 9548

2006-03-31T01:20:00Z

Microsoft lança um update para o Exchange 2003 para aliviar o evento 9548 – “user does not have a master account SID”.

Um dos eventos mais comuns encontrados em servidores Exchange 2000 ou 2003 é o evento 9548:

O evento acima indica que o serviço do “Information Store” encontrou a conta de usuário desabilitada denominada “Richard”, e o usuário em questão não possui o atributo msExchMasterAccountSid configurado.

Para simular este evento, basta desabilitar uma conta de usuário no “Active Directory” associada a uma caixa de correio no servidor Exchange 2000 ou 2003, e então enviar uma mensagem para este usuário. Se você não tiver o cuidado de configurar o msExchMasterAccountSid, o evento 9548 será informado no log de aplicações.

Na minha experiência como Engenheira de Suporte na Microsoft, a ausência do atributo msExchMasterAccountSid contribuiu para a abertura de inúmeros incidentes relacionados aos mais diversos tipos de problemas – má performance no servidor Exchange, popups de RPC no cliente Outlook, failovers inesperados, entre outros.

O que significa o atributo msExchMasterAccountSid ?

Quando o Exchange 2000 ou Exchange 2003 calcula as permissões de acesso a um determinado objeto, por exemplo, um “Public Folder”, existem duas possibilidades para o cálculo de tais permissões, dependendo de como a conta do usuário se encontra no Active Directory – habilitada ou desabilitada.

Se a conta de usuário estiver habilitada, as permissões são calculadas utilizando os atributos objectSID ou SIDHistory.

Se a conta de usuário estiver desabilitada, as permissões são calculadas utilizando o atributo msExchMasterAccountSid.

Em suma, a lógica para permitir acesso aos objetos do Exchange funciona da seguinte forma:

Usuário desabilitado – o Exchange consulta o msExchMasterAccountSid para determinar o SID e fornecer acesso aos objetos.

Usuários habilitado – o Exchange consulta o objectSID ou SIDHistory do usuário para fornecer acesso a objetos.

Desta forma, é necessário que o usuário desabilitado no Active Directory tenha o atributo msExchMasterAccountSid configurado para que o cálculo de permissões funcione corretamente. Seguindo a mesma lógica, o usuário habilitado não deve possuir o referido atributo.

Corrigir o problema é muito simples. Basicamente, após desabilitar uma conta de usuário no Active Directory associada a uma caixa postal no Exchange 2000 ou Exchange 2003, a única ação a ser tomada é atribuir a permissão de “Associated External Account” para SELF, conforme indicado no exemplo à seguir:

(Active Directory Users and Computers, propriedades do usuário, guia Exchange Advanced, Mailbox Rights”).

Diversos scripts customizados ou ferramentas como o NoMas (http://www.msexchange.org/articles/NoMAS-Tool.html) eram utilizados pelos administradores para automatizar esta tarefa.

Mas se você utiliza servidores Exchange 2003, tudo isso é passado ...

A boa notícia é que o uso de scripts ou de ferramentas como o NoMas não é mais necessário em servidores Exchange 2003. Recentemente, a Microsoft lançou um hotfix para alterar este comportamento. A primeira versão deste hotfix está disponível através do artigo 903158.

903158 A hotfix is available to modify the way that Exchange Server 2003 handles a disabled Active Directory user account that is associated with an Exchange Server 2003 mailbox

http://support.microsoft.com/default.aspx?scid=kb;EN-US;903158

Após a instalação desta hotfix, o Exchange 2003 irá utilizar uma nova lógica para o cálculo das permissões, explicada à seguir:

01 – Se a conta de usuário estiver desabilitada e o atributo msExchMasterAccountSid estiver configurado para uma conta localizada em um domínio externo, então o msExchMasterAccountSid é o SID associado com a caixa de correio. (nenhuma alteração no comportamento original).

02 – Se a conta de usuário estiver desabilitada, e o atributo msExchMasterAccountSid não estiver configurado, então o Exchange irá utilizar o objectSID. A grande alteração no código do Exchange 2003 está aqui!

03 – Se o Exchange não conseguir determinar se a conta está habilitada ou desabilitada devido as permissões colocadas no objeto, ou se o Exchange não conseguir obter acesso ao atributo objectSID (problema também relacionado à permissões), então a operação irá falhar e o evento 9548 será informado no log de aplicações.

A conclusão é que à partir de agora, após a instalação do hotfix mencionado acima, a única forma do evento 9548 ser informado em um servidor Exchange 2003 é se existir um problema “real” com a conta de usuário associado a caixa postal.

Nota: o hotfix é válido apenas para servidores Exchange 2003 - servidores Exchange 2000 permanecem com o comportamento inalterado.

Viviane Lopes

Checkpoint Depth too deep

2006-03-15T19:15:00Z

Uma das causas mais comuns para o súbito shutdown dos bancos de dados de um servidor Exchange é o comportamento conhecido como “Checkpoint Depth too deep”.

Neste artigo vou explicar o que acontece durante o processo, principais causas e como monitorar o servidor Exchange de forma a evitar o acontecimento deste comportamento.

Conceitos importantes:

ESE (Extensible Storage Engine): Database Engine utilizada pelo Exchange Information Store, baseado na tecnologia denominada Microsoft Joint Engine (JET).
Log de transação (Transaction Log): Todas as alterações realizadas no banco de dados do Exchange são inicialmente gravadas no log de transação, e posteriormente no banco de dados.

Os logs de transações são críticos para o servidor Exchange e existem para garantir a integridade transacional do banco de dados e possibilitar a recuperação total dos dados em caso de uma parada abrupta do servidor.
Checkpoint: O Checkpoint é um arquivo de sistema do servidor Exchange responsável por acompanhar o progresso dos logs de transações em relação aos bancos de dados.

Cada Storage Group contém um único arquivo de Checkpoint, denominado Enn.chk, onde nn representa o prefixo do Storage Group em questão.

Exemplo:

E00.chk – checkpoint do Primeiro Storage Group.

E01.chk – checkpoint do Segundo Storage Group

E02.chk – checkpoint do Terceiro Storage Group.

E03.chk – checkpoint do Quarto Storage Group.

Checkpoint Depth:

Em um servidor Exchange 2000 ou 2003, cada Storage Group pode ter no máximo 1008 logs de transações não aplicados nos bancos de dados em um dado momento. O número 1008 está pré-definido no código do produto e não pode ser customizado.

O controle de transações não aplicadas no banco de dados é realizado através do Checkpoint.

Quando o número de logs de transações não aplicados em um Storage Group atinge o número máximo permitido, o servidor Exchange começa o processo de shutdown de todos os bancos de dados do Storage Group em questão.

Nesta situação, os seguintes eventos são informados no log de aplicações:

Event ID: 471

Category: Logging/Recovery

Source: ESE

Type: Error

Message: Information Store (2908) Unable to rollback operation #12317050 on database G:\First Storage Group\Mailbox Store (Server1). Error: -614. All future database updates will be rejected.

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1159
Description: Database error 0xfffffd9a occurred in function JTAB_BASE::EcUpdate while accessing the database "<C:\Program Files\Exchsrvr\mdbdata\vip.edb>".

Os erros -614 e 0xfffffd9a podem ser traduzidos para:

“JET_errCheckpointDepthTooDeep” – too many outstanding generations between checkpoint and current generation.

O serviço do Information Store opera desta forma para impedir que o controle de Checkpoint fique muito distante dos logs de transações criados pelo sistema. É uma proteção do servidor Exchange para garantir a integridade dos dados.

Em um servidor Exchange com alto volume de carga, o valor do Checkpoint Depth normalmente deve ficar entre 4 ou 5 logs. Isso significa que as transações contidas nestes logs ainda não foram aplicadas no banco de dados. Se o servidor parar subitamente, por exemplo, por um problema de falta de energia, estes 4 logs serão os logs de transações necessários para colocar o banco de dados consistente, até o momento da queda.

Quando a energia for restaurada e o serviço do Information Store reiniciado, o arquivo Checkpoint de cada Storage Group será consultado. O Checkpoint informa ao Information Store à partir de qual log de transação ele deverá iniciar o processo de recuperação dos dados que ainda não haviam sido gravados nos bancos de dados.

Os cenários mais comuns para o acontecimento deste problema são:

01 – Um processo “congelou” as atualizações no arquivo de checkpoint. Normalmente isso acontece durante o processo de backup on-line.

02 – Duas tarefas concorrentes estão sendo executadas ao mesmo tempo, como por exemplo uma movimentação de mailboxes em larga escala e uma tarefa de backup.

03 – O servidor está experimentando problemas de performance. Por exemplo, problemas de performance nos discos podem prevenir o servidor de responder rapidamente a múltiplas requisições de I/O.

Como monitorar o servidor Exchange ?

01 - À partir do Rollup de Setembro para o Exchange 2000 e versões posteriores, é possivel monitorar o número de logs de transações não aplicados em um Storage Group através do Performance Monitor.

O contador “Log Generation Checkpoint Depth” (Objeto Database è Instances) reporta o número de logs de transações de um Storage Group que ainda não foram aplicados nos bancos de dados.

O valor informado pode ser entendido como a quantidade de logs que devem ser aplicados no banco de dados caso o processo do Information Store (Store.exe) apresente qualquer tipo de falha.

A lógica é – quanto maior o “Log generation depth”, mais tempo o processo de inicio (startup) do serviço do Information Store levará.

Muitas vezes trabalhamos em incidentes de suporte em que o cliente reporta uma demora significativa para que o serviço do Information Store inicie – nesta situação, o serviço permanece no estado de “Starting” e todas as tentativas de conexões de clientes são recusadas.

O log de aplicações irá reportar o evento 301 – indicando que o processo de aplicação dos logs de transações nos bancos de dados está sendo realizado (soft-recovery). Se o Checkpoint estiver muito atrás em relação a geração de logs presente no disco, o processo poderá demorar muito mais do que o “desejado”.

Event Type: Information
Event Source: ESE
Event Category:
Event ID: 301
Description: Information Store (1728) The database engine has begun replaying logfile D:\Program Files\Exchsrvr\SG1\E001453A.log.

O efeito colateral é obviamente percebido pelos clientes, que não poderão se conectar no servidor Exchange enquanto o processo não estiver finalizado.

No exemplo abaixo, o Checkpoint Depth está no valor 4, ou seja, informações contidas em 4 logs de transações ainda não foram aplicados nos bancos de dados.

Durante uma tarefa de backup, é normal que este valor cresça, pois o processo de backup “congela” o checkpoint temporariamente para garantir a integridade dos dados que estão sendo copiados. Porém, se o tempo de backup de um Storage Group for demasiado alto, e o servidor estiver sendo acessado durante o processo (gerando logs de transações), o valor pode chegar ao limite de 1008 logs, quando então todos os bancos de dados serão desmontados.

A solução neste caso é planejar o tamanho dos Storage Groups adequadamente, levando em consideração o tempo de backup e a quantidade de logs de transações gerados durante as atividades normais dos usuários.

Outra situação comum, é uma tarefa de backup mal-sucedida, onde o processo de backup não descongela o Checkpoint. O servidor Exchange continuará trabalhando normalmente, até que o Checkpoint Depth atinga 1008 logs – neste ponto os bancos de dados serão desmontados.

Neste caso, o melhor é verificar o que há de errado com a rotina de backup e o motivo pela qual o processo não está sendo finalizado corretamente.

02 – Outra forma de monitorar o CheckPoint Depth é utilizando o pacote para monitoramento do Exchange existente no servidor MOM (Microsoft Operations Management):

O pacote de monitoramento para Exchange existente no servidor MOM inclui a seguinte regra:

ESE Log Generation CheckPoint Depth > 800 – O MOM irá disparar um alerta ao administrador quando o valor ultrapassar a marca de 800.

Se você precisar de mais informações, por favor utilize os seguintes artigos da Microsoft como referência:

905801 The information store is dismounted, and an event ID 1159 message is logged in Exchange Server 2003 or in Exchange 2000 Server

http://support.microsoft.com/default.aspx?scid=kb;EN-US;905801

819771 Update to monitor uncommitted transaction log files

http://support.microsoft.com/default.aspx?scid=kb;EN-US;819771

Viviane Lopes

Como o Horário de Verão afeta compromissos e o calendário no cliente Outlook

2006-02-21T01:41:00Z

Alguns países como Chile, Brasil e Israel adotam um sistema variável para o horário de verão. As datas de inicio e término mudam a cada ano seguindo uma determinação estabelecida pelo governo federal.

Como resultado destas mudanças, os usuários experimentam o inconveniente de terem seus compromissos e reuniões alterados em 1 hora. Todos os anos, a Microsoft recebe inúmeros chamados de clientes reportando este comportamento.

Vamos explicar o que ocasiona este comportamento bem como maneiras de minimizar o impacto para os usuários do Outlook.

Tomemos o Brasil como exemplo. A configuração do fuso horário padrão do Brasil (GMT -03:00 Brasília) em qualquer sistema operacional da Microsoft é:

Inicio do Horário de Verão: Terceiro domingo de Outubro as 02:00 da manhã.

Término do Horário de Verão: Segundo domingo de Fevereiro as 02:00 da manhã.

Ajustar automaticamente o relógio para o horário de verão: Habilitado.

Para o ano de 2005/2006, o governo brasileiro determinou as seguintes datas para o Horário de Verão:

Inicio do Horário de Verão: 16 de Outubro de 2005 (Terceiro domingo de Outubro).

Término do Horário de Verão: 19 de Fevereiro de 2006 (Terceiro domingo de Fevereiro).

Quando as novas datas são publicadas pelo governo, os administradores precisam atualizar todas as máquinas instaladas com sistemas operacionais da Microsoft com as novas informações do horário de verão. Geralmente, as informações descritas no artigo KB: 317211 e a ferramenta “Time Zone Editor” (tzedit.exe) são utilizadas para atualizar o fuso horário em questão.

Como podemos perceber, existe uma diferença entre o Horário de Verão padrão do Windows e as datas definidas pelo governo. Vamos denominar esta diferença de “Período Delta”.

Para o ano de 2005/2006, o período delta ocorre somente no final do horário de verão, como indicado abaixo:

O problema experimentado pelos usuários do cliente Outlook acontece para todos os compromissos durante o período delta criados antes da atualização do horário de versão no sistema operacional. Estes compromissos estarão com o horário alterado em 1 hora. Todos os compromissos criados depois da atualização do horário de verão estarão com o horário correto.

O questionamento colocado por todos os clientes que utilizam o Microsoft Outlook é – Por que experimentamos este comportamento ? Para responder esta pergunta, temos que entender como o cliente Outlook agenda reuniões e compromissos:

Três fatores afetam a forma como o Outlook agenda uma reunião ou um compromisso:

O horário do computador.
A configuração de fuso horário do sistema operacional.
A configuração de ajuste automático para o horário de verão.

O Outlook estampa o compromisso ou reunião com a informação do fuso horário de Greenwich, denominada “Greenwich Mean Time”. A fórmula para determinar o “Greenwich Mean time” utiliza como base o relógio do computador, o ajuste do fuso horário local (incremento ou decremento de horas dependendo do fuso horário), e o ajuste automático do Horário de Verão (incremento ou decremento de 1 hora dependendo da época do ano).

Exemplo:

Horário local para a reunião: 5:00 da tarde Horário de Brasília

Ajuste para o fuso horário de Brasília: - 3:00 horas

Ajuste para o horário de verão (positivo ou negativo): -1:00 hora

Greenwich Mean time resultante: 1:00 da tarde Greenwich Mean time

Assim que o Outlook recebe a solicitação de reunião, os cálculos para o horário da reunião são realizados seguindo a regra acima, e então o item é gravado no calendário dos usuários envolvidos.

Se qualquer um dos fatores mencionados estiverem incorretos quando o compromisso ou reunião é criado, o horário final (Greenwich Mean Time) será calculado incorretamente. Não é possível corrigir o horário após a criação da reunião através da tentativa de corrigir o fator em erro.

Por exemplo, se o sistema operacional não estiver com o ajuste de horário de verão automático corretamente configurado, todos os itens criados terão o seu horário Greenwich Mean time incorretamente calculados. Para corrigir o horário após a criação da reunião, será necessário abrir o item no Outlook e manualmente corrigir o horário.

O que pode ser feito para corrigir os itens criados no Período Delta ?

Os usuários podem modificar cada compromisso manualmente depois que as informações do horário de verão forem atualizados no sistema operacional.

Não existe uma forma centralizada para que os administradores do Exchange Server possam atualizar os itens no calendário dos usuários.

Recomendações adicionais para minimizar a ocorrência deste comportamento:

Assim que o governo publicar as alterações para o Horário de Verão, verifique qual é o “Período Delta” e simule as alterações necessárias em laboratório. Assim você saberá antecipadamente que mudanças esperar no ambiente de produção.
Trabalhe em conjunto com o time responsável por atualizar o Horário de Verão no sistema operacional o mais cedo possível, de forma a minimizar a criação de compromissos e reuniões durante o Período Delta antes da atualização do Horário de Verão no sistema operacional.
Antes que qualquer alteração no Horário de Verão seja realizada, solicite aos usuários que imprimam seus calendários. O calendário impresso pode servir como referência caso seja necessário atualizar os itens manualmente.
Para reuniões com múltiplos participantes, apenas o organizador da reunião deverá atualizar o horário e então enviar a atualização aos participantes.
Ao término do Horário de Verão, modifique o sistema operacional de forma a espelhar o padrão do Horário de Verão do seu fuso horário. Esta ação tem como objetivo evitar a existência de um mix de computadores com configurações diferentes, alguns com as datas do Horário de Verão alteradas, outros com o Horário de Verão padrão do Windows (por exemplo, novos equipamentos adicionados a organização).

Se você precisar de mais informações, por favor utilize os seguintes artigos da Microsoft como referência:

317211 How to configure daylight saving time dates for Brazil

http://support.microsoft.com/?id=317211

195900 How Outlook handles time zones for meeting requests

http://support.microsoft.com/?id=195900

197480 OL2000: Changing the Time Zone Without Changing Appointment Times

http://support.microsoft.com/?id=197480

Viviane Lopes e Nicolas Souza