Os erros 8197 - Free/Busy
Por: Viviane Lopes
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
https://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: https://blogs.technet.com/exchange/archive/2005/07/29/408394.aspx