Problemas para saber sobre durante a consolidação de site a um site baseado em Exchange Server 2003 Service Pack 1

Traduções deste artigo Traduções deste artigo
ID do artigo: 841659 - Exibir os produtos aos quais esse artigo se aplica.
Este artigo foi arquivado. É oferecido "como está" e não será mais atualizado.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

depois de instalar o Microsoft Exchange Server 2003 Service Pack 1 em um site central, você pode iniciar a consolidação de site para mover os computadores Exchange Server de locais remotos para o site central. Alguns problemas podem ocorrer durante a consolidação de site. Antes de começar a consolidação de site, todos os conectores ADC (Active Directory) na floresta deve ser atualizado para a versão do ADC que está incluída no Exchange Server 2003 Service Pack 1.

Além disso, é recomendável ter certeza de que você configure corretamente a agenda de replicação Connector do Exchange Server 5.5 Directory entre o site remoto e o site central onde os objetos serão movidos. O comportamento do Exchange Server 2003 Active Directory Connector e seu efeito no seu site enquanto ele estiver sendo executado depende muitas variáveis de cada rede.

Depois de pasta pública cross-site move, depois move cross--grupo administrativo e depois que você re-home objetos, um número de problemas podem ocorrer. Para ajudar na preparação para uma mudança de cross-site, é uma boa idéia que você compreenda o comportamento e os problemas descritos neste artigo.

INTRODUÇÃO

Consolidação de site é o processo de consolidação de sites remotos em um site grande, central ou em vários sites grandes. Depois de um site central foi implantado e clientes começaram a executar o Outlook 2003, o administrador pode começar a consolidar o conteúdo de sites remotos. Consolidação de site serão consolidados o conteúdo principal, as pastas públicas, as caixas de correio e os objetos de diretório. Consolidação de site também consolida serviços, como o catálogo de endereços offline ou conectores externos ao site central. Este artigo descreve os problemas conhecidos que podem ocorrer durante a consolidação de site. Este artigo também explica o que pode causar os problemas. Este artigo descreve soluções alternativas e soluções. As informações é fornecidas para ajudar você a compreender os problemas que podem ocorrer. Além disso, as informações são fornecidas para concluir a consolidação de site.

Instalar o conector do Active Directory para Exchange Server 2003 Service Pack 1

O Active Directory Connector (ADC) no Microsoft Exchange Server 2003 Service Pack 1 é um pré-requisito para consolidação de site. A interface de gráfica do usuário (GUI) do Exchange System Manager no Exchange Server 2003 Service Pack 1 não permite move cross-site para ocorrer até que todos os ADCs na floresta tenham sido atualizados para Exchange Server 2003 Service Pack 1.

Atualizar agenda de replicação Connector do Exchange Server 5.5 Directory (opcional)

Durante move cross-site, muitas alterações de diretório podem ocorrer. Recomendamos que o administrador analise a agenda de replicação Connector do Exchange Server 5.5 Directory entre o site remoto e o site central onde os objetos serão movidos. Para certificar-se de que a duplicação de fluxo de alterações rapidamente a partir do site central de volta para o site remoto que está sendo consolidado, o administrador talvez queira fazer o seguinte:
  • Verifique se o conector de replicação do Exchange Server 5.5 é definido diretamente entre o site remoto e o site central.
  • Certifique-se que o mesmo servidor no site central é usado pelo conector de replicação e altera o bridgehead de replicação que o ADC está configurado para replicar o serviço de diretório do Active Directory de.
  • Verifique se que a agenda de replicação do Exchange Server 5.5 está definida para sempre ou intervalos curtos.
Essas alterações são opcionais, mas eles são altamente recomendável. Se a replicação de diretório ou replicação ADC estiver atrasada, o processo de limpeza automatizada depois move cross-site pode demorar mais.

Comportamento de ADC

Comportamento de ADC antes da transferência

Antes que uma movimentação de cross--grupo administrativo de uma pasta pública seja concluída, o ADC conclui vários estágios do comportamento de limpeza de mover cross--grupo administrativo. Entrega de mensagem será afetada até que a limpeza de cross--grupo administrativo mover ADC seja concluída.

O tempo para concluir o comportamento de limpeza do ADC depende de seu ambiente, sobre a replicação entre os sites do Exchange Server 5.5 e na replicação do Active Directory para Exchange Server 5.5.

Por exemplo, a limpeza das listas de distribuição e a exclusão do objeto stub executar cada 12 horas. A limpeza das listas de distribuição e a exclusão do objeto de stub são concluídas ao mesmo tempo. Em ambientes menores, esses podem ser concluídos no ciclo de limpeza de um ou de 12 horas. Em ambientes maiores, isso podem levar dois ou mais ciclos de limpeza e eles podem levar mais de 24 horas para concluir. Limpeza de listas de distribuição e a exclusão do objeto stub podem demorar em um ambiente maior devido a seguir:
  • O tempo para replicar do Active Directory para Exchange Server 5.5
  • Duplicação entre sites no Exchange Server 5.5.
A limpeza mais rápida, clique a licença de conexão com o botão direito do mouse e clique em Duplicar agora . No entanto, a velocidade ainda é limitada pelo seguinte:
  • O tempo para replicar do Active Directory para Exchange Server 5.5.
  • Duplicação entre sites no Exchange Server 5.5.


Mover de comportamento do ADC para Exchange Server 5.5 vinculados e objetos do Active Directory durante um grupo administrativo de cruz

O objeto de stub Exchange Server 5.5 e o objeto do Active Directory são desvinculados durante uma movimentação de cross-site. A Public Folder realojar Tool (PFMigrate) usa o novo sinalizador NM_MOVED_CROSS_SITE nos nomes de ADC global para atribuir um valor nomes ADC global diferente aos dois objetos. O ADC não vincula esses dois objetos juntos. Portanto, o objeto de fragmento de código pode ser excluído no final da limpeza sem excluir o objeto do Active Directory.

O ADC suprime a replicação do objeto de stub Exchange Server 5.5 volta para o Active Directory porque ADC GlobalNames são removidos e re-stamped com um valor diferente. Se o ADC não suprimir a replicação, o objeto de diretório de pasta pública deve ser replicado volta para o Active Directory e o resultado seria objetos duplicados. Além disso, se o ADCGlobalNames não tem replicados para todos os controladores de domínio, o usuário pode estar vinculado volta ao objeto do Active Directory. Carimbos PFMigrate ADCDoNotReplicate como um endereço de proxy X.500 na pasta pública. O carimbo ADCDoNotReplicate informa o ADC não para replicar este objeto volta para o Active Directory. O bit de cross-site não pode ser usado para interromper esse comportamento porque ADC GlobalNames não replica inter site. Portanto, os contratos de conexão que duplicar as alterações que são originadas de um site não-local não seriam consulte cross-site bit e ainda seria replicar exclusões e atualizações.

Comportamento de limpeza de ADC

atualizar grupos de distribuição
No Exchange Server 5.5, o objeto de pasta pública do Exchange Server 5.5 antigo deve ser removido da lista de distribuição e a pasta pública movida deve ser atualizada na lista de distribuição do Active Directory.

Objetos de domínio são um dos objetos mais básicos no Active Directory. Todos os outros objetos são subordinados a objetos de domínio. O nome distinto (DN) de um objeto de domínio é composto dos componentes de domínio (dc) do nome DNS do domínio. Por exemplo, o objeto do domínio microsoft.com tem um DN do dc = microsoft, dc = com. Objectclass que é usado para este objeto é domainDNS e o objectcategory é DomainDNS.

Como os membros da lista de distribuição é baseado em DN e a associação não é alterado durante o grupo cross-administrativo mover de uma pasta pública, Active Directory tem a associação correta da pasta pública. ADC usa o comando ADCGlobalNames para consultar a participação no grupo e DN links quando ele replica para Exchange Server 5.5. ADC pode atualizar o Exchange Server 5.5 listas de distribuição forçar a replicação do grupo do Active Directory. No entanto, pode haver latência entre sites do Exchange Server 5.5. Portanto, quando a lista de distribuição é atualizada em um site, ele não tenha o novo objeto e só pode ter conhecimento sobre o objeto de pasta pública de stub. Para contornar esse problema, o ADC conclui DN link pesquisas para permitir o vínculo de volta a objetos do antigos se o novo objeto não puder ser encontrado quando o diretório do Exchange Server 5.5 é pesquisado.

Se a pasta pública do Exchange Server 5.5 antiga foram excluída e não foram deixada como uma pasta pública stub até após a limpeza da lista de distribuição, a pasta pública deve ser removida de suas listas de distribuição e a pasta pública deve perder sua participação de lista de distribuição. Isso pode ocorrer se as listas de distribuição replicado volta para o Active Directory e removido o usuário de suas listas de distribuição. No entanto, porque a pasta pública de stub é mantida, deve haver um processo que limpa, essas listas de distribuição para que o recém-movido pasta pública objeto é adicionado às suas listas de distribuição em Exchange Server 5.5 sites e para que, eventualmente, o objeto de pasta pública de stub pode ser removido. Esse comportamento pode ocorrer em uma das duas maneiras a seguir:
  • O processo PFMigrate toca todas as listas de distribuição na pasta pública movida pertence no Active Directory. Portanto, o Active Directory duplicará a associação correta ao Exchange Server 5.5. O atributo ObjectVersion replicado é atualizado no Active Directory.
  • Se as listas de distribuição não estiverem no site de destino, o ADC pode automaticamente forçar a replicação de todas as listas de distribuição na pasta pública ao qual pertence. PFMigrate apresenta todos os cross--grupo administrativo pastas públicas movidas com o X 500: ADCDeleteWhenUnlinked valor proxy e aparência de distribuição lista membros. ADC procura por objetos com o endereço de proxy X 500: ADCDeleteWhenUnlinked para forçar a replicação. Se o grupo de distribuição estiver no site local, ele será tocar o grupo no Active Directory que possui a associação correta com a nova pasta pública no novo site para forçar a replicação para Exchange Server 5.5. Esse comportamento foi adicionado para a fase ADC tem para limpeza de diretório resolver links de DN não resolvidos. Esse comportamento é executada a cada 12 horas.



Removendo objetos de fragmento de código no site original do Exchange Server 5.5


O X 500: ADCDeleteWhenUnlinked valor proxy é marcada em um objeto pela PFMigrate processo para indicar que o objeto deve ser excluído quando o atributo MemberOf está vazio. Isso significa que o objeto não pertence a qualquer grupos de distribuição devido ao comportamento lista de distribuição atualizado é abordado anteriormente. Isso também foi adicionado para a fase que tem o ADC para limpeza de diretório resolver links de DN não resolvidos.

O Outlook Web Access e o Outlook o status de leitura/não lido

Quando uma pasta pública é movida para um servidor diferente durante cross-site move de pastas públicas, o status de leitura e não lido de mensagens na pasta pública é perdido. Esse comportamento ocorre porque a leitura e o status não lidas não são replicados entre servidores. Portanto, quando um usuário usa o Outlook Web Access, ou quando o Outlook acessa uma pasta pública que tenha sido movida cross-site, todas as mensagens serão exibidas como não lidas. Esse comportamento também ocorre quando você move réplicas de pastas públicas dentro do site. Esse comportamento não é específico para move cross-site.

Acesso a um público a pasta que tenha sido movida cross-site

O seguinte comportamento pode ocorrer:
  • Poderá ser negado acesso a uma pasta pública movido temporariamente.
  • Você não pode ser redirecionado para a casa nova da pasta pública.
  • Não todo o conteúdo pode estar em nova pasta pública.
Esse comportamento pode ocorrer por uma das seguintes razões:
  • Se a lista de réplicas não é atualizada no servidor ?s o usuário que acessa o cross-site movido pasta pública, o usuário é direcionado para a réplica antiga até que a lista de réplica é atualizada. Se a réplica antiga é excluída, o usuário não receberá acesso à pasta pública. Lista de réplicas é esperada que ser atualizados em cinco minutos de movimentação cross-site. No entanto, se a lista de réplica não pode ser replicada antes que a réplica de pasta pública é excluída, os usuários não terá acesso à pasta pública até que a lista de réplica é atualizada.
  • O usuário pode conectar-se para o novo site para acessar sua pasta pública antes de todo o conteúdo é replicado para o novo site.


Afinidade da pasta pública

Acesso às pastas públicas pode não ser concluída se afinidade da pasta pública não for definida para o novo site. Esse comportamento ocorre porque afinidade deve ser configurada para o novo site ? doméstico ? da pasta pública antes da movimentação de cross-site de pasta pública. Esse comportamento também ocorre quando você move réplicas de pastas públicas e não é específico para move cross-site.

Afinidade da pasta pública é a capacidade de um programa cliente para exibir um servidor em outro site e para acessar uma pasta pública. Isso é feito em vez de replicar essa pasta para o site local. Afinidade da pasta pública costuma ser usada se existe uma conexão de largura de banda alta.

Observação Afinidade da pasta pública não é necessária se a orientação para fornecer réplicas em sites de origem e destino durante a caixa de correio mover etapas é seguida. Afinidade será necessária se pastas públicas são movidas no total antes ou depois move a caixa de correio.

Problemas conhecidos: comportamento depois move de pasta pública cross-site

Efeitos sobre usuários do Exchange Server 5.5 e os usuários do Exchange Server 2003 quando mensagens de email são enviadas para pastas públicas

Problemas de entrega de mensagem podem ocorrer quando os usuários enviam mover emails para uma pasta pública durante um grupo administrativo de cruz e enquanto o ADC está limpando os objetos de diretório do Exchange Server 5.5.

Observação Durante a movimentação de cross-site, os usuários podem receber um não-delivery report (NDR) que contém o seguinte erro:
acesso negado 0 x 80070005




regras da caixa de entrada


Regras que movem as mensagens para e de pastas públicas que são baseadas em pasta ID (FID) não funcionará após pastas públicas que foram movidas entre grupos administrativos. Você pode receber uma mensagem semelhante à seguinte:
Não é possível localizar a pasta de destino




movido pastas públicas na lista de endereços global


Pastas públicas que são movidas entre grupos administrativos poderão desaparecer da lista de endereços global no Exchange Server 5.5. Esse comportamento pode ocorrer se o objeto original do Exchange Server 5.5 no site antigo é oculto antes do Exchange Server 5.5 novo objeto é replicado para o novo site do Active Directory. -Administrativa entre pastas públicas movidas não são afetadas no Active Directory, a lista de endereços global do Exchange 2000 Server ou lista de endereços global do Exchange Server 2003.



armazenamento no diário


Diário não funcionará se uma pasta pública que é usada para Exchange Server 5.5 ou Exchange 2000 Server diário for movidos cross-administrative groups. Esse problema ocorre porque o atributo LegacyExchangeDN é alterado.

Observação Diário para uma pasta pública no Exchange 2000 e no Exchange Server 2003 não tem suporte e pode causar problemas de funcionalidade e desempenho no seu ambiente Exchange. Quando você reconfigurar diário depois cross-site mover, altere seu diário de destino de uma caixa de correio em vez de uma pasta pública.



formulários organizacionais


Formulários organizacionais não são movidos entre sites pelo script PFMigrate. Formulários organizacionais fazem parte das pastas do sistema e administradores devem atualizar manualmente a lista de réplica de pasta pública para esta e outras pastas do sistema.


programas de terceiros com base em pastas públicas


Programas de terceiros que são baseados em uma pasta pública e o atributo LegacyExchangeDN da pasta pública podem não funcionar após uma pasta pública é movida entre sites.

endereços de proxy
Pastas públicas manterão seus endereços de proxy original do seu site antigo. Além disso, pastas públicas não obterá novo proxy endereços de que está sendo movido grupo administrativo de cruz, mesmo se a diretiva de destinatário for baseada em membros do grupo administrativo.

O serviço de atualização de destinatário não será carimbar proxies atualizados se a pasta pública já proxies desse tipo. Para receber um novo endereço de proxy para uma diretiva de destinatário que se aplicariam agora para o usuário com base na nova participação em grupos administrativos, clique em Aplicar agora na diretiva de destinatário e, em seguida, recriar o serviço de atualização de destinatário. Recomendamos que você não fizer isso menos que seja necessário como isso pode afetar o desempenho da rede.

Embora endereços de proxy não são atualizados, fluxo de mensagens de email não será afetado. No entanto, se seu sistema estiver executando alguns verificação de restrição muito específica, você pode enfrentar um problema se os endereços não forem atualizados. Por exemplo, considere o seguinte cenário:
  • AG1 aceita mensagens de email para domain1.com.
  • AG2 aceita mensagens de email para domain2.com.
  • O conector que conecta dois grupos administrativos não permite que qualquer pessoa fora da organização para enviar emails por ele.
  • Portanto, as mensagens de email geraria um NDR. As mensagens de email não irão ser enviadas entre o conector.




executar o Directory Service/Information Store consistency adjuster opção ? realocar ?


Após mover uma entre sites de uma pasta pública, é recomendável que você não executar o Directory Service/Information Store (DS / IS) ajustador de consistência com o recurso sincronizado com o diretório e redefinir o valor de base do servidor ativado até que a replicação de diretório todo seja concluída. Recomendamos que você nunca execute o DS / IS consistency adjuster a menos que seja necessário. Você deve aguardar até que move de cross-site de pasta pública forem concluídas antes de executar o DS / IS consistency adjuster.
Se você executa o DS / IS consistency adjuster logo após cross-site move de pastas públicas, ele pode realocar suas pastas públicas em um site diferente do site de destino especificado pelo PFMigrate. Esse comportamento pode ocorrer se as seguintes condições forem verdadeiras:
  • Execute PFMigrate para adicionar réplicas de pastas públicas para todas as pastas públicas em um site a um servidor de destino em um novo site.
  • Execute PFMigrate exclua todas as réplicas de pastas públicas de todos os servidores no site de origem.
  • Um administrador executa o DS / IS consistency adjuster antes homed atributos sejam replicadas novamente do Active Directory para o diretório do Exchange Server 5.5.
No entanto, após o Active Directory replica com o Exchange Server 5.5, não há nenhum risco na execução do DS / IS consistency adjuster.

Solucionando problemas de comportamento após entre a caixa de correio do grupo administrativo move

Efeitos sobre usuários do Exchange Server 5.5 e os usuários do Exchange Server 2003

Há um número de problemas de entrega de mensagem durante uma movimentação do grupo administrativo de cruz e enquanto o ADC está limpando os objetos de diretório do Exchange Server 5.5. Para se preparar para esse comportamento, é recomendável que você entenda totalmente os possíveis problemas.

Problemas de fluxo de email

Por um curto período de tempo depois da caixa de correio é movida, mensagens podem acabar em fila para servidores que estão em um site diferente, como se os servidores estão no site local. Isso ocorre porque o agente de transferência de mensagem (MTA) não entende como um usuário pode mover entre sites. Portanto, o MTA faz algumas suposições incorretas após o bloco PR_IN_TRANSIT é lançado.

Tenta entregar as mensagens é feita através de procedimentos armazenados remotos (RPC). Essas tentativas falham se apenas um X 400 conector conecta os sites e se eles não compartilham o mesmo contexto de segurança (a mesma conta de serviço). Você também pode receber mensagens de erro semelhantes à seguinte no servidor Exchange 5.5:



Tipo de evento: aviso
Origem do evento: MSExchangeMTA
Categoria do evento: interface
IDENTIFICAÇÃO de evento: 9318
Usuário: N/d
Computador: Exchange5.5ServerName
Descrição: Erro de comunicação de RPC ao. Não é possível ligar via RPC. Índice de tabela (LTAB) localidade: 6, código de erro NT/MTA: 1753. Erro de Comms 1753, erro de ligação 0, Remote Server Name ExchangeServerName [BASE principal 1 500 % 10] (14)



A solução alternativa para esse problema é criar um conector de site entre os sites temporariamente. Isso permite uma conexão RPC direta ser feitas entre os servidores em questão. Esta conexão permite que mensagens sejam entregues. Após a movimentação de caixa de correio cross-site foi concluída e o MTA tiver identificado corretamente o roteamento correto para o usuário, você não terá esse problema.



regras da caixa de entrada


Se você tiver qualquer cliente ou servidor lado caixa de entrada regras que sejam baseiam em um usuário e seus LegacyExchangeDN Exchange, as regras será interrompidas quando você move cross-administrative groups usuários, porque o LegacyExchangeDN de um usuário altera. No entanto, as regras da caixa de entrada não são interrompidas se o usuário reside em um Exchange Server 2003 Service Pack 1 ou posterior com base em servidor. As regras da caixa de entrada funcionam no Exchange Server 2003 Service Pack 1 após um grupo administrativo de cruz mover porque alterações para o armazenamento de caixa de correio permitem regras para trabalho mesmo quando muda o LegacyExchangeDN de um usuário. Em vez de usar o atributo LegacyExchangeDN, o adicional X.500-endereço de proxy que foi adicionado durante a movimentação do grupo cross-administrativo pode ser usado durante a regra de processamento nos servidores Exchange 2003 Service Pack 1.

Se o usuário não está hospedado no Exchange Server 2003 Service Pack 1, suas regras de caixa de entrada que são baseadas em um grupo administrativo de cruz movido pessoa deve ser recriada.



usuários movidos na GAL
Usuários que são movidos grupo administrativo de cruz poderão desaparecer da lista de endereços global no Exchange Server 5.5 por um curto período de tempo enquanto o objeto original do Exchange Server 5.5 no site antigo está oculto e antes do Exchange Server 5.5 novo objeto foi replicado para o novo site do Active Directory. Grupo administrativo entre movido os usuários são afetados no Active Directory, Exchange 2000 Server e lista de endereços global do Exchange Server 2003.

endereços de proxy


Os usuários manterão seus endereços de proxy original do seu site antigo. No entanto, os usuários não obterá novo proxy endereços de que está sendo movido grupo administrativo de cruz, mesmo se a diretiva de destinatário for baseada em membros do grupo administrativo.

O serviço de atualização de destinatário não será carimbar proxies atualizados se o usuário já tiver proxies desse tipo. Para receber um novo endereço de proxy para uma diretiva de destinatário que se aplicariam agora para o usuário com base na nova participação em grupos administrativos, clique em Aplicar agora na diretiva de destinatário e, em seguida, recriar o serviço de atualização de destinatário. Recomendamos que você não fizer isso menos que seja necessário como isso pode afetar o desempenho da rede.

Embora endereços de proxy não são atualizados, fluxo de mensagens de email não será afetado. No entanto, se seu sistema estiver executando alguns verificação de restrição muito específica, você pode enfrentar um problema se os endereços não forem atualizados. Por exemplo, considere o seguinte cenário:
  • AG1 aceita mensagens de email para domain1.com.
  • AG2 aceita mensagens de email para domain2.com.
  • Conector conectando dois grupos administrativos não permite que qualquer pessoa fora da organização para enviar email pela-lo.
  • Portanto, a mensagem de email gera um NDR. E, a mensagem de email não será enviada através do conector.

processo de logon do Outlook Web Access


Na implementação de um front-end/back-end, usuários podem acessar suas caixas de correio pelo Outlook Web Access (OWA) inserindo um logon explícito ou um logon implícita . A URL para um logon explícito Especifica o servidor e caixa de correio que o usuário deseja acessar e assume a forma: http:// servername /exchange/ username, onde servername é o nome da tanto o OWA front-end ou back-end do servidor e username é o nome da conta do Microsoft Windows do usuário. Quando um usuário usa um logon para logon para Outlook Web Access (OWA) explícita, o logon pode não funcionar. Esse problema ocorre porque, quando um usuário é movido cruzada administrativas grupo, o diretório virtual HTTP que o usuário usa para alterações do Outlook Web Access (OWA). O diretório virtual HTTP que o usuário usa para o Outlook Web Access (OWA) altera porque o servidor de back-end de caixa de correio de Exchange do usuário é alterado. O erro de logon ocorrerá se o endereço SMTP no novo diretório virtual HTTP não é um endereço SMTP que o usuário tem.

Observação Os diretórios virtuais do Exchange Outlook Web Access padrão são difíceis de todos os codificados para usar a diretiva de destinatário padrão e o endereço SMTP na diretiva. Você só pode usar diferentes diretivas de destinatários que possuem diferentes endereços SMTP se você criar um novo diretório virtual.

Esse problema é provável de ocorrer em um dos dois cenários a seguir:
  • Cenário um: Se o site de origem for um site puro do Exchange Server 5.5 onde cada site tem um endereço SMTP diferente, e a caixa de correio atual tem um endereço SMTP no Exchange Server 5.5 que não corresponde ao padrão Exchange endereço SMTP no servidor Exchange Server 2003 Service Pack 1 do diretório virtual. Quando o usuário é movido do Exchange Server 5.5 para Exchange Server 2003, quando o usuário tenta usar um logon explícito com o Outlook Web Access para efetuar logon no servidor do Exchange Server 2003 Service Pack 1, eles não é possível fazer logon.
  • Cenário dois: em um misto puro Exchange 2000 Server/Exchange Server 2003 ambiente ou, se o usuário atualmente estiver usando um diretório virtual dedicado, que é criado pelo administrador e não é o diretório virtual padrão, para o Outlook Web Access. O diretório virtual dedicado usa um endereço SMTP de uma diretiva de destinatário que também fornece endereços de SMTP são usados por caixas de correio na organização do Exchange. Isso significa que o SMTP endereços correspondência. Quando o usuário é movido para o novo site, elas são movidas para um novo servidor de caixa de correio do Exchange que esteja configurado para usar o diretório virtual do Exchange Outlook Web Access padrão. Este diretório virtual do Exchange padrão usa a diretiva de destinatário padrão e possui um endereço SMTP diferente que o usuário não tem. Portanto, quando o usuário é movido do Exchange Server 5.5 para Exchange Server 2003, quando o usuário tenta usar um logon explícito no Outlook Web Access para efetuar logon no servidor do Exchange Server 2003 Service Pack 1, eles não é possível logon.
Para solucionar os problemas em um cenário e cenário dois, use um dos seguintes soluções:
  • Crie um diretório virtual dedicado no novo site para o novo servidor de caixa de correio local para onde o usuário é movido. Aponte o novo diretório virtual dedicado para uma diretiva de destinatário que tem o endereço SMTP que o usuário tem.
  • Em um misto de sites ou cenário de 2000 puro do Exchange Server, adicione o endereço SMTP da diretiva de destinatário padrão a diretiva de destinatário que se aplica ao usuário movido. Depois do RUS foi atualizado, o usuário terá um proxy SMTP adicional que agora coincide com o diretório virtual padrão.
  • Adicionar manualmente o endereço de SMTP correto para o usuário movido
Exchange Server 2003 Service Pack 1 inclui uma correção que torna possível usar o endereço SMTP em logons implícitos ou explícitos logons para contornar esse problema. O Outlook Web Access sempre funcionará nas seguintes situações quando você se conecta a um servidor baseado no Exchange Server 2003 Service Pack 1:
  • logon implícita
    Por exemplo, digite o URL para acesso do OWA no seguinte formato:
    http:// Server / exchange
  • logon explícito usando o nome de usuário principal (UPN) ou o endereço SMTP
    Por exemplo, digite o URL para acesso do OWA no seguinte formato:
    http:// server servidor/exchange/usuário @ Domain_Name. com

Quando você tenta usar um logon explícito usando o alias do usuário e o usuário não tem o endereço SMTP do diretório virtual HTTP, o logon não será concluído. Por exemplo, se você digitar o URL para acesso do OWA no seguinte formato: http:// Server /exchange/ User, você não irá acessar a caixa de correio do servidor Exchange. Esse problema ocorre sempre que um logon explícito usando o alias de um usuário for usado para o OWA e não é específico para cenários de grupo administrativo de cruz.



informações de disponibilidade e caixas de correio de recursos


Informações de disponibilidade devem ser re-published após mover uma caixa de correio cross-site. Para caixas de correio do usuário, isso ocorrerá 15 minutos após o usuário usa o Outlook para fazer logon para o servidor do Exchange e o usuário executa uma ação de calendário. Por exemplo, se o usuário aprova, remove ou cria uma solicitação de reunião, as informações de disponibilidade do calendário for republicadas 15 minutos mais tarde.

O proprietário da caixa de correio recurso, por exemplo uma sala de reunião, abra a caixa de correio e executar uma ação de calendário a publique novamente as informações de disponibilidade.

Esse comportamento ocorre porque não haverá uma mensagem de informações de disponibilidade para novo atributo o usuário ?s LegacyExchangeDN no site de destino, mas o Outlook não publicará uma atualização até que uma alteração de calendário é feita e o cache de informações de disponibilidade ? local ? Outlook é dirtied. Esse comportamento também ocorre se você executar através do processo GUIDGen para redefinir pastas de sistema do site.

Ou, a ferramenta UpdateFB pode ser usada para automatizar essa disponibilidade a republicação do processo.

Para obter informações adicionais sobre a ferramenta UpdateFB, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
294282Como usar o Updatefb.exe para republicar ausente dados de disponibilidade


Catálogo de endereços offline

download do catálogo de endereços off-line e sites remotos
Quando um usuário executa o Outlook 2003 no modo de cache em sites remotos com o Exchange Server 2003 ou uma versão anterior, eles devem verificar se eles têm largura de banda suficiente para oferecer suporte a um download completo do catálogo de endereços offline para todos os clientes nesse site remoto.



sites remotos em vínculos lentos


Quando caixas de correio que usar o Outlook 2003 no modo de cache são movidas de um servidor remoto Exchange Server 5.5 para um servidor Exchange 2003 SP1 central em sites ou não, um catálogo de endereços offline completo deve ser baixado. Além disso, quando há uma alteração significativa para o diretório, ou quando um novo grupo de administração é adicionado ou removido, um download completo do offline catálogo de endereços será gerado para os usuários de modo em cache. Portanto, sites remotos devem certificar-se de que haja largura de banda suficiente para oferecer suporte a um catálogo de endereços offline completo para todos os clientes no site remoto.



obter informações adicionais sobre o catálogo de endereços offline completo downloads


Normalmente, Os clientes do Outlook verá apenas uma comparação de catálogo de endereços offline baixar. Esse é um pequeno subconjunto do download do catálogo de endereços offline completo que contenha apenas alterações em vez da lista de endereços global completo. No entanto, há casos onde os clientes Outlook terão para baixar o catálogo de endereços offline completo. Se o diretório tiver um número significativo de alterações, por exemplo, muitas novas contas, as alterações de nome e muito mais, ou um novo grupo de administração Exchange é adicionado ou removido, todos os clientes que estiver no modo em cache serão atualizados com um catálogo de endereços offline completo. Além disso, os clientes que são movidos do Exchange Server 5.5 para um novo servidor do Exchange Server 2003 também receberá um novo total catálogo de endereços offline.

Para obter informações adicionais sobre como limitar o efeito de OAB completo downloads no Exchange Server 2003, clique no seguinte número de artigo para ler o artigo na Base de dados de Conhecimento da Microsoft:
867623Downloads de catálogo de endereços offline completo a otimização para limitar o efeito em uma rede local no Exchange Server 2003


Aguarde até que as atualizações de diretório

Os administradores terão esperar por atualizações de diretório para ocorrer antes que as mensagens de email podem fluir sem criar um relatório de não-entrega (NDR).

Problemas conhecidos: comportamento após realocar de objeto

Entrega de mensagem será afetada no Exchange Server 5.5 e Exchange Server 2003 para os usuários a listas de contato e distribuição de endereçamento

Se os usuários enviar emails para contatos e listas de distribuição durante um grupo administrativo de cruz mover e durante o ADC limpar os objetos de diretório do Exchange Server 5.5, há um número de problemas de entrega de mensagem que podem ocorrer.

regras da caixa de entrada


Quando o lista/grupo de distribuição é re-homed durante um grupo administrativo de cruz mova, regras de caixa de entrada que processar mensagens com base na lista de distribuição como remetente ou destinatário não funcionará para caixas de correio que são hospedadas em servidores do Exchange anteriores ao Exchange Server 2003 Service Pack 1. Essas regras devem ser recriadas ou as caixas de correio com a regra devem ser movidas para um servidor que está executando o Exchange 2003 SP1.



movido pastas públicas na lista de endereços global


Quando uma lista de contato/distribuição é movida, ele poderão desaparecer da lista de endereços global no Exchange Server 5.5 durante o tempo que o objeto original do Exchange Server 5.5 no site antigo está oculta e antes do Exchange Server 5.5 novo objeto foi replicado para o novo site do Active Directory. Re-homed objetos no Active Directory, a lista de endereços global do Exchange 2000 Server ou lista de endereços global do Exchange Server 2003 não são afetados.



endereços de proxy


Objetos que são re-homed manterão seus endereços de proxy original do seu site antigo. No entanto, eles não terá novos endereços de proxy quando movido grupo administrativo de cruz, mesmo se a diretiva de destinatário for baseada em membros do grupo administrativo.

O serviço de atualização de destinatário não carimbar proxies atualizados no objeto se o objeto re-homed já tiver o mesmo tipo de proxies. Para receber um novo endereço de proxy para uma diretiva de destinatário que se aplicariam agora para o objeto com base na nova participação em grupos administrativos, clique em Aplicar agora na diretiva de destinatário e, em seguida, recriar o serviço de atualização de destinatário. Recomendamos que você não fizer isso menos que seja necessário como isso pode afetar o desempenho da rede.
Embora endereços de proxy não são atualizados, o fluxo de mensagens não será afetado. No entanto, se seu sistema estiver executando alguns verificação de restrição muito específica, você pode enfrentar um problema se os endereços não forem atualizados. Por exemplo, considere o seguinte cenário:
  • AG1 aceita mensagens de email para domain1.com.
  • AG2 aceita mensagens de email para domain2.com.
  • O conector que conecta dois grupos administrativos não permite que qualquer pessoa fora da organização para enviar emails por ele.
  • Portanto, a mensagem de email geraria um NDR. A mensagem de email não será enviada entre o conector.


X.500 endereços são substituídos por ADC inter-organizational nos contatos são movidos cross-site


Considere este cenário. Uma licença de conexão inter-organizational (CA) cria um contato em uma organização. O contato representa caixas de correio em outra organização. Se o contato for movido cross-site, o nome de diretório original do contato do site de origem é marcado para o contato movido na forma de um endereço X.500. No entanto, se a caixa de correio que representa o contato for alterada, a alteração é duplicada para o objeto contato movido, e o ADC substituirá o endereço X.500.

Para contornar esse problema, use um ou mais dos seguintes procedimentos:
  • Reconfigurar o ADC para um novo site e, em seguida, executar a ferramenta perder todos os endereços X.500.
  • Exportar o LegacyExchangeDNs do Exchange Server 5.5 antes da movimentação de cross-site e importe o LegacyExchangeDNs como endereços X.500 em caixas de correio do Exchange Server 5.5.
  • Alterne para modo nativo do Exchange e não mover os contatos.


Aguarde até que o ADC para concluir


Você deve aguardar para o Active Directory para Exchange Server 5.5 replicação, duplicação intra-sites e duplicação entre sites para concluir. O fluxo de mensagens e outras operações serão afetadas até que os diretórios do Exchange Server 5.5 são sincronizados e o ADC foi executado para corrigir as alterações.

executa o Directory Service/Information Store consistency adjuster


Depois de uma distribuição de lista que é concedida acesso a uma pasta pública é movida cross-site, você deve executar o patch Directory Service/Information Store (DS / IS) Ferramenta de ajustador de consistência para se certificar que a lista de distribuição está ainda poderão acessar a pasta pública.

Referências

Para obter informações adicionais, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
836489Uma atualização é necessária para consolidação de modo misto site com o Exchange Server 5.5
843107Como usar a ferramenta pfMigrate para realizar uma operação de movimentação cross-site pasta pública no Exchange Server 2003 Service Pack 1

Propriedades

ID do artigo: 841659 - Última revisão: sábado, 26 de outubro de 2013 - Revisão: 3.2
A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 2003 Service Pack 1
Palavras-chave: 
kbnosurvey kbarchive kbmt kbinfo kbexchange2003sp1fix KB841659 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 841659

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com