Explorando o SharePointSolução de problemas de integração do sistema de mensagens

Pav Cherny

Código disponível para download em: SharePoint2008_08.exe(416 KB)

Sumário

Abordagem geral da solução de problemas
Arquitetura do sistema de mensagens do SharePoint
Obtendo informações sobre diagnóstico
Transferência de mensagens de saída
Transferência de mensagens de entrada
Gerenciamento de diretórios
Conclusão

Em um ambiente bem projetado do SharePoint, os operadores de informações não precisam alterar seus hábitos de comunicação nem suas rotinas de trabalho para colaborar. Em vez de verificar manualmente os sites de colaboração de forma contínua, o SharePoint pode entregar documentos e outras informações, como alertas e lembretes, diretamente em suas caixas de correio.

Os usuários também podem participar em fluxos de trabalho respondendo a essas mensagens ou enviando novos itens como mensagens de email a bibliotecas de documentos e listas.

Entretanto, integrar o SharePoint® a um ambiente de sistema de mensagens seguro é um desafio, além de representar uma oportunidade para os componentes que não sejam do SharePoint influenciarem na colaboração baseada no SharePoint. O desafio é isolar e eliminar, com eficiência, as causas dos problemas do ambiente integrado sempre que eles ocorrerem.

Nesta coluna, falarei sobre a integração do sistema de mensagens do SharePoint baseada em uma comprovada estratégia de solução de problemas que fornece resultados rápidos. A idéia é localizar o ponto problemático de forma eficiente e abordá-lo com etapas de solução de problemas direcionadas e mais detalhadas.

Em uma organização de grande porte, essa investigação em fases pode significar a entrega do caso para outro especialista depois de uma análise inicial, especialmente se o problema estiver relacionado a componentes que não são do SharePoint. Em organizações de pequeno e médio portes, porém, não raro, um único administrador de TI deve ser capaz de solucionar os problemas de todos os sistemas envolvidos diretamente, o que reforça ainda mais a necessidade de usar abordagens estruturadas.

Para manter esta coluna orientada à prática, usei um ambiente de teste com o Active Directory®, Exchange Server 2007 e o WSS 3.0. As instruções passo a passo para criar esse ambiente de teste, bem como as ferramentas de solução de problemas discutidas nesta coluna, estão no material complementar, disponível na seção de downloads de código do site da TechNet Magazine.

Abordagem geral da solução de problemas

Talvez mais do que em qualquer outro cenário de interoperabilidade, a solução de problemas de integração do sistema de mensagens do SharePoint requeira uma abordagem extremamente estruturada. Há vários fatores que complicam essa tarefa.

Obviamente, é preciso lidar com tecnologias complexas e, ao se deparar com questões de transferência de mensagens, conversões de formatos de mensagem, aspectos de segurança e problemas de gerenciamento de diretórios, você verá que algumas mensagens de erro do SharePoint são bem confusas. Os grupos de notícias da Internet são repletos de linhas de discussão não resolvidas e sugestões que podem levá-lo a seguir o caminho errado — por exemplo, executar todos os aplicativos Web sob a identidade do pool de aplicativos para a Administração Central do SharePoint a fim de fazer com que a integração do sistema de mensagens funcione.

Mas há também aspectos positivos. O SharePoint é muito flexível. Na verdade, ele pode fornecer informações detalhadas sobre solução de problemas se você souber onde procurar. Com alguns scripts básicos, você pode melhorar muito sua eficiência na solução de problemas.

O primeiro objetivo da solução de problemas é entender o problema específico com o qual você está lidando. É necessário identificar onde o problema está localizado e quais componentes estão envolvidos. Você também pode tentar reproduzir o problema variando as configurações do sistema e estudando os logs de eventos e os arquivos de log baseados em texto do Windows®. Contudo, isso pode ser complicado, já que alguns problemas ocorrem apenas esporadicamente. Ainda assim, quanto melhor você conseguir reproduzir um problema, mais rápido poderá identificar e eliminar sua causa. Outro objetivo importante, muitas vezes negligenciado, é documentar todas as alterações e correções de configuração e verificar se elas foram aplicadas a todos os sistemas relevantes no ambiente, como todos os servidores front-end em uma Web farm.

Arquitetura do sistema de mensagens do SharePoint

Sempre que surgir um problema relacionado à integração do sistema de mensagens, uma sugestão é que você primeiro tome uma xícara de café ou de chá e, em seguida, analise a arquitetura de integração do sistema de mensagens antes de se envolver na solução do problema. Caso contrário, você poderá acabar corrigindo o problema ou componente errado. Por exemplo, um erro de Acesso Negado que o impede de criar um objeto de contato no Active Directory não significa necessariamente que você precisa corrigir as permissões de acesso do Active Directory, como veremos mais adiante.

Seja como for, é vital entender o papel de cada componente envolvido na integração do sistema de mensagens e como os componentes individuais interagem entre si. A Figura 1 mostra os componentes importantes em um cenário de conectividade do SharePoint, assunto que será abordado em detalhes nas seções a seguir.

Figura 1 Arquitetura de integração do sistema de mensagens do SharePoint (clique na imagem para ampliá-la)

Obtendo informações sobre diagnóstico

Uma das ferramentas mais importantes na solução de problemas são informações confiáveis de diagnóstico. O exemplo clássico é o log de eventos do Windows. Entre outras coisas, você pode controlar o nível de detalhes com que o SharePoint grava o log de eventos do Windows nos servidores Web usando a Administração Central do SharePoint (na página Operações, em Log e Relatório, clique em Log de Diagnóstico). Você pode especificar o evento menos crítico a ser relatado no log de eventos e no log de rastreamento. O log de rastreamento (localizado por padrão em %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs) será muito útil se você estiver pesquisando informações de baixo nível, mas pode acumular com muita rapidez, portanto, use esse recurso com parcimônia.

Outra maneira de obter informações sobre diagnóstico é habilitar a depuração para o aplicativo Web afetado, configurando o arquivo web.config correspondente, conforme descrito no Web Application Config.pdf do material complementar. O SharePoint exibe informações detalhadas sobre rastreamento diretamente na interface do usuário. Uma vantagem dessa abordagem é que você pode ver as informações de erro relevantes sem ter de analisar os megabytes dos dados de rastreamento. Uma desvantagem é que você deve alterar a configuração do sistema do seu aplicativo Web. Não se esqueça de fazer backup do arquivo web.config original e revertê-lo à configuração original depois de concluir a solução de problemas.

Também é possível configurar o serviço SMTP para gravar informações detalhadas no log do protocolo SMTP (no Gerenciador ISS, marque a caixa de seleção Habilitar o recurso de log na guia Geral). Instale o módulo Log de ODBC com o recurso Serviço SMTP conforme descrito no SharePoint Messaging Integration.pdf do material complementar, mesmo que não planeje usar o Log de ODBC. Caso contrário, o serviço SMTP não gravará o log de protocolo. Por padrão, o log do protocolo SMTP está localizado em %SystemRoot%\System32\LogFiles\SmtpSvc1. É um arquivo de texto que permite analisar a comunicação SMTP em detalhes e determinar se uma mensagem saiu do servidor SharePoint.

No servidor Transporte de Hub que se comunica com o serviço SMTP, também é possível habilitar o registro em log do protocolo na configuração Conector de Envio e Conector de Recebimento (consulte o SharePoint Messaging Integration.pdf). Você também pode usar muitas outras ferramentas para seguir o caminho que as mensagens tomam no ambiente do Exchange Server 2007 pelos servidores Transporte de Hub e Caixa de Correio, como o Controle de Mensagens, o Visualizador de Filas e o Pipeline Tracing (Rastreamento de Pipeline). Se desejar informações detalhadas sobre a solução de problemas de fluxo de emails do Exchange Server 2007, consulte o tópico "Problemas de transporte e fluxo de emails" em go.microsoft.com/fwlink/?LinkID=120145.

Nos controladores de domínio do Active Directory, é possível coletar informações detalhadas sobre a solução de problemas habilitando o registro em log de diagnóstico para o Acesso a Diretório e outras categorias por meio da definição das entradas do registro correspondentes em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Um valor de 0x0 para uma categoria significa que apenas os eventos críticos são registrados, enquanto que um valor de 0x5 significa que todos os eventos são registrados, incluindo as informações sobre depuração. O uso de um nível de registro em log maior do que 0x3 pode degradar o desempenho do servidor e rapidamente acumular o log de eventos do Windows. Durante operações normais, todos os valores devem ser definidos como 0x0.

A coleta de informações detalhadas de diagnóstico nos servidores SharePoint, Exchange e Active Directory em uma situação de solução de problemas pode ajudar a localizar um ponto problemático com rapidez e confiança. Outras ferramentas de solução de problemas, como TCP/IP (ping, tracert, telnet etc.) e o Monitor de Rede, também podem ser úteis, já que a maior parte da comunicação entre esses sistemas ocorre na rede do computador. O Microsoft® Network Monitor 3.1 está disponível em go.microsoft.com/fwlink/?LinkId=120143.

