Problèmes à connaître lors du site consolidation à un site Exchange Server 2003 Service Pack 1

Traductions disponibles Traductions disponibles
Numéro d'article: 841659 - Voir les produits auxquels s'applique cet article
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Agrandir tout | Réduire tout

Sommaire

Résumé

Après avoir installé Microsoft Exchange Server 2003 Service Pack 1 dans un site central, vous pouvez lancer la consolidation de site pour déplacer les ordinateurs Exchange Server des sites distants sur le site central. Certains problèmes peuvent se produire lors de la consolidation site. Avant de commencer à consolidation de site, tout Active Directory connecteurs (ADC) dans la forêt doit être mis à niveau vers la version de Connecteur Active Directory est fournie avec Exchange 2003 Service Pack 1.

De plus, il est recommandé de vérifier que vous configurer correctement la planification du connecteur de réplication Exchange Server 5.5 Directory entre le site distant et le site central où les objets va être déplacés. Le comportement d'Exchange Server 2003 connecteur Active Directory et son effet sur votre site alors qu'elle est en cours d'exécution dépend des plusieurs variables de chaque réseau.

Une fois intersite des dossiers publics, une fois inter-administrative-groupe et une fois que vous avez re-home objets, un certain nombre de problèmes peuvent survenir.
Pour aider à préparer pour un déplacement entre sites, il est judicieux de comprendre le comportement et les problèmes décrits dans cet article.

INTRODUCTION

Consolidation de site est le processus de consolidation des sites distants dans un site central, ou dans plusieurs grands sites. Après un site central a été déployé et clients ont commencé à exécuter Outlook 2003, l'administrateur peut commencer à consolider contenu à partir des sites distants. Consolidation de site est consolidés le contenu principal, les dossiers publics les boîtes aux lettres et les objets d'annuaire. Consolidation de site regroupe également les services tels que le Carnet d'adresses en mode hors connexion ou des connecteurs étrangers vers le site central. Cet article décrit les problèmes connus qui peuvent se produire pendant la consolidation de site. Cet article explique également ce qui peut provoquer les problèmes. Cet article décrit solutions et les résolutions. Les informations permettant de vous aider à comprendre les problèmes qui peuvent se produire. En outre, les informations sont fournies pour vous aider à accomplir consolidation de site.

Installer le Connecteur Active Directory Exchange Server 2003 Service Pack 1

L'Active Directory Connector (ADC) dans Microsoft Exchange Server 2003 Service Pack 1 est une condition préalable pour la consolidation de site. L'interface utilisateur graphique le Gestionnaire système Exchange dans Exchange Server 2003 Service Pack 1 n'autorise pas passe intersite au lieu tant que tous les ADC dans la forêt ont été mis à niveau vers Exchange 2003 Service Pack 1.

Planification du connecteur de réplication Exchange Server 5.5 Directory (facultative) de mise à jour

Plusieurs modifications d'annuaire peuvent se produire lors de déplacements intersite. Nous recommandons de prendre l'administrateur en compte la planification du connecteur de réplication Exchange Server 5.5 Directory entre le site distant et le site central où les objets va être déplacés. Pour vous assurer que la réplication du flux de modifications rapidement à partir du site central au site distant sur lequel consolidé, l'administrateur pouvez souhaiter effectuer les opérations suivantes :
  • Assurez-vous que le connecteur de réplication Exchange Server 5.5 est défini directement entre le site distant et le site central.
  • Assurez-vous que le même serveur dans le site central est utilisé par le connecteur de réplication et que le pont de réplication que le connecteur Active Directory est configuré pour répliquer le service d'annuaire Active Directory passe de.
  • Assurez-vous que la planification de réplication Exchange Server 5.5 est définie à toujours ou à intervalles court.
Ces modifications sont facultatives, mais ils sont fortement recommandés. Si la réplication d'annuaire ou par réplication ADC est retardée, le processus de nettoyage automatique après passe intersite peut prendre plus de temps.

Comportement du connecteur Active Directory

Comportement de connecteur Active Directory avant le déplacement

Avant un administrative-groupe de déplacement entre d'un dossier public, le connecteur Active Directory effectue plusieurs étapes de comportement de nettoyage d'administration-groupe de déplacement entre. Remise du message sera affectée avant que le nettoyage d'administration-groupe de déplacement entre connecteur Active Directory soit terminé.

Le temps nécessaire au comportement de nettoyage du connecteur Active Directory dépend de votre environnement, sur la réplication entre vos sites Exchange Server 5.5 et sur la réplication d'Active Directory vers Exchange Server 5.5.

Par exemple, le nettoyage des listes de distribution et la suppression de l'objet stub exécuter toutes les 12 heures. Le nettoyage des listes de distribution et la suppression de l'objet stub sont complétées en même temps. Dans les environnements plus petits, il peuvent être effectuée dans le cycle un nettoyage ou 12 heures. Dans les environnements plus, ces peuvent prendre deux ou plusieurs cycles de nettoyage et peut prendre plus proche de 24 heures pour terminer. Nettoyage des listes de distribution et la suppression de l'objet stub peuvent prendre plus de temps dans un environnement plus grand en raison des opérations suivantes :
  • Le temps de réplication à partir d'Active Directory vers Exchange Server 5.5
  • Inter-site réplication dans Exchange Server 5.5.
Pour le nettoyage plus rapide, cliquez avec le bouton droit sur l'accord de connexion, puis cliquez sur Répliquer maintenant . Toutefois, la vitesse est toujours limitée par suivantes :
  • Heure pour répliquer à partir d'Active Directory dans Exchange Server 5.5.
  • Inter-site réplication dans Exchange Server 5.5.


Déplacer du comportement de connecteur Active Directory pour Exchange Server 5.5 lié et objets Active Directory au cours d'un groupe inter-d'administration

L'objet stub Exchange Server 5.5 et l'objet Active Directory sont non liées au cours d'un déplacement intersites. L'outil de dossiers publics récupérer (PFMigrate) utilise du nouvel indicateur NM_MOVED_CROSS_SITE dans les noms globaux ADC pour affecter une autre valeur noms globaux ADC aux deux objets. Le connecteur Active Directory ne pas lier ces deux objets. Par conséquent, l'objet stub peut être supprimé à la fin du nettoyage sans supprimer l'objet Active Directory.

Le connecteur Active Directory supprime la réplication de l'objet stub Exchange Server 5.5 revenir à l'annuaire Active Directory car le GlobalNames connecteur Active Directory sont supprimés et re-stamped avec une valeur différente. Si le connecteur Active Directory n'a pas supprimer la réplication, l'objet répertoire dossiers publics s'être répliqué retour vers Active Directory, et le résultat serait les objets dupliqués. En outre, si le ADCGlobalNames n'a pas été répliquées sur tous les contrôleurs de domaine, l'utilisateur peut-être être lié revenir à l'objet Active Directory. PFMigrate assigne ADCDoNotReplicate d'une adresse proxy X.500 dans le dossier public. Le tampon ADCDoNotReplicate indique le connecteur ADC ne pas pour répliquer cet objet revenir à Active Directory. Le bit intersite ne peut pas être utilisé pour arrêter ce problème, car la GlobalNames ADC ne réplique pas inter site. Par conséquent, les accords de connexion qui répliquent les modifications que l'origine d'un site non local ne serait pas voir le intersite bits et est toujours répliquer les suppressions et mises à jour.

Comportement de nettoyage du connecteur Active Directory

mise à jour des groupes de distribution
Dans Exchange Server 5.5, l'ancien objet de dossiers publics Exchange Server 5.5 doit être supprimé de la liste de distribution et le dossier public a été déplacé doit être mis à jour de la liste de distribution à partir d'Active Directory.

Objets du domaine sont une des objets de plus simples dans Active Directory. Tous les autres objets sont subordonnés à des objets du domaine. Le nom unique (DN) d'un objet de domaine est constitué les composants de domaine (dc) du nom DNS du domaine. Par exemple, objet le domaine microsoft.com possède un nom unique du dc = microsoft, dc = com. L'objectClass qui est utilisé pour cet objet est domainDNS et l'objectCategory est DomainDNS.

Parce que la appartenance à une liste de distribution est basé sur nom de domaine et l'appartenance ne change pas pendant le groupe inter-administrative déplacer d'un dossier public, Active Directory a l'appartenance correct au dossier public. Connecteur Active Directory utilise la commande ADCGlobalNames pour rechercher l'appartenance à un groupe et les liens nom de domaine lorsqu'il réplique vers Exchange Server 5.5. Connecteur Active Directory peut mettre à jour l'Exchange Server 5.5 listes de distribution en forcer la réplication du groupe Active Directory. Toutefois, il peut être la latence entre les sites Exchange Server 5.5. Par conséquent, lorsque la liste de distribution est mis à jour dans un site, il n'est peut-être le nouvel objet pas et peut uniquement avoir connaissance de l'objet de stub de dossiers publics. Pour contourner ce problème, le connecteur Active Directory effectue des recherches de lien nom de domaine pour permettre la liaison revenir à des anciens objets si le nouvel objet est introuvable lors de la recherche de l'annuaire Exchange Server 5.5.

Si l'ancien dossier public Exchange Server 5.5 ont été supprimé et ont été pas laissé dans un dossier public stub jusqu'à ce qu'après le nettoyage de liste de distribution, le dossier public est supprimé dans leurs listes de distribution et le dossier public perdait ses l'appartenance à une liste de distribution. Cela peut se produire si les listes de distribution répliqué en vers Active Directory et supprimé de l'utilisateur de leurs listes de distribution. Toutefois, parce que le dossier public talon est conservé, il doit être un processus qui nettoie ces listes de distribution afin que l'objet récemment déplacé dossier public est ajouté à ses listes de distribution dans Exchange Server 5.5 sites, et que par la suite l'objet de dossiers publics stub peut être supprimé. Ce problème peut se produire dans une des deux manières suivantes :
  • Le processus de PFMigrate touche toutes les listes de distribution auxquelles appartient le dossier public a été déplacé dans Active Directory. Par conséquent, Active Directory réplique les membres corrects vers Exchange Server 5.5. L'attribut ObjectVersion répliqué est mis à jour dans Active Directory.
  • Si les listes de distribution ne sont pas dans le site cible, le connecteur Active Directory peut automatiquement forcer la réplication des toutes les listes de distribution auquel appartient le dossier public. PFMigrate assigne tous les inter-administrative-groupe déplacés dossiers publics avec la X500 : ADCDeleteWhenUnlinked valeur de proxy et présente des distribution la liste membres. Recherche de connecteur Active Directory des objets avec une adresse proxy de X500 : ADCDeleteWhenUnlinked pour forcer la réplication. Si le groupe de distribution se trouve dans le site local, elle va toucher du groupe dans Active Directory qui possède l'appartenance correct avec le nouveau dossier public dans le nouveau site pour forcer la réplication vers Exchange Server 5.5. Ce problème a été ajouté à la phase de connecteur Active Directory a pour le nettoyage du répertoire résoudre les liens de nom de domaine n'ont pas été résolus. Ce comportement s'exécute toutes les 12 heures.



Suppression des objets de talon dans le site Exchange Server 5.5 d'origine


Le X500 : ADCDeleteWhenUnlinked valeur de proxy est tamponnée sur un objet par le PFMigrate processus pour indiquer que l'objet doit être supprimé lorsque son attribut de membres est vide. Cela signifie que l'objet n'appartient à aucun groupe de distribution en raison du comportement liste de distribution de mises à jour décrite précédemment. Il a été également ajouté à la phase contenant le connecteur Active Directory pour le nettoyage du répertoire résoudre les liens de nom de domaine n'ont pas été résolus.

État de lecture/non lu Outlook Web Access et Outlook

Lorsqu'un dossier public est déplacé vers un autre serveur pendant intersite déplace des dossiers publics, l'état de lecture et non lu de messages dans le dossier public est perdue. Ce problème se produit parce que la lecture et l'état non lu n'est pas répliqué entre les serveurs. Par conséquent, lorsqu'un utilisateur utilise Outlook Web Access, ou lorsque Outlook accède à un dossier public qui a été déplacé entre sites, tous les messages s'affichent comme non lus. Ce problème se produit également lorsque vous déplacez les réplicas de dossiers publics dans le site. Ce comportement n'est pas spécifique à intersite se déplace.

Accès à un public le dossier qui a été déplacé intersite

Le problème suivant peut se produire :
  • L'accès à un dossier public a été déplacé peut être refusé temporairement.
  • Vous ne pouvez pas être redirigés vers la nouvelle maison du dossier public.
  • Pas tous le contenu peut être dans le nouveau dossier public.
Ce problème peut se produire pour des deux raisons suivantes :
  • Si la liste de réplicas n'est pas mis à jour sur serveur ?s l'utilisateur qui accède à la intersite déplacé dossier public, l'utilisateur est dirigé vers le réplica ancien jusqu'à ce que la liste de réplicas est mis à jour. Si le réplica ancien est supprimé, l'utilisateur reçoit pas l'accès au dossier public. La liste de réplicas doit être mis à jour dans les cinq minutes du déplacement entre sites. Toutefois, si la liste de réplicas ne peut pas être répliquée avant la suppression le réplica de dossiers publics, les utilisateurs ne devrez pas accès au dossier public jusqu'à ce que la liste de réplicas est mis à jour.
  • L'utilisateur peut se connecter au nouveau site d'accès leur dossier public avant tout le contenu est répliqué vers le nouveau site.


L'affinité du dossier public

Accès aux dossiers publics ne peuvent pas terminée si l'affinité du dossier public n'est pas défini au nouveau site. Ce problème se produit car l'affinité doit être configurée du nouveau site ? domestique ? du dossier public avant le déplacement d'intersites de dossiers publics. Ce problème se produit également lorsque vous déplacer des réplicas de dossiers publics et êtes pas spécifique à intersite se déplace.

L'affinité du dossier public est la possibilité d'un programme client pour afficher un serveur sur un autre site et accéder à un dossier public. Cette opération est effectuée au lieu de réplication de ce dossier sur le site local. L'affinité du dossier public est utilisé si une connexion large bande passante existe.

note L'affinité du dossier public n'est pas nécessaire si les instructions pour fournir des réplicas de sites des source et cible au cours de la boîte aux lettres déplacement étapes sont suivie. Affinité sera nécessaire si les dossiers publics sont déplacés dans total avant ou après déplacer des boîtes aux lettres.

Problèmes connus : comportement après que le dossier public intersite déplacé

Effets sur les utilisateurs Exchange Server 5.5 et les utilisateurs Exchange Server 2003 lorsque des messages électroniques sont envoyés aux dossiers publics

Problèmes de remise de message peuvent se produire lorsque les utilisateurs envoient déplacement des messages électroniques vers un dossier public au cours d'un groupe inter-d'administration et pendant que le connecteur Active Directory nettoie les objets d'annuaire Exchange Server 5.5.

note Lors du déplacement intersite, les utilisateurs peuvent recevoir un rapport de non-remise (NDR) contient l'erreur suivante :
Accès refusé 0 x 80070005




règles de boîte de réception


Règles qui déplacent des messages à et de dossiers publics basés sur le dossier code FID ne fonctionneront pas après que les dossiers publics ont été déplacés entre des groupes d'administration. Un message semblable au suivant peut s'afficher :
Impossible de trouver le dossier de destination




transféré les dossiers publics dans la liste d'adresses globale


Dossiers publics qui sont déplacées entre des groupes d'administration peuvent disparaître de la liste d'adresses globale dans Exchange Server 5.5. Ce problème peut se produire si l'objet Exchange Server 5.5 d'origine dans le site ancien est masqué avant de la nouvelle 5.5 Server Exchange objet est répliqué vers le nouveau site à partir d'Active Directory. Déplacé les d'administration des dossiers publics ne sont pas affectés dans Active Directory, la liste d'adresses globale Exchange 2000 Server ou la Exchange Server 2003 liste d'adresses globale.



la journalisation


La journalisation ne fonctionnera pas si un dossier public qui est utilisé pour Exchange Server 5.5 ou Exchange 2000 Server journalisation est déplacés groupes inter-d'administration. Ce problème se produit car l'attribut LegacyExchangeDN est modifié.

note La journalisation dans un dossier public dans Exchange 2000 et Exchange Server 2003 n'est pas prise en charge, ce qui peut provoquer des problèmes des fonctionnalités et les performances dans votre environnement Exchange. Lorsque vous reconfigurez la journalisation après que le intersite déplacé, modifiez votre la journalisation pour cibler une boîte aux lettres au lieu d'un dossier public.



formulaires de l'organisation


Formulaires de l'organisation ne sont pas déplacées intersite par le script PFMigrate. Formulaires de l'organisation font partie les dossiers système et les administrateurs doivent mettre manuellement à jour la liste de réplicas du dossier public pour cette et les autres dossiers système.


les programmes tiers basés sur les dossiers publics


Programmes tiers qui dépendent d'un dossier public et l'attribut LegacyExchangeDN de ce dossier public peuvent ne pas fonctionner après le déplacée d'un dossier public entre sites.

adresses proxy
Dossiers publics conserveront leurs adresses de proxy d'origine à partir de leur site ancien. En outre, les dossiers publics économisez pas proxy nouvel adresses d'être déplacé groupe inter-administratif, même si la stratégie de destinataire est basée sur l'appartenance au groupe d'administration.

Le service de mise à jour destinataire ne marque pas les proxys mis à jour si le dossier public possède déjà des proxys de ce type. Pour recevoir une nouvelle adresse proxy pour une stratégie de destinataire qui appliquerait maintenant à l'utilisateur basé sur l'appartenance d'administration nouveau, cliquez sur Appliquer maintenant sur la stratégie de destinataire, puis recréez le service de mise à jour de destinataire. Nous vous recommandons que vous n'effectuez pas cette opération que s'il est nécessaire car cela peut affecter les performances de votre réseau.

Bien que les adresses proxy ne sont pas mis à jour, flux de messages électroniques n'est pas affecté. Toutefois, si votre système est d'effectuer une vérification des restrictions très spécifiques, vous pouvez rencontrer un problème si les adresses ne sont pas mis à jour. Par exemple, envisagez le scénario suivant :
  • AG1 accepte les messages électroniques de domain1.com.
  • AG2 accepte les messages électroniques de domain2.com.
  • Le lien qui relie les deux groupes d'administration ne permet pas tout le monde d'extérieur de l'organisation pour envoyer des messages sur elle.
  • Par conséquent, les messages électroniques génère un rapport de non-remise (NDR). Les messages électroniques ne sont pas envoyés sur le lien.




Exécution le vérificateur de cohérence Directory service/banque d'informations ? rapatrier ? option


Après qu'un inter-site déplacé d'un dossier public, il est préférable que vous n'exécutez pas la Directory service/banque d'informations (service D'ANNUAIRE/is) le vérificateur de cohérence avec la fonctionnalité synchronisé avec l'annuaire et rétablir la valeur de serveur domestique activé jusqu'à ce que tous les réplication d'annuaire ait achevé. Nous vous recommandons que vous ne jamais exécutez le cohérence SA/BI, sauf s'il s'agit requis. Vous devez attendre que dossiers publics entre sites passe est terminées avant d'exécuter le service D'ANNUAIRE cohérence SA/BI.
Si vous exécutez la cohérence SA/BI peu après que intersite déplace des dossiers publics, il peut rapatrier vos dossiers publics sur un site autre que le site cible spécifié par PFMigrate. Ce problème peut se produire si les conditions suivantes sont remplies :
  • Vous exécutez PFMigrate pour ajouter des réplicas de dossiers publics pour tous les dossiers publics dans un site à un serveur cible sur un nouveau site.
  • Vous exécutez PFMigrate pour supprimer tous les réplicas de dossiers publics de tous les serveurs du site source.
  • L'administrateur exécute le service D'ANNUAIRE cohérence SA/BI avant que les attributs d'hébergement ont répliqués en dans Active Directory vers l'annuaire Exchange Server 5.5.
Toutefois, une fois que Active Directory réplique avec Exchange Server 5.5, il n'existe aucun risque d'exécuter le service D'ANNUAIRE de cohérence SA/BI.

Dépannage de comportement après entre boîtes aux lettres du groupe d'administration déplace

Effets sur les utilisateurs Exchange Server 5.5 et les utilisateurs Exchange Server 2003

Il existe un certain nombre de problèmes de remise de message pendant un déplacement groupe inter-d'administration et pendant que le connecteur Active Directory nettoie les objets d'annuaire Exchange Server 5.5. Pour préparer à ce problème, il est préférable de bien comprendre les problèmes potentiels.

Problèmes de flux de messagerie

Pour une courte période après que la boîte aux lettres est déplacé, messages peuvent finissent en file d'attente de serveurs qui sont dans un site différent comme si les serveurs sont dans le site local. C'est parce que l'Agent de transfert des messages (MTA) ne comprend pas comment un utilisateur peut accéder sur sites. Par conséquent, l'agent de transfert des messages définit quelques hypothèses incorrectes une fois que le bloc PR_IN_TRANSIT est lancé.

Tentative pour remettre les messages est effectuée sur les procédures stockées à distance (RPC). Ces tentatives échouent si seulement un X 400 lien connecte les sites et si elles ne partagent pas le même contexte de sécurité (le même compte de service). Vous pouvez également recevoir des messages d'erreur semblables aux suivantes sur le serveur Exchange 5.5 :



Type d'événement : avertissement
Source de l'événement : MSExchangeMTA
Catégorie d'événement : interface
L'ID d'événement : 9318
Utilisateur: n / A
Ordinateur : Exchange5.5ServerName
Description : une RPC communications erreur s'est produite. Impossible de lier sur RPC. Index de table LTAB localité: 6, code d'erreur NT/MTA : 1753. Comms erreur 1753, erreur de liaison 0, nom du serveur distant ExchangeServerName [BASE principale 1 500 % 10] (14)



La solution de contournement pour ce problème consiste à temporairement créer un lien de site entre les sites. Cela permet une connexion RPC directe à effectuer entre les serveurs en question. Cette connexion permet pour le courrier soit remis. Après le déplacement de boîtes aux lettres intersite a terminé et l'agent de transfert des messages a identifié correctement la gamme correcte pour l'utilisateur, vous ne rencontrez pas ce problème.



règles de boîte de réception


Si vous disposez de n'importe quel client ou serveur côté boîte de réception règles qui dépendent d'un utilisateur et leur LegacyExchangeDN Exchange, les règles ne seront rompus lorsque vous déplacez des inter-administrative groupes utilisateurs car la LegacyExchangeDN d'un utilisateur change. Cependant, les règles de boîte de réception ne violent pas si l'utilisateur réside sur un serveur ultérieur basé ou Exchange 2003 Service Pack 1. Règles de boîte de réception fonctionnent dans Exchange Server 2003 Service Pack 1 après qu'un groupe inter-administrative déplacer car Autoriser les modifications apportées à la banque de boîtes aux lettres règles travailler même lorsque le LegacyExchangeDN d'un utilisateur change. Au lieu de se fier à l'attribut LegacyExchangeDN, le plus X.500 proxy-adresse qui a été ajouté lors du déplacement groupe inter-d'administration peut servir au cours de règle de traitement sur les serveurs Exchange 2003 Service Pack 1.

Si l'utilisateur n'est pas hébergé sur Exchange Server 2003 Service Pack 1, leurs règles de boîte de réception sont basés sur un groupe inter-administrative déplacé personne doit être recréé.



les utilisateurs déplacés de la liste d'adresses globale
Les utilisateurs qui sont déplacés groupe inter-d'administration peut-être disparaître de la liste d'adresses globale dans Exchange Server 5.5 pour un court moment pendant que l'objet Exchange Server 5.5 d'origine dans le site ancien est masqué et avant d'Exchange Server 5.5 objet a été répliqué vers le nouveau site à partir d'Active Directory. Groupe d'administration entre déplacé les utilisateurs sont inchangés dans Active Directory, Exchange 2000 Server et la Exchange Server 2003 liste d'adresses globale.

adresses proxy


Les utilisateurs conservent leurs adresses de proxy d'origine à partir de leur site ancien. Toutefois, les utilisateurs économisez pas proxy nouveau adresses d'être déplacé groupe inter-administratif, même si la stratégie de destinataire est basée sur l'appartenance au groupe d'administration.

Le service de mise à jour destinataire ne marque pas les proxys mis à jour si l'utilisateur a déjà proxys de ce type. Pour recevoir une nouvelle adresse proxy pour une stratégie de destinataire qui appliquerait maintenant à l'utilisateur basé sur l'appartenance d'administration nouveau, cliquez sur Appliquer maintenant sur la stratégie de destinataire, puis recréez le service de mise à jour de destinataire. Nous vous recommandons que vous n'effectuez pas cette opération que s'il est nécessaire car cela peut affecter les performances de votre réseau.

Bien que les adresses proxy ne sont pas mis à jour, flux de messages électroniques n'est pas affecté. Toutefois, si votre système est d'effectuer une vérification des restrictions très spécifiques, vous pouvez rencontrer un problème si les adresses ne sont pas mis à jour. Par exemple, envisagez le scénario suivant :
  • AG1 accepte les messages électroniques de domain1.com.
  • AG2 accepte les messages électroniques de domain2.com.
  • Le connecteur se connecter les deux groupes d'administration ne permet pas tout le monde d'extérieur de l'organisation pour Envoyer courrier électronique sur elle.
  • Par conséquent, le message électronique génère un rapport de non-remise (NDR). Et, le message électronique n'est pas envoyé sur le lien.

processus d'ouverture de session Outlook Web Access


Dans une frontal/principal implémentation, utilisateurs peuvent accéder leurs boîtes aux lettres via Outlook Web Access (OWA) en entrant une Ouverture de session explicite ou d'une Ouverture de session implicite . L'URL pour une ouverture de session explicite spécifie le serveur et les boîtes aux lettres que l'utilisateur souhaite accéder et prend la forme : http:// servername /exchange/ usernameservername est le nom du soit OWA frontal ou back-end serveur et username est le nom de compte Microsoft Windows de l'utilisateur. Lorsqu'un utilisateur utilise une explicite d'ouverture de session pour la connexion à Outlook Web Access (OWA), l'ouverture de session peuvent ne pas fonctionne. Ce problème se produit parce que lorsqu'un utilisateur est déplacé inter-administrative regrouper, le répertoire virtuel HTTP que l'utilisateur utilise les modifications de Outlook Web Access (OWA). Le répertoire virtuel HTTP que l'utilisateur utilise pour Outlook Web Access (OWA) modifie les modifications du serveur principal de l'utilisateur Exchange boîte aux lettres. L'erreur d'ouverture de session se produit si l'adresse SMTP sur le nouveau répertoire virtuel HTTP n'est pas une adresse SMTP dont l'utilisateur.

note Les répertoires de virtuels de Outlook Web Access pour Exchange de par défaut sont tout durs codé pour utiliser la stratégie de destinataire par défaut et l'adresse SMTP dans cette stratégie. Vous ne pouvez utiliser différentes stratégies de destinataire qui ont des adresses SMTP différentes si vous créez un nouveau répertoire virtuel.

Ce problème est susceptible de se produire dans une des deux scénarios suivants :
  • Scénario 1: si le site source est un site Exchange Server 5.5 pur où chaque site possède une adresse SMTP différente et la boîte aux lettres actuelle a une adresse SMTP dans Exchange Server 5.5 qui ne correspond pas à la valeur par défaut Exchange répertoire virtuel adresse SMTP sur le serveur Exchange 2003 Service Pack 1. Lorsqu'il est déplacé à partir d'Exchange Server 5.5 vers Exchange Server 2003, lorsque l'utilisateur tente d'utiliser une ouverture de session explicite avec Outlook Web Access pour ouvrir une session sur le serveur Exchange 2003 Service Pack 1, ils ne peuvent pas se connecter.
  • Scénario 2: dans un pur ou mixte Exchange 2000 Server Exchange Server 2003 environnement, si l'utilisateur utilise actuellement un répertoire virtuel dédié qui est créé par un administrateur et n'est pas le répertoire virtuel par défaut, pour Outlook Web Access. Le répertoire virtuel dédié utilise une adresse SMTP d'une stratégie de destinataire qui fournit également des adresses SMTP sont utilisées par les boîtes aux lettres de l'organisation Exchange. Cela signifie que le SMTP adresses correspondance. Lorsque l'utilisateur est déplacé vers le nouveau site, ils sont déplacés vers un nouveau serveur de boîtes aux lettres Exchange est configuré pour utiliser le répertoire virtuel de Outlook Web Access pour Exchange par défaut. Ce répertoire virtuel Exchange par défaut utilise la stratégie de destinataire par défaut et a une adresse SMTP différente qui l'utilisateur ne dispose pas. Par conséquent, lorsqu'il est déplacé à partir d'Exchange Server 5.5 vers Exchange Server 2003, lorsque l'utilisateur tente d'utiliser une connexion explicite dans Outlook Web Access pour ouvrir une session sur le serveur Exchange 2003 Service Pack 1, ils Impossible de se connecter.
Pour contourner les problèmes dans le scénario n ° 1 et dans les deux scénarios, appliquez l'une des solutions suivantes :
  • Créer un répertoire virtuel dédié dans le nouveau site pour le nouveau serveur de boîtes aux lettres dans laquelle l'utilisateur est déplacé. Pointez le nouveau répertoire virtuel dédié à une stratégie de destinataire dont l'adresse SMTP qui l'utilisateur a.
  • Dans un sites mixte ou pur Exchange Server 2000 scénario, ajoutez l'adresse SMTP de la stratégie de destinataire par défaut à la stratégie de destinataire s'applique à l'utilisateur a été déplacé. Après que le service de mise à jour de destinataire a mise à jour, l'utilisateur a un proxy SMTP supplémentaire répondant maintenant le répertoire virtuel par défaut.
  • Manuellement ajouter l'adresse SMTP correcte à l'utilisateur a été déplacé
Exchange Server 2003 Service Pack 1 comprend un correctif qui permet d'utiliser l'adresse SMTP d'ouvertures de session implicite ou explicite ouvertures de session pour contourner ce problème. Outlook Web Access fonctionnent toujours dans les scénarios suivants lorsque vous vous connectez à un serveur Exchange Server 2003 Service Pack 1 :
  • Ouverture de session implicite
    Par exemple, tapez l'URL pour l'accès OWA dans le format suivant :
    http:// Server Server/Exchange
  • Ouverture de session explicite à l'aide le nom d'utilisateur principal (UPN) ou une adresse de SMTP
    Par exemple, tapez l'URL pour l'accès OWA dans le format suivant :
    http:///change/utilisateur server @ Domain_Name. com

Lorsque vous essayez d'utiliser une connexion explicite à l'aide d'alias de l'utilisateur et l'utilisateur n'a pas l'adresse SMTP du répertoire virtuel HTTP, l'ouverture de session ne se termine pas. Par exemple, si vous tapez l'URL pour l'accès OWA dans le format suivant : http:// Server /exchange/ User, vous n'ont pas accès à la boîte aux lettres du serveur Exchange. Ce problème se produit lorsqu'une connexion explicite à l'aide l'alias d'un utilisateur est utilisée pour OWA et n'est pas aux scénarios de groupe inter-d'administration spécifique.



informations de disponibilité et de boîtes aux lettres de ressources


Informations de disponibilité et doivent être re-published après qu'une boîte aux lettres intersite déplacé. Pour les boîtes aux lettres utilisateur, cela se produira 15 minutes après l'utilisateur utilise Outlook pour ouvrir une session sur le serveur Exchange et l'utilisateur effectue une action de calendrier. Par exemple, si l'utilisateur approuve, supprime ou crée une demande de réunion, les informations de disponibilité et de calendrier sont republiées 15 minutes plus tard.

Le propriétaire d'une boîte aux lettres de ressources, par exemple une salle de réunion, devez ouvrir la boîte aux lettres et exécuter une action de calendrier à republiez les informations de disponibilité et.

Ce problème se produit parce qu'aucune n'est un message de disponibilité pour l'attribut LegacyExchangeDN nouveau ?s l'utilisateur dans le site cible, mais Outlook ne publie pas une mise à jour jusqu'à ce qu'une modification du calendrier est apportée, le cache de la disponibilité ? local ? Outlook est dirtied. Ce problème se produit également si vous exécutez dans le processus GUIDGen pour réinitialiser les dossiers système de site.

Ou bien, l'outil UpdateFB peut être utilisé pour automatiser cette republication processus disponible/occupé.

Pour plus d'informations sur l'outil UpdateFB, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
294282 Comment utiliser Updatefb.exe pour republier absente les données de disponibilité


Carnet d'adresses en mode hors connexion

téléchargement de carnet d'adresses en mode hors connexion et des sites distants
Lorsqu'un utilisateur exécute Outlook 2003 en mode mis en cache sur les sites distants avec Exchange Server 2003 ou une version antérieure, elles doivent vous assurer qu'ils ont suffisamment de bande passante pour prendre en charge un téléchargement complet du carnet d'adresses en mode hors connexion pour tous les clients sur ce site distant.



sites distants via des liaisons lentes


Lorsque boîtes aux lettres que vous utilisez Outlook 2003 en mode mis en cache sont déplacés vers un serveur Exchange 2003 SP1 central, soit entre des sites à partir d'un serveur Exchange Server 5.5 distant ou non, un Carnet d'adresses en mode hors connexion complet doivent être téléchargé. En outre, lorsqu'il y a une modification importante dans le répertoire ou que d'un nouveau groupe d'administration est ajouté ou supprimé, un téléchargement du Carnet d'adresses en mode hors connexion complet sera généré pour les utilisateurs en mode mis en cache. Par conséquent, les sites distants doivent vous assurer qu'il est suffisamment de bande passante pour prendre en charge un Carnet d'adresses en mode hors connexion complet pour tous les clients sur le site distant.



téléchargements du Carnet d'adresses en mode hors connexion complet plus d'informations


En règle générale, les clients Outlook verront uniquement un diff du Carnet d'adresses en mode hors connexion télécharger. Ceci est un petit sous-ensemble du téléchargement du Carnet d'adresses en mode hors connexion complet qui contient des modifications uniquement au lieu de la liste d'adresses globale complète. Cependant, il existe des cas dans lequel les clients Outlook aura pour télécharger le carnet d'adresses en mode hors connexion complet. Par exemple, si le répertoire est un nombre significatif de modifications, beaucoup de nouveaux comptes, les changements de nom, etc. ou un nouveau groupe d'administration Exchange est ajouté ou supprimé, tous les clients qui sont en mode mis en cache seront mis à jour avec un carnet d'adresses en mode hors connexion complet. En outre, les clients qui sont déplacés à partir d'Exchange Server 5.5 vers un nouveau serveur Exchange Server 2003 sont également recevoir un nouveau complet carnet adresses d'en mode hors connexion.

Pour plus d'informations Pour limiter l'effet D'OAB complet téléchargements dans Exchange Server 2003, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft. :
867623 Limitation du carnet d'adresses complète en mode hors connexion télécharge to limit the effect on a LAN in Exchange Server 2003


Attendez de mises à jour de l'annuaire

Les administrateurs devront attendre annuaire mises à jour de surviennent avant les messages peuvent circuler sans créer un rapport de non-remise (NDR).

Problèmes connus : comportement après rapatrier objet

Remise de message sera affecté sur Exchange Server 5.5 et Exchange Server 2003 pour les utilisateurs des listes de contacts et de distribution de publipostage

Si les utilisateurs envoyer des messages électroniques à contacts et listes de distribution au cours d'un groupe inter-d'administration déplacement et pendant le connecteur Active Directory nettoyage des objets d'annuaire Exchange Server 5.5, il existe un certain nombre des problèmes de remise de message qui peut se produire.

règles de boîte de réception


Lorsque la liste/du groupe de distribution est re-homed pendant un groupe inter-administrative déplacer, les règles de boîte de réception qui processus messages basés sur la liste de distribution en tant qu'expéditeur ou destinataire ne fonctionne pas pour les boîtes aux lettres qui sont hébergés sur les serveurs Exchange qui sont antérieures à Exchange 2003 Service Pack 1. Ces règles doivent être recréés, ou les boîtes aux lettres avec la règle doivent être déplacées vers un serveur qui exécute Exchange 2003 SP1.



transféré les dossiers publics dans la liste d'adresses globale


Lorsqu'une liste de contacts/distribution migrée, il peut disparaître de la liste d'adresses globale dans Exchange Server 5.5 pendant l'heure à laquelle l'objet Exchange Server 5.5 d'origine dans le site ancien est masqué et avant la nouvelle 5.5 Server Exchange objet a été répliqué vers le nouveau site à partir d'Active Directory. Objets re-homed dans Active Directory, la liste d'adresses globale Exchange 2000 Server ou la Exchange Server 2003 liste d'adresses globale ne sont pas affectés.



adresses proxy


Objets qui sont re-homed conserveront leurs adresses de proxy d'origine à partir de leur site ancien. Toutefois, ils pas économisez nouvelles adresses proxy lorsque déplacé groupe inter-administratif, même si la stratégie de destinataire est basée sur l'appartenance au groupe d'administration.

Le service de mise à jour destinataire ne marque pas les proxys mis à jour sur l'objet si l'objet re-homed possède déjà le même type de proxy. Pour recevoir une nouvelle adresse proxy pour une stratégie de destinataire s'appliquer maintenant à l'objet fonction de l'appartenance de groupe d'administration nouveau, cliquez sur Appliquer maintenant sur la stratégie de destinataire, puis recréez le service de mise à jour de destinataire. Nous vous recommandons que vous n'effectuez pas cette opération que s'il est nécessaire car cela peut affecter les performances de votre réseau.
Bien que les adresses proxy ne sont pas mis à jour, flux de messages électroniques n'est pas affecté. Toutefois, si votre système est d'effectuer une vérification des restrictions très spécifiques, vous pouvez rencontrer un problème si les adresses ne sont pas mis à jour. Par exemple, envisagez le scénario suivant :
  • AG1 accepte les messages électroniques de domain1.com.
  • AG2 accepte les messages électroniques de domain2.com.
  • Le lien qui relie les deux groupes d'administration ne permet pas tout le monde extérieur de l'organisation pour envoyer des messages sur elle.
  • Par conséquent, le message électronique génère un rapport de non-remise (NDR). Le message électronique ne sera pas envoyé sur le lien.


adresses X.500 sont remplacés par connecteur Active Directory inter_organisationnel dans les contacts qui sont déplacés intersite


Examinons ce scénario. Un accord de connexion inter-organisationnels (CA) crée un contact dans une organisation. Le contact représente des boîtes aux lettres dans une autre organisation. Si le contact est déplacé intersite, le nom de répertoire d'origine du contact à partir du site source est tamponnée sur le contact a été déplacé dans le formulaire d'une adresse X.500. Toutefois, si la boîte aux lettres que représente le contact est modifiée, la modification est répliquée vers l'objet contact déplacé et le connecteur Active Directory remplacent l'adresse X.500.

Pour contourner ce problème, appliquez une ou plusieurs des procédures suivantes :
  • Reconfigurer le connecteur ADC vers un nouveau site, puis exécutez l'outil perdre toutes les adresses X.500.
  • Exporter le LegacyExchangeDNs à partir d'Exchange Server 5.5 avant le déplacement entre sites et ensuite importer le LegacyExchangeDNs que les adresses X.500 sur les boîtes aux lettres Exchange Server 5.5.
  • Passez au mode natif Exchange et ne pas déplacer les contacts.


Attendez que le connecteur ADC terminer


Vous devez attendre pour Active Directory pour Exchange Server 5.5 réplication, la réplication intrasite et inter-site réplication soit terminée. Flux des messages électroniques et d'autres opérations seront affectées jusqu'à ce que les répertoires Exchange Server 5.5 sont synchronisées et que le connecteur Active Directory a été exécuté pour corriger les modifications.

Exécuter le vérificateur de cohérence Directory service/banque d'informations


Après une distribution de liste qui a accès à un dossier public est déplacé intersite, vous devez exécuter la corrigée Directory service/banque d'informations (service D'ANNUAIRE/is) outil de vérificateur de cohérence pour vous assurer que la liste de distribution est toujours en mesure d'accéder au dossier public.

Références

Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
836489 Une mise à jour est nécessaire de consolidation de site en mode mixte avec Exchange Server 5.5
843107 Comment utiliser l'outil pfMigrate pour effectuer une opération de déplacement intersite des dossiers publics dans Exchange 2003 Service Pack 1

Propriétés

Numéro d'article: 841659 - Dernière mise à jour: jeudi 6 février 2014 - Version: 3.2
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Exchange Server 2003 Service Pack 1
Mots-clés : 
kbnosurvey kbarchive kbmt kbinfo kbexchange2003sp1fix KB841659 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 841659
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

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