P&R do Administrador do Exchange: assuntos freqüentemente mal compreendidos - Parte 2

  • Artigo

Publicado em: 1 de fevereiro de 2006

By Nino Bilic

Este artigo explica alguns dos assuntos mal compreendidos relacionados ao Microsoft® Exchange Server.

  • Executar /domainprep redefine as permissões na organização do Exchange?

  • Observar os destinatários no SRS realmente mostra o conteúdo do banco de dados do SRS?

  • A contagem de reparos mostra quantas vezes o banco de dados foi reparado?

  • O que ocorre quando o log circular é habilitado no Exchange Server 2003 ou no Exchange 2000 Server?

  • Quando o Serviço de Atualização de Destinatário remove endereços de usuários?

    • Razão para remoção de endereço 1: Bug do Gerenciador de Sistema do Exchange

    • Razão para remoção de endereço 2: Limpar o endereço primário e aplicar a política

    • Razão para remoção de endereço 3: Remover o último endereço do tipo de endereço específico e aplicar a política

  • Para obter mais informações

Executar /domainprep redefine as permissões na organização do Exchange?

É um conceito errôneo acreditar que a execução de /domainprep do Exchange 2000 Server redefine as permissões na organização do Exchange. Para fazer isso, é necessário executar a instalação completa do Exchange 2000 Server, em vez de /domainprep do Exchange. É possível obter o mesmo resultado executando a instalação do service pack no Exchange 2000 Server. Para obter instruções, consulte o artigo 320007 da Base de Dados de Conhecimento Microsoft, "XADM: Permissions That Are Modified Manually Are Reset to the Default Values" (em inglês).

No Exchange Server 2003, a instalação apresenta as permissões na organização do Exchange somente uma vez, apenas durante a instalação inicial. Outras instalações não redefinirão manualmente as permissões alteradas, como fez a instalação do Exchange 2000 Server. Executar a instalação novamente no Exchange Server 2003 não ajudará a resolver os problemas com permissões.

Observar os destinatários no SRS realmente mostra o conteúdo do banco de dados do SRS?

Abrir o administrador do Exchange, conectar-se ao SRS (Serviço de replicação de site) e, em seguida, verificar os destinatários não são etapas suficientes para testar se a replicação foi bem-sucedida a partir de um servidor executando o Exchange Server versão 5.5. Esse teste não mostra a você o conteúdo real dos destinatários no SRS.

No Exchange Server 5.5, o conteúdo do painel direito quando os destinatários são exibidos é preenchido com o uso da chamada MAPI. O SRS não possui mais essa funcionalidade de MAPI. Portanto, ao exibir os destinatários do SRS utilizando o administrador do Exchange, você verá os destinatários como estão no Active Directory, em vez de ver o que está no SRS no diretório do Exchange Server 5.5.

Para obter uma visão real daquilo que foi replicado para o SRS a partir do Exchange Server 5.5 através da replicação de diretório, é necessário executar uma exportação de diretórios do SRS para um arquivo .csv. Como alternativa, você pode executar o Ldp.exe para consultar o banco de dados do SRS e verificar os destinatários. Esse método mostrará a verdadeira lista de destinatários no SRS.

A contagem de reparos mostra quantas vezes o banco de dados foi reparado?

Ao despejar o cabeçalho do banco de dados, um dos campos que você verá é Repair Count. Não é verdade que o campo Repair Count mostra quantas vezes o banco de dados foi reparado. Na verdade, esse campo mostra quantos reparos foram feitos no banco de dados somente durante o último reparo. O código de exemplo a seguir mostra a área do banco de dados à qual isso se refere. Observe principalmente a linha:

     Repair Count: 0

FakePre-e19685a69899444c8ba3a6863a2af67f-548e49cbfb5a454aa6dc5212cba183c1

O que ocorre quando o log circular é habilitado no Exchange Server 2003 ou no Exchange 2000 Server?

É pouco conhecido o fato de que, quando o administrador do Exchange habilita o log circular no Exchange Server 2003 ou no Exchange 2000 Server, todas as transações do arquivo .stm não estão sendo registradas nos logs de transações. Portanto, com o log circular ativado, o Exchange Server 2003 e o Exchange 2000 Server ficam mais vulneráveis no caso de uma falha do servidor, se caixas de correio estiverem envolvidas. Algumas informações que deveriam ter sido confirmadas no arquivo .stm podem ser permanentemente perdidas no caso de falta de energia.

Quando o Serviço de Atualização de Destinatário remove endereços de usuários?

As seções a seguir explicam quando o Serviço de Atualização de Destinatário deve remover os endereços dos usuários.

Razão para remoção de endereço 1: Bug do Gerenciador de Sistema do Exchange

Antes do Exchange 2000 Server Service Pack 1 (SP1), havia um bug no Gerenciador de Sistema do Exchange que poderia fazer com que o Serviço de Atualização de Destinatário removesse todos os endereços de um tipo específico se um dos endereços desse tipo não estivesse selecionado na política de destinatário. Esse bug foi corrigido no Exchange 2000 Server SP1. Agora, o Serviço de Atualização de Destinatário não remove todos os endereços de um tipo específico se um dos endereços desse tipo não tiver sido selecionado na política de destinatário. Por exemplo, antes do Exchange 2000 Server SP1:

Recipient policy:    X   SMTP:  @domain1.com
                     X   SMTP:  @domain2.com

Se

@domain2.com

não fosse selecionado e a política de destinatário fosse aplicada, o Serviço de Atualização de Destinatário removeria todos os endereços SMTP (Simple Mail Transfer Protocol) do usuário, neste caso FakePre-b90a8f45dea342c8a98d14a4dfb8f02b-b16cc34531c34a71b5e6b5fd56d5e5b2 e FakePre-80c56e514d0743d294d68ce4a147af70-2474c995a2184bf0acdd73df3094bad5. Observe que isso também ocorre quando o endereço que não foi selecionado não é o endereço primário. Para obter mais informações, consulte o artigo 291842 da Base de Dados de Conhecimento Microsoft, "XIMS: SMTP Proxy Addresses Are Deleted for All Users" (em inglês)

Esse problema poderá ocorrer se você instalar o Gerenciador de Sistema do Exchange em seus computadores cliente para administrar servidores e se não aplicar os service packs nesses computadores. Nesse caso, utilizar o Gerenciador de Sistema do Exchange a partir de um computador cliente em um servidor executando o Exchange 2000 Server Service Pack 3 (SP3) causaria esse problema.

Razão para remoção de endereço 2: Limpar o endereço primário e aplicar a política

Suponhamos que haja uma política com dois endereços SMTP:

Recipient policy:    X  SMTP:   @domain1.com
                     X  X400:     c=US;a= ;p=Orgname;o=AGname

O @domain1.com é um endereço primário para o tipo de endereço específico.

Se você limpar a caixa de seleção de um endereço primário em uma política e aplicar a política, todos os endereços desse tipo serão removidos. Ao limpar a caixa de seleção de um endereço em uma política, o Serviço de Atualização de Destinatário não solicita a aplicação da política. Se você não aplicar a política, todos os endereços desse tipo não serão removidos. No entanto, se aplicar a política posteriormente, os endereços serão removidos posteriormente.

Razão para remoção de endereço 3: Remover o último endereço do tipo de endereço específico e aplicar a política

Suponhamos que haja uma política com dois tipos de endereços:

Recipient policy:    X  SMTP:   @domain1.com
                     X  X400:     c=US;a= ;p=Orgname;o=AGname

Observe que há somente um endereço do tipo SMTP. Agora, se o tipo de endereço SMTP for removido da política e, em seguida, a alteração for aplicada, os endereços do tipo SMTP serão removidos dos usuários aos quais essa política se aplica com base no filtro. Se você não aplicar a alteração, a aplicação manual posterior da política não removerá o tipo de endereço. Se quiser remover o tipo de endereço posteriormente, será necessário criar o mesmo tipo de endereço na política, selecioná-lo, removê-lo e, em seguida, aplicar a alteração.

Para obter mais informações

Para obter mais informações, consulte o seguinte recurso do Exchange Server e os artigos da Base de Dados de Conhecimento Microsoft: