Resolvendo problemas comuns relacionados ao Exchange ActiveSync (erros 0x80072F0D e 0X85010014)

Article
09/25/2008

Por: Rodrigo Sorbara / Revisado por: Viviane Lopes

Neste artigo falaremos dos problemas mais comuns relacionados à falha no sincronismo de caixas postais de usuários através do EAS (Exchange ActiveSync) e as linhas de troubleshooting que podem ser adotadas.

Levantando informações sobre o ambiente

Antes de entrar em detalhes sobre o que os códigos de erro significam e como tratá-los, precisamos obter respostas sobre como está estruturado o ambiente e qual é o cenário atual.

O acesso via OWA está sendo possível via HTTP e/ou HTTPS? Caso os usuários não estejam conseguindo estabelecer este tipo de acesso, talvez seja melhor começar a investigar outros problemas relacionados à infra-estrutura de rede e servidores (problemas de DNS, firewalls, IIS etc...) levando em consideração os sintomas observados.
O problema durante o sincronismo através do EAS acontece com todos os usuários? A mensagem de erro é sempre a mesma ou varia entre os usuários? O sincronismo ocorre com sucesso se utilizarmos HTTP puro (sem SSL)?
Qual é a topologia utilizada? Temos uma estrutura de FE/BE ou apenas um servidor Exchange na organização? Caso exista apenas um servidor Stand-alone e este esteja configurado para o uso de SSL e FBA, leia o artigo KB817379.
Se o SSL estiver configurado no diretório virtual Exchange, precisamos verificar se o certificado foi emitido por uma autoridade certificadora comercial como Verisign ou Thawte, ou se o certificado provém de uma CA interna.

O que representa o código de erro 0x80072F0D?

Este primeiro código de erro e sua descrição, nos reporta basicamente uma falha durante a comunicação SSL entre cliente e servidor:

The security certificate on the server is invalid. Contact your system administrator or ISP to install a valid certificate on the server and try again.
Support Code:
0x80072F0D

Antes de começarmos a tratar a mensagem de erro acima, precisamos saber se o sincronismo via ActiveSync acontece normalmente quando utilizamos uma conexão HTTP (sem SLL). Se recebermos um código de erro diferente de "0x80072F0D" durante este novo teste via HTTP, deveremos então tratá-lo primeiramente antes de verificar a questão relacionada ao certificado.

O código de erro 0x80072F0D nos indica na maioria das vezes a falta do certificado da Autoridade Certificadora Raiz (RootCA) no cliente. No entanto, existem situações menos freqüentes em que este erro pode ser ocasionado como certificado(s) expirado(s) (tanto no cliente como no servidor), ou até mesmo bloqueio de funcionalidades via ROM ou cartão SIM realizado pelas operadoras nos dispositivos móveis.

Como não temos a opção de simplesmente ignorar este erro e ir adiante (como podemos fazer no OWA), teremos que verificar qual RootCA (interna ou comercial) foi responsável pela emissão do certificado instalado no site do IIS em que o diretório virtual Exchange reside e se o certificado relacionado à esta autoridade certificadora está devidamente presente nos dispositivos móveis.

Importando o certificado do RootCA nos dispositivos móveis (WM5 e WM6)

Antes de iniciar a importação, é necessário verificar se o certificado do RootCA, e o certificado instalado no diretório virtual Exchange não estão expirados ou inválidos.

Após essa verificação, precisamos exportar o certificado da Autoridade Certificadora Raiz de alguma máquina que já o possua e importá-lo no dispositivo móvel.

Assim que for exportado para um arquivo de extensão *.CER, este certificado poderá ser disponibilizado para o cliente via FTP, Pen-drive ou compartilhamento de rede.

Abaixo segue um exemplo básico de como fazer o "download" e importação do certificado no Windows Mobile 6 (WM6):

Você então deverá receber a seguinte confirmação:

Atenção: Não existe uma maneira de importar o certificado disponibilizando-o através de um site HTTP. O navegador não consegue realizar a abertura e importação do certificado.

O procedimento para importação no Windows Mobile 5 (WM5) requer o uso da ferramenta SmartPhoneAddCert.exe conforme documentado noartigo KB915840. Este artigo também disponibiliza uma lista dos certificados de Autoridades Certificadoras Raízes que normalmente já estão presentes nos dispositivos móveis por padrão.

Como realizar o troubleshooting do código de erro 0X85010014?

Nesta seção citarei algumas situações que podem ocasionar a mensagem de erro abaixo durante a tentativa de sincronismo através do EAS.

ActiveSync encountered a problem on the server
Support code 0x85010014

Primeiramente é importante lembrar que a comunicação entre servidores FE e BE ocorre apenas via porta 80 (HTTP). Por este motivo, é importante dizer que nunca devemos requerer SSL no diretório virtual Exchange em nenhum Back-end.

Se o objetivo é melhorar a segurança durante esta conversa, a forma indicada para tal é o uso de IPSEC entre os servidores Front-End e Back-end.

Cenário 1 - Servidor Stand-alone com FBA e SSL habilitado

Quando temos somente um servidor Exchange (Stand-alone) e o uso da autenticação baseada em formulários (FBA) e SSL em conjunto, o código de erro 0x85010014 também será exibido para o cliente. Este é um problema conhecido neste tipo de ambiente documentado através do artigo KB817379.

OBS: Esta documentação também apresenta soluções para este tipo de cenário.

Cenário 2 – Autenticação Integrada não selecionada no diretório virtual Exchange

Um outro erro de configuração bastante comum é a falta de autenticação integrada no diretório virtual Exchange no servidor que contém a mailbox do usuário. Como o mecanismo de autenticação do ActiveSync negocia a forma de autenticação que será utilizada pelo cliente (Kerberos ou NTLM), esta certamente falhará caso esta opção não esteja selecionada.

Habilitar a opção “Windows Integrated Authentication” no diretório virtual Exchange deve resolver o problema. No entanto, caso o código de erro 0x85010014 continue a ser exibido, siga os passos adiante.

Cenário 3 – Parâmetro "NTAuthenticationProviders" não configurado corretamente

Para acessar o conteúdo da caixa postal do usuário, os diretórios virtuais Microsoft-Server-ActiveSync e OMA fazem um logon DAV explícito no diretório virtual Exchange do servidor Back-end onde a caixa do usuário existe similar ao exemplificado abaixo:

https://netbios_name_of_mailbox_server/exchange/mailbox_alias

Durante o processo de autenticação, o IIS transmite o cabeçalho de segurança “Negotiate” do servidor FE para o BE para que o cliente possa posteriormente negociar e escolher qual método de autenticação será utilizado (Kerberos ou NTLM).

Por este motivo, a não configuração do parâmetro NTAuthenticationProviders para o valor "Negotiate,NTLM" na metabase do IIS do servidor Back-end também pode causar falha na autenticação e, consequentemente, gerar a mensagem de erro 0x85010014 durante a tentativa de sincronismo da caixa postal do usuário.

Nesta ocasião teremos a seguinte evidência de erro no log de aplicativo do servidor:

Event Type: Error
Event Source: Server ActiveSync
Event Category: None
Event ID: 3031
Date: 31/1/2008
Time: 15:27:53
User: CONTOSO\user.1
Computer: ALD060

Description:

The mailbox server [exchange-be.contoso.com] does not allow "Negotiate" authentication to its [exchange] virtual directory. Exchange ActiveSync can only access the server using this authentication scheme.

Para verificar se este parâmetro está corretamente configurado no servidor BE responsável pela caixa postal do usuário devemos utilizar o script adsutil.vbs com a sintaxe abaixo:

C:\Inetpub\AdminScripts>cscript adsutil.vbs get w3svc/1/root/NTAuthenticationProviders
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

The parameter "NTAuthenticationProviders" is not set at this node.

Para configurá-lo corretamente teremos que executar o script adsutil.vbs com a sintaxe abaixo também extraído do artigo KB215383:

C:\Inetpub\AdminScripts>cscript adsutil.vbs set w3svc/1/root/NTAuthenticationProviders "Negotiate,NTLM"
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

NTAuthenticationProviders : (STRING) "Negotiate,NTLM"

Cenário 4 - Tamanho do token de autenticação do usuário

Caso o código de erro 0x85010014 esteja sendo retornado apenas para alguns usuários, a causa raiz do problema provavelmente estará relacionada com a falha na autenticação Kerberos devido à uma limitação existente no tamanho do token de autenticação do usuário.

Este problema normalmente acontece quando um determinado usuário faz parte de mais de 120 grupos no Active Directory e pode ser contornado com o ajuste do valor de registro MaxTokenSize em todos os controladores de domínio e servidores Exchange da organização.

O artigo KB330463 dá maiores detalhes sobre as ações que devem ser tomadas.

Outras ferramentas e métodos de troubleshooting úteis

Um dos logs que pode ser habilitado no lado do cliente que certamente colaborará para o bom andamento do troubleshooting pode ser habilitado seguindo as instruções disponíveis aqui.
O log do IIS também ajudará a conduzir a análise de uma forma proveitosa. O procedimento para habilitá-lo pode ser encontrado aqui.
Se ainda assim os problemas de sincronismo ainda continuem, o “approach” recomendado é abrir um incidente de suporte para que possamos melhor auxiliá-lo através do uso de ferramentas internas e recursos especialistas.