Por: Alessandro Gonçalves

Nessa última semana tivemos alguns incidentes de suporte onde serviços do Exchange 2007 não inicializavam após a aplicação do Rollup , tanto o RU5 ou RU3 post-SP1.

Um dos serviços afetados é o Microsoft Exchange Mail Submission , e o seguinte evento é adicionado ao SYSTEM LOG:

Log Name:      System
Source:        Service Control Manager
Date:          7/18/2008 4:13:06 PM
Event ID:      7000
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Ex2k7-MBX
Description:
The Microsoft Exchange Mail Submission service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.

Essa comportamento foi revelado após a adoção dos updates rollup do Exchange , onde foram inseridos dois certificados para assinar o managed code dos serviços do Exchange. Foi lançado um artigo de suporte kb944752 , o qual apresenta a solução e alguns workarounds. Todavia a solução definitiva não está clara .

O motivo deste blog é colocar que nem sempre o workaround indicado no arquivo irá funcionar , e o método correto para corrigir o problema é seguir o artigo kb936707 , onde está indicado um hotfix para o .NET Framework 2.0 o qual adiciona o configuration setting generatePublisherEvidence e se faz necessário editar / criar configuration files para os serviços do Exchange 2007 que utilizam managed code. Para tal verifique o serviço que está falhando , nesse caso o Microsoft Mail Submission e edite o arquivo referente ao mesmo, MSExchangeMailSubmission.exe.config, e adicione o parâmetro generatePublisherEvidence na parte configuration. O resultado final será algo assim:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

Para servidores Exchange 2007 instalados em Windows Server 2008 , necessitamos apenas editar / criar os arquivos de configuração , já que o setting generatePublisherEvidence está presente em todos .NET framework após 3.0 .

Aqui está uma lista dos serviços que podem ser afetados pelo comportamento de timeout. Todos esses serviços apresentam arquivos com extensão .config.

Bin\EdgeTransport.exe
Bin\ExBPA.exe
Bin\ExBPACmd.exe
Bin\ExTRA.exe.
Bin\Microsoft.Exchange.Cluster.ReplayService.exe
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
Bin\Microsoft.Exchange.Monitoring.exe
Bin\Microsoft.Exchange.Search.ExSearch.exe
Bin\Microsoft.Exchange.ServiceHost.exe
Bin\MSExchangeMailboxAssistants.exe
Bin\MSExchangeMailSubmission.exe
Bin\MSExchangeTransportLogSearch.exe
ClientAccess\PopImap\Microsoft.Exchange.Imap4.Exe
ClientAccess\PopImap\Microsoft.Exchange.Pop3.Exe

Os seguintes serviços não possuem arquivos exe.config por padrão , mas se apresentarem o mesmo comportamente necessitaremos criá-los e adicionar toda a secção de configuration.

Bin\Microsoft.Exchange.AntispamUpdateSvc.exe
Bin\MsExchangeFDS.exe
Bin\MSExchangeTransport.exe

Estou apresentando isso porque em alguns casos , o aumento do Timeout no SCM - Service Control Manager - não resolveu o problema.

Servidores com maiores possibilidades de serem afetados são os que estão isolados - sem acesso a Internet - ou com restrição de acesso no proxy ou firewall.

Estou colocando links que podem melhor ajudar a explicar essa situação:

Bypassing the Authenticode Signature Check on Startup
Authenticode and Assemblies

E para os iniciados em PowerShell , aqui vai um link com um blog com um script para automatizar a mudança. Ainda não o testei , mas como todo o script não nos responsabilizamos pelo resultado.

O script foi escrito por Guillaume Bordier e está publicado no blog.

Obrigado pela atenção.