Transferência de mensagens de saída

Recursos

• Site dos Produtos e Tecnologias do SharePoint
• TechCenter do Windows SharePoint Services
• Windows SharePoint Services Developer Center
• Blog da equipe de Produtos e Tecnologias do Microsoft SharePoint

Equipado com os logs de eventos, de rastreamentos, de protocolos, de rastreamentos de mensagens e de rastreamentos de rede, estou pronto para solucionar problemas de integração do sistema de mensagens do SharePoint. Vamos começar pela parte fácil: a transferência de mensagens de saída. O SharePoint oferece suporte à transferência de mensagens de saída em diversas configurações e não requer um serviço SMTP local nos servidores Web. Entretanto, em um cenário de integração de mensagens completo, a configuração recomendada é usar o serviço SMTP local. A Figura 2 mostra os principais componentes no cenário.

Figura 2 Transferência de mensagens de saída (clique na imagem para ampliá-la)

Este cenário do sistema de mensagens inclui quatro estágios: o SharePoint deve transferir a mensagem para o serviço SMTP, o serviço SMTP deve processar a mensagem, o servidor Transporte de Hub deve receber a mensagem e o Exchange Server 2007 deve transferir a mensagem para o destino final.

Se o SharePoint não puder transferir a mensagem para o serviço SMTP, em condições normais, você receberá um erro na interface do usuário, como uma notificação de email que não pôde ser enviada. A causa pode ser que o serviço SMTP não está em execução. Ou talvez o log do protocolo SMTP diga que o serviço SMTP rejeitou a tentativa de envio com o código de erro 550 [Requested action not taken: mailbox unavailable (Não é possível executar a ação solicitada: caixa de correio não disponível)], uma indicação de que o problema está localizado no serviço SMTP.

Para verificar se não é um problema do SharePoint, você pode usar um script básico (consulte SMTP.vbs no material complementar) para enviar uma mensagem de teste pelo SMTP com as mesmas informações de remetente e destinatário. Se for um problema do serviço SMTP, o script não terá êxito. Na verdade, esse script pode lhe dar pistas importantes sobre a causa do problema, que o SharePoint infelizmente não revela mesmo com a depuração habilitada, conforme ilustrado na Figura 3.

Figura 3 Não é possível retransmitir mensagens (clique na imagem para ampliá-la)

Ao conceder as permissões de retransmissão do servidor Web na configuração do serviço SMTP e ao reiniciar esse serviço, o problema de envio de mensagens do SharePoint pode ser resolvido. Agora a mensagem chegará ao serviço SMTP, e o próximo passo importante é saber se o serviço consegue rotear a mensagem ao servidor Transporte de Hub.

Se a mensagem permanecer na pasta Queue (Fila), o serviço SMTP não conseguirá contatar o servidor Transporte de Hub. Se isso acontecer, é porque o serviço Transporte do Microsoft Exchange não está em execução ou há um problema de comunicação ou de configuração de rede. Usando o cliente Telnet, você pode verificar com rapidez e facilidade se é possível conectar à porta de destino de um Conector de Recebimento configurado para comunicação interna.

Não precisa ser necessariamente a porta 25 TCP. Na verdade, se o serviço SMTP usar essa porta, você poderá transferir as mensagens para o Conector de Recebimento padrão de servidores Transporte de Hub, que é configurado para bloquear envios de mensagens anônimas. Nesse caso, você verá um arquivo de mensagem na pasta Drop (Recebimento) (o serviço Temporizador do Windows SharePoint Services deve ser interrompido; caso contrário, a mensagem desaparecerá depois de alguns segundos). O arquivo de mensagem é uma notificação de status de entrega declarando que a mensagem foi rejeitada com "Diagnostic-code: smtp;530 5.7.1 Client was not authenticated" ("Código de diagnóstico: cliente smtp;530 5.7.1 não foi autenticado").

Para resolver esse problema, você deve criar um Conector de Recebimento para os servidores SharePoint. Como seus servidores SharePoint são sistemas internos, escolha a opção de autenticação Externally Secured (Protegido Externamente). Nesse caso, não é necessário conceder direitos estendidos à conta ANONYMOUS LOGON. Além disso, considere o uso de IPsec para proteger a comunicação entre os servidores SharePoint e o servidor Transporte de Hub.

Se as mensagens deixarem a pasta Queue do SMTP e os logs do protocolo SMTP nos servidores SharePoint e Transporte de Hub (verifique a pasta %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) indicarem uma transferência de mensagem bem-sucedida, considere o serviço concluído, pois o Exchange Server 2007 é capaz de rotear a mensagem até o destino. Como mencionado anteriormente, use as ferramentas de solução de problemas de fluxo de email incluídas no Exchange Server 2007 para investigar qualquer problema se as mensagens não chegarem aos destinatários do Exchange esperados. Observe que informações de destinatário incorretas, filtros de spam e restrições de tamanho de mensagem podem evitar uma entrega final nesse estágio.

Transferência de mensagens de entrada

Na direção oposta, a transferência de mensagens é um pouco mais complicada porque os possíveis problemas são mais sutis. Por exemplo, a documentação de produto do SharePoint recomenda configurar os registros MX no DNS para domínios de email do SharePoint, o que é uma boa maneira de desviar mensagens em uma organização do Exchange.

O Exchange Server 2007 usa Conectores de Envio com espaços de endereço associados para transferir mensagens. Ele pode rotear suas mensagens do SharePoint para servidores de Transporte de Borda ao transferir por meio da Internet mesmo que os servidores SharePoint sejam internos. Para transferência de mensagens internas, use Conectores de Envio com espaços de endereço detalhados e especifique seus servidores SharePoint executando o serviço SMTP como hosts inteligentes na configuração do conector (consulte o SharePoint Messaging Integration.pdf no download complementar). O estabelecimento de uma topologia de roteamento bem definida com servidores bridgehead dedicados ajuda a obter uma transferência de mensagens confiável do Exchange para o SharePoint.

Para verificar se as mensagens chegam aos servidores SharePoint, interrompa o serviço Temporizador do Windows SharePoint Services. As mensagens serão acumuladas na pasta Drop porque é o serviço Temporizador que processa as mensagens e coloca os anexos de arquivo nas bibliotecas de documentos associadas aos endereços de email de destinatário, conforme indicado na Figura 4. Se as mensagens não chegarem à pasta Drop, use o Visualizador de Filas no servidor Transporte de Hub para ver se o Exchange roteia as mensagens corretamente. Depois investigue os problemas de comunicação de rede que podem impedir que o Transporte de Hub se comunique com o serviço SMTP no servidor SharePoint.

Figura 4 Transferência de mensagens de entrada (clique na imagem para ampliá-la)

Ao reiniciar o serviço Temporizador, você verá os itens de mensagem desaparecerem da pasta Drop. Entretanto, se os anexos de mensagem não chegarem como documentos nas bibliotecas de destino mesmo que o SharePoint indique o processamento de mensagens bem-sucedido no log de eventos do Windows, isso significa que o Exchange enviou as mensagens no formato RTF do Exchange. Para investigar esse problema, encerre o serviço Temporizador novamente, envie outra mensagem com um anexo do seu cliente Outlook® e abra a mensagem no Bloco de Notas depois que ela chegar à pasta Drop. Agora pesquise a cadeia de caracteres "winmail.dat". Se você encontrá-la, o Exchange Server está enviando as mensagens no formato errado.

O SharePoint requer que os anexos de mensagem sejam codificados no formato MIME ou UUENCODE. Além disso, ele não mostra nenhum problema de processamento relacionado ao winmail.dat no log de eventos do Windows (consulte a Figura 5). Os anexos de arquivo simplesmente não aparecem na biblioteca de documentos. Use o Bloco de Notas como uma ferramenta de solução de problemas e elimine o problema de formatação, configurando uma definição Remote Domain (Domínio Remoto) no Console de Gerenciamento do Exchange para o domínio de email do SharePoint. Na guia Format of original message sent as attachment to journal report (Formato da mensagem original enviada como anexo para o relatório de diário), em Exchange rich-text format (Formato rich-text do Exchange), selecione Never use (Nunca usar).

Figura 5 Processamento de mensagens Winmail.dat (clique na imagem para ampliá-la)

Gerenciamento de diretório

Um dos eventos mais úteis do serviço Timer é o evento 6873, que declara que um erro ocorreu ao processar um arquivo de email de entrada por causa de um alias desconhecido. Isso acontece se um usuário do Exchange especificar um endereço de email incorreto do SharePoint ao enviar mensagens, como uma biblioteca de documentos inexistente.

Você pode minimizar esse problema configurando o Serviço de Gerenciamento de Diretório nas configurações de Email de Entrada da Administração Central do SharePoint a fim de criar objetos de destinatário para bibliotecas de documentos habilitadas para email no Active Directory. Os usuários do Exchange poderão, então, selecionar, conforme conveniente, esses objetos de destinatário com as informações de endereço corretas no catálogo de endereços.

No entanto, saiba que agora você estará entrando em um novo território de solução de problemas. O Serviço de Gerenciamento de Diretório falha em uma configuração de proteção do sistema baseada no princípio de privilégios mínimos porque esse recurso possui requisitos de permissão elevada no servidor Web. Além disso, a documentação do produto (como technet.microsoft.com/library/cc262947.aspx) exagera a situação quando sugere que você deve conceder à conta do pool de aplicativos Administração Central o direito "Criar, excluir e gerenciar contas de usuário" na UO especificada para os objetos de destinatário do SharePoint no Active Directory.

O Serviço de Gerenciamento de Diretório cria objetos de contato e de grupo e, por isso, a conta do pool de aplicativos Administração Central requer controle total sobre esses objetos na UO mas não requer permissões administrativas para as contas de usuário. Se você configurar o Serviço de Gerenciamento de Diretório em uma Web farm conforme descrito e tentar habilitar emails em uma biblioteca de documentos, é bastante provável que obtenha um erro de "Acesso negado".

As informações de erro indicam problemas de permissão do Active Directory, e os administradores do SharePoint não hesitam em atribuir controle total para Todos na UO do SharePoint. Entretanto, além de reduzir a segurança do Active Directory, essa medida não resolve o problema.

Uma solução de problemas estruturada requer que você localize o ponto problemático primeiro e depois aplique as alterações de configuração planejadas. Se seguir essa abordagem, verificar o log de eventos do Windows no controlador de domínio e rastrear a comunicação de rede usando o Monitor de Rede, talvez descubra que o SharePoint não acessa o Active Directory quando o problema ocorre. Portanto, é improvável que as alterações na configuração do Active Directory corrijam o problema. Ele está ocorrendo no servidor SharePoint.

Infelizmente, é extremamente difícil obter mais informações úteis sobre o problema da permissão. O SharePoint não registra nenhuma informação adicional no log de eventos do Windows. Contudo, se habilitar a depuração do SharePoint, você verá a pilha de chamadas (como mostra a Figura 6), que sugere que o Serviço de Gerenciamento de Diretório usa o método CreateContact de um serviço Web do SharePoint. O SDK do SharePoint dirá que esse é o Email Integration Web Service (Serviço Web de Integração de Email) (<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx).

Figura 6 Saída de depuração

Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall) 
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters) 
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags) 
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias) 
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) 
   at Microsoft.SharePoint.SPList.Update() 
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args) 
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e) 
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) 
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument) 
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)

Vejamos o SharepointEmailWS.asmx em um navegador da Web para obter a lista de operações com suporte. É possível ver o método CreateContact, e um clique no link CreateContact revela as mensagens SOAP que você deve enviar a esse serviço Web se quiser criar um contato no Active Directory. Isso é ótimo porque agora você pode criar uma ferramenta de solução de problemas baseada em script (consulte SharepointEmailWS.vbs no material complementar) para trabalhar fora da interface do usuário do SharePoint, o que torna mais fácil especificar contas de usuário diferentes durante as execuções de teste. A Figura 7 mostra as informações retornadas se você executar esse script na conta do pool de aplicativos Administração Central (à esquerda) e na conta Administrador do SharePoint (à direita).

Figura 7 Dois erros diferentes de "Acesso negado" (clique na imagem para ampliá-la)

As mensagens de erro são diferentes! As duas mensagens declaram que o acesso é negado, mas o erro à esquerda indica um problema de processamento e o erro à direita não indica. Então, qual é a diferença entre as contas do pool de aplicativos e a conta Administrador do SharePoint?

A conta Administrador do SharePoint é um Administrador local no servidor SharePoint, enquanto que as contas do pool de aplicativos não são. O problema pode ser resolvido adicionando as contas do pool de aplicativos do seu aplicativo Web ao grupo Administradores locais e reiniciando o servidor Web, mas isso não é novidade. Considero inaceitável a ação de executar as contas do pool de aplicativos com privilégios administrativos em servidores Web de produção.

Por que uma conta do pool de aplicativos requer essas permissões elevadas? Novamente, o script pode revelar a resposta. Se conceder a todos os usuários permissões de Administrador local no seu servidor Web para fins de teste, você descobrirá que as contas do pool de aplicativos podem usar o Email Integration Web Service enquanto o acesso permanece negado para todas as outras contas, inclusive administradores do SharePoint. Isso significa que o Email Integration Web Service usa a configuração de pool de aplicativos como base para decisões de controle de acesso.

A configuração do pool de aplicativos faz parte da metabase IIS (ou do arquivo applicationHost.config no IIS 7.0), e o acesso à metabase é restrito aos Administradores locais por padrão. Felizmente, é possível conceder acesso de contas que não seja de administrador à metabase usando o Metabase Explorer (Gerenciador de Metabase) incluído nas ferramentas do IIS 6.0 Resource Kit. No IIS 7.0, é ainda mais fácil conceder controle total ao arquivo applicationHost.config; basta executar os seguintes comandos:

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config" 
/G "<application pool account>" :F /E iisreset /noforce

Além disso, para criar objetos de contato no Active Directory, o pool de aplicativos Administração Central requer controle total sobre os objetos de contato e de grupo na UO de destino. E as contas do pool de aplicativos Web requerem acesso total à metabase nos servidores SharePoint da Web farm. Agora você está pronto para criar objetos de contato usando a interface do usuário do SharePoint.

Mas, espere; tem mais! Criar objetos de destinatário no Active Directory é apenas uma parte da história de integração de diretório. A outra parte é gerar atributos de destinatário relacionados ao Exchange e atualizar os catálogos de endereço baseados no servidor. Por exemplo, se atualizar a lista de endereços global no servidor Exchange usando o comando do Shell de Gerenciamento do Exchange Update-GlobalAddressList "Default Global Address List", você poderá encontrar os objetos de destinatário recentemente criados para as bibliotecas de documentos do SharePoint no catálogo de endereços do Outlook. Mas o ato de enviar mensagens para esses destinatários gera relatórios de falha de entrega por causa de informações de endereço incorretas, conforme ilustrado na Figura 8.

Figura 8 Mensagem que não pode ser entregue a uma biblioteca de documentos (clique na imagem para ampliá-la)

O acrônimo IMCEAEX significa Internet Mail Connector Encapsulated Address for Exchange (Endereço encapsulado do conector de email da Internet para o Exchange). Ele indica um endereço de destinatário que não é do Exchange encapsulado em um formato que o antigo Internet Mail Connector do Exchange é capaz de manipular. Mas, atualmente, estamos lidando com o Exchange Server 2007 e Conectores de Envio baseados em SMTP nativos.

A questão é que o Email Integration Web Service do SharePoint não grava os atributos de endereço que o Exchange Server 2007 requer para a transferência de mensagens. Ele apenas grava os atributos específicos de nome, sobrenome, nome de exibição e endereço de destino (e, opcionalmente, ms-ExchRequireAuthToSendTo). No entanto, ele não define o apelido de email, os endereços de proxy ou Exchange DN herdados, e não associa o objeto de destinatário a uma diretiva de destinatário do Exchange.

Para resolver o problema, use o cdmlet Get-Mailbox no Shell de Gerenciamento do Exchange a fim de obter todos os objetos de destinatário com um endereço de destino que aponte para o domínio de email do SharePoint. E faça um pipe da saída para o cdmlet Set-MailContact a fim de ativar as diretivas de destinatário do Exchange, conforme se segue:

Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True

Se preferir, use o Console de Gerenciamento do Exchange e marque a caixa de seleção "Atualizar automaticamente endereços de email com base em diretiva de endereço de email" nas propriedades do objeto de contato.

O WSS 3.0 e o MOSS 2007 já vêm com suporte à integração total do sistema de mensagens para habilitar alertas e notificações, fluxos de trabalho e envio de documentos baseados em email. Embora não seja uma tarefa fácil configurar os sistemas corretamente, a integração de mensagens pode aumentar a produtividade de trabalho. Especificamente, você deve verificar se a transferência de mensagens de entrada e de saída funcionam corretamente. Você também deve garantir que a integração de diretórios funcione.

As mensagens de erro do SharePoint nem sempre são intuitivas ou informativas. Entretanto, mostrei maneiras de chegar à origem dos problemas de integração, localizar as causas e eliminá-las de forma confiável, sem comprometer a segurança dos servidores SharePoint.

Pav Cherny é especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada. Entre suas publicações estão white papers, manuais de produto e livros com foco nas operações de TI e na administração do sistema. Pav é presidente da Biblioso Corporation, empresa especializada em serviços de documentação gerenciada e de localização.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida.