Probleme während der Standortkonsolidierung in einer Exchange Server 2003 Service Pack 1-based Site kennen

Installieren von Exchange Server 2003 Service Pack 1 Active Directory Connector

Die Active Directory Connector (ADC) in Microsoft Exchange Server 2003 Service Pack 1 ist eine Voraussetzung für die Standortkonsolidierung. Die grafische Benutzeroberfläche (GUI) von Exchange System-Managers in Exchange Server 2003 Service Pack 1 kann nicht Cross-Site wechselt zum auftreten, bis in der Gesamtstruktur alle ADCs auf Exchange Server 2003 Service Pack 1 aktualisiert wurden.

Aktualisieren Sie Exchange Server 5.5 Connector zur Verzeichnisreplikation Zeitplan (optional)

Viele Verzeichnisänderungen können auftreten, während Cross-Site wechselt. Wir empfehlen der Administrator den Exchange Server 5.5 Connector zur Verzeichnisreplikation Zeitplan zwischen remote-Standort und den zentralen Standort, in denen Objekte verschoben werden. Sicherstellen, dass die Replikation der Änderungen Fluss schnell vom zentralen Standort zum Remotestandort rückgängig machen, die konsolidiert werden, ist kann der Administrator möchten folgende Aktionen ausführen:

• Stellen Sie sicher, dass der Exchange Server 5.5-Replikation-Connector direkt zwischen dem Remotestandort und dem zentralen Standort festgelegt wird.
• Stellen Sie sicher, dass derselbe Server am zentralen Standort durch den Connector Replikation verwendet wird, und ändert sich von des Replikation-Bridgeheads, dass der ADC für die Active Directory-Verzeichnisdienst replizieren konfiguriert ist.
• Stellen Sie sicher, dass der Exchange Server 5.5-Replikationszeitplan auf immer oder kurzen Intervallen festgelegt ist.

Diese Änderungen sind optional, jedoch werden dringend empfohlen. Wenn Verzeichnisreplikation oder ADC-Replikation verzögert wird, kann der automatisierte Cleanup-Prozess nach Cross-Site wechselt länger dauern.

ADC-Verhalten

ADC-Verhalten vor dem Verschieben

Bevor Cross administrativen Gruppe verschieben eines Öffentlichen Ordners abgeschlossen ist, schließt der ADC mehrere Stufen der Cross administrativen Gruppe verschieben Cleanup Verhalten. Die Nachrichtenübermittlung wird beeinträchtigt, bis zum Abschluss der ADC-Bereinigung Cross administrativen Gruppe verschieben.

Die Zeit für das ADC-Bereinigung Verhalten hängt Ihre Umgebung, die Replikation zwischen Exchange Server 5.5-Standorten und Replikation von Active Directory zu Exchange Server 5.5 ab.

Die Bereinigung der Verteilerlisten und das Löschen des Objekts Stub werden beispielsweise alle 12 Stunden ausgeführt. Die Bereinigung der Verteilerlisten und das Löschen der Stub-Objekts werden zur gleichen Zeit abgeschlossen. In kleineren Umgebungen können diese in eine Bereinigung Zyklus oder 12 Stunden abgeschlossen werden. In größeren Umgebungen benötigen diese zwei, oder weitere Cleanup Zyklen und Sie näher an 24 Stunden dauern. Bereinigen von Verteilerlisten und Löschen des Objekts Stub können länger in einer größeren Umgebung aufgrund der folgenden dauern:

• Die Zeit zum Replizieren von Active Directory auf Exchange Server 5.5
• Standortübergreifende Replikation in Exchange Server 5.5.

Bereinigung schneller klicken Sie mit der rechten Maustaste auf die Verbindungsvereinbarung und klicken Sie Jetzt replizieren . Die Geschwindigkeit ist jedoch weiterhin durch die folgenden beschränkt:

• Die Zeit aus dem Active Directory auf Exchange Server 5.5 repliziert.
• Standortübergreifende Replikation in Exchange Server 5.5.

ADC-Verhalten für verknüpfte Exchange Server 5.5 und Active Directory-Objekte während einer Cross administrativen Gruppe verschieben

Das Exchange Server 5.5-Stubobjekt und das Active Directory-Objekt sind beim Cross-Site verschieben Unverknüpfte. Dem Public Folder Veränderung des Stammservers für das Tool (PFMigrate) verwendet das neue NM_MOVED_CROSS_SITE-Flag im Namen ADC-Global, einen anderen ADC-Global Namen Wert beide Objekte zuzuweisen. Der ADC verknüpft nicht diese beiden Objekte miteinander. Daher kann das Stubobjekt am Ende der Bereinigung ohne Löschen der Active Directory-Objekt gelöscht werden.

Der ADC unterdrückt das Stub Exchange Server 5.5-Objekt zurück, das Active Directory-Replikation, da ADC GlobalNames entfernt und mit einem anderen Wert re-stamped. Wenn der ADC-Replikation nicht unterdrücken, würde das Verzeichnisobjekt für Öffentliche Ordner zurück in Active Directory repliziert werden, und das Ergebnis wäre doppelte Objekte. Darüber hinaus kann die ADCGlobalNames nicht auf alle Domänencontroller repliziert wurde, der Benutzer wieder mit Active Directory-Objekt verknüpft werden. PFMigrate Stempel ADCDoNotReplicate als eine x. 500-Proxyadresse für den öffentlichen Ordner. Der ADCDoNotReplicate-Stempel teilt den ADC nicht, dieses Objekt wieder in Active Directory zu replizieren. Das Bit Cross-Site kann nicht zum dieses Verhalten beenden, da nicht der ADC-GlobalNames repliziert verwendet werden inter-Site. Daher würde die Verbindungsvereinbarungen, die Änderungen zu replizieren, die von einer nicht lokalen Website versorgt nicht Cross-Site-bit- und finden Sie würde weiterhin replizieren, Löschungen und Aktualisierungen.

ADC-Bereinigung Verhalten

Aktualisieren von Verteilergruppen

In Exchange Server 5.5 muss das alte Exchange Server 5.5 Öffentliche Ordner-Objekt aus der Verteilerliste entfernt werden, und der verschobene Öffentliche Ordner muss in der Verteilerliste aus dem Active Directory aktualisiert werden.

Domänenobjekte sind eine der grundlegendsten Objekte in Active Directory. Alle anderen Objekte sind Domänenobjekte untergeordnet. Der DN (Distinguished Name) eines Domänenobjekts besteht aus den Domäne-Komponenten (dc) des DNS-Namen der Domäne. Beispielsweise hat die Domäne microsoft.com-Objekt einen DN dc = Microsoft, dc = com. Objectclass, die für dieses Objekt verwendet wird, ist DomainDNS und die Objectcategory ist DomainDNS.

Da die Mitgliedschaft in Verteilerlisten basiert auf DN und Ändern der Mitgliedschaft nicht während der die Cross-administrative Gruppe verschieben eines Öffentlichen Ordners, Active Directory hat die richtige Mitgliedschaft in den öffentlichen Ordner. ADC verwendet den ADCGlobalNames -Befehl, um die Gruppenmitgliedschaft und DN Verknüpfungen nachschlagen, wenn es in Exchange Server 5.5 repliziert. ADC kann die Exchange Server 5.5-Verteilerlisten aktualisieren, indem Erzwingen der Replikation der Active Directory-Gruppe wird. Allerdings kann es Wartezeit zwischen Exchange Server 5.5-Standorten. Daher wird die Verteilerliste in einem Standort aktualisiert, Sie haben nicht das neue Objekt und möglicherweise nur Kenntnisse über das Objekt den Stub für Öffentliche Ordner. Um dieses Problem zu umgehen, führt der ADC DN Link Suchvorgänge damit verknüpft alte Objekte an, ob das neue Objekt nicht gefunden werden kann, wenn Exchange Server 5.5-Verzeichnis durchsucht wird.

Der alte Exchange Server 5.5 Öffentliche Ordner gelöscht wurden und wurden als Stub Öffentliche Ordner bis nach Verteilung Liste Cleanup nicht beibehalten, der Öffentliche Ordner würde aus Ihren Verteilerlisten entfernt, und der Öffentliche Ordner verliert die Mitgliedschaft in Verteilerlisten. Dies kann auftreten, wenn die Verteilerlisten zurück in Active Directory repliziert und den Benutzer aus Ihren Verteilerlisten entfernt. Allerdings da Stub öffentlichen Ordner gespeichert wird, muss es ein Prozess, der diese Verteilerlisten bereinigt, sodass das neu verschoben Öffentliche Ordner-Objekt an die Verteilerlisten über Exchange Server 5.5-Standorten hinzugefügt wird und damit letztendlich das Objekt den Stub für Öffentliche Ordner entfernt werden kann. Dieses Verhalten kann in der folgenden zwei Arten auftreten:

• Der Prozess PFMigrate berührt alle Verteilerlisten, zu der der verschobene Öffentliche Ordner in Active Directory gehört. Daher repliziert Active Directory die richtige Mitgliedschaft wieder zu Exchange Server 5.5. Das replizierte ObjectVersion-Attribut wird in Active Directory aktualisiert.
• Wenn die Verteilerlisten nicht in der Zielsite vorhanden sind, kann der ADC automatisch die Replikation von allen Verteilerlisten erzwingen, zu dem der Öffentliche Ordner gehört. PFMigrate kennzeichnet alle administrativen-gruppenübergreifende verschobenen Öffentliche Ordner mit der X 500: ADCDeleteWhenUnlinked Proxy Wert und sucht nach Verteilung Mitgliedschaft aufgelistet. ADC sucht nach Objekten mit einer Proxyadresse des X 500: ADCDeleteWhenUnlinked zum Erzwingen der Replikation. Wenn die Verteilergruppe in der lokalen Website befindet, wird es die Gruppe in Active Directory berühren, die die richtige Mitgliedschaft durch den neuen Öffentlichen Ordner in der neuen Website Erzwingen der Replikation in Exchange Server 5.5 verfügt. Dieses Verhalten wurde in die Phase hinzugefügt, wenn ADC für Verzeichnisbereinigung nicht aufgelöste DN Verknüpfungen beheben aufweist. Dieses Verhalten führt alle 12 Stunden.

Entfernen von Stub Objekte im ursprünglichen Exchange Server 5.5-Standort

Die X 500: ADCDeleteWhenUnlinked Proxy-Wert ist für ein Objekt durch die PFMigrate gestempelt Prozess, um anzugeben, dass das Objekt gelöscht werden soll, wenn das MemberOf -Attribut leer ist. Dies bedeutet, dass das Objekt keine Verteilergruppen aufgrund des Verhaltens Liste aktualisierte Verteilung gehört, die weiter oben beschrieben wird. Dies wurde auch die Phase hinzugefügt, die der ADC für Verzeichnisbereinigung nicht aufgelöste DN Verknüpfungen aufgelöst hat.

Outlook Web Access und Outlook gelesen/ungelesen-status

Wenn ein Öffentlicher Ordner auf einem anderen Server während verschoben wird Cross-Site wechselt der Öffentlichen Ordner, der Status befindlichen gelesene und ungelesenen Nachrichten im öffentlichen Ordner gehen verloren. Dieses Verhalten, da die Lese- und ungelesen-Status nicht zwischen Servern repliziert wird. Daher Wenn ein Benutzer Outlook Web Access verwendet, oder wenn Outlook greift auf ein Öffentlicher Ordner, die Cross-Site verschoben, werden alle Nachrichten als ungelesen angezeigt. Dieses Verhalten tritt auch auf, wenn Sie Replikate Öffentlicher Ordner innerhalb der Website verschieben. Dieses Verhalten gilt nicht für Cross-Site wechselt.

Zugriff auf einen Öffentlichen Ordner, die wurde verschoben Cross-Site

Das folgende Verhalten auftreten:

• Der Zugriff auf einen Öffentlichen Ordner verschobenen möglicherweise vorübergehend verweigert.
• Sie können nicht an das neue Basisverzeichnis des öffentlichen Ordners umgeleitet werden.
• Der neue Öffentliche Ordner möglicherweise nicht alle Inhalte.

Dieses Verhalten kann aus folgenden zwei Gründen auftreten:

• Wenn die Replikatliste auf nicht aktualisiert wird der Benutzer ?s-Server, der Cross-Site zugreift verschoben für Öffentlichen Ordner, der Benutzer wird angewiesen, das alte Replikat bis die Replikatliste aktualisiert wird. Wenn das alte Replikat gelöscht wird, erhält der Benutzer Zugriff auf den öffentlichen Ordner nicht. Die Replikatliste erwartet innerhalb von fünf Minuten das Cross-Site Verschieben aktualisiert werden. Jedoch die Replikatliste kann nicht repliziert werden, bevor die Replikate Öffentlicher Ordner gelöscht wird, werden Benutzer erst dann über Zugriff auf den öffentlichen Ordner die Replikatliste aktualisiert wird.
• Der Benutzer kann keine Verbindung herstellen zur neuen Website, um Ihre Öffentlichen Ordner zugreifen, bevor der Inhalt auf den neuen Standort repliziert wird.

Affinität Öffentlicher Ordner

Zugriff auf Öffentliche Ordner kann nicht abgeschlossen, wenn Öffentliche Ordner-Affinität zum neuen Standort nicht festgelegt ist. Dies liegt daran, Affinität für den neuen ? privat eingeben Standort des öffentlichen Ordners vor dem Verschieben Öffentlicher Ordner Cross-Site konfiguriert werden muss. Dieses Verhalten tritt auch auf, wenn Sie Replikate Öffentlicher Ordner verschieben und nicht gilt für Cross-Site wechselt.

Affinität Öffentlicher Ordner ist die Fähigkeit eines Client-Programms können Sie einen Server auf einem anderen Standort anzeigen und einen Öffentlichen Ordner zugreifen. Dies erfolgt, anstatt den Ordner zum lokalen Standort replizieren. Affinität Öffentlicher Ordner wird normalerweise verwendet, wenn eine Verbindung mit hoher Bandbreite vorhanden ist.

Hinweis: Affinität Öffentlicher Ordner ist nicht erforderlich, wenn die Anleitung bereitstellen, Replikate in Quell- und Zieldomäne Sites während das Postfach Schritte verschieben befolgt werden. Affinität werden benötigt, wenn insgesamt Öffentliche Ordner verschoben werden, entweder vor oder nach-Postfach verschiebt.

Bekannte Probleme: Verhalten nach Cross-Site für Öffentliche Ordner verschieben

Auswirkungen auf Benutzer von Exchange Server 5.5 und Exchange Server 2003-Benutzer Wenn e-Mail-Nachrichten an Öffentliche Ordner gesendet werden

Nachrichtenübermittlung behandeln können auftreten, wenn Benutzer senden, e-Mail-Nachrichten an einen Öffentlichen Ordner während einer Cross administrativen Gruppe verschieben und während der ADC die Exchange Server 5.5-Verzeichnisobjekte Aufräumen ist.

Hinweis: Während des Verschiebens Cross-Site erhalten Benutzer einen Unzustellbarkeitsbericht (NDR), die den folgenden Fehler enthält:

Posteingangsregeln

Regeln, die Nachrichten, verschieben zu und von Öffentlichen Ordnern, die auf Ordner-ID (FID) basieren funktioniert nicht nachdem Öffentliche Ordner zwischen administrativen Gruppen verschoben wurden. Möglicherweise wird eine Meldung angezeigt, die der folgenden ähnelt:

verschobene Öffentliche Ordner in der globalen Adressliste

Öffentliche Ordner, die zwischen administrativen Gruppen verschoben werden können aus der globalen Adressliste in Exchange Server 5.5 verschwinden. Dieses Verhalten kann auftreten, wenn das ursprüngliche Exchange Server 5.5-Objekt in der alten Website vor der neuen Exchange Server 5.5 ausgeblendet ist, aus Active Directory-Objekt an den neuen Standort repliziert wird. Zwischen administrative verschobenen Öffentliche Ordner sind in Active Directory, Exchange 2000 Server Global Address List oder der Exchange Server 2003 globalen Adressliste nicht betroffen.

Journaling

Journaling funktioniert nicht, wenn ein Öffentlicher Ordner, der für Exchange Server 5.5 oder Exchange 2000 Server-Journal verwendet wird verschoben zwischen administrativen Gruppen ist. Dieses Problem tritt auf, weil das LegacyExchangeDN -Attribut geändert wird.

Hinweis: Journaling in einem öffentlichen Ordner in Exchange 2000 und Exchange Server 2003 wird nicht unterstützt und Funktionalität und Leistungsprobleme in Ihrer Exchange-Umgebung verursachen. Beim Journaling nach Cross-Standort zum anderen neu konfigurieren, ändern Sie Ihre Journale auf ein Postfach statt auf einen Öffentlichen Ordner.

organisatorische Formulare

Organisatorische Formulare werden nicht verschoben Cross-Site durch das PFMigrate-Skript. Organisatorische Formulare sind Teil der Systemordner, und Administratoren müssen die Replikatliste für Öffentliche Ordner für diese und andere Systemordner manuell aktualisieren.

Programme von Fremdanbietern anhand von Öffentlichen Ordnern

Fremdanbieter-Programme, die auf einen Öffentlichen Ordner und das Attribut LegacyExchangeDN des öffentlichen Ordners basieren funktionieren möglicherweise nicht nach dem Verschieben eines Öffentlichen Ordners Cross-Site.

Proxyadressen

Öffentliche Ordner behalten ihre ursprüngliche Proxyadressen von der alten Website. Öffentliche Ordner werden außerdem nicht erhalten neuen Proxy Adressen verhindert verschoben Cross-administrative Gruppe, auch wenn die Empfängerrichtlinie auf Administrative Gruppenmitgliedschaft basiert.

Der Empfängeraktualisierungsdienst wird nicht aktualisierten Proxys Zeitstempel, wenn der Öffentliche Ordner bereits Proxys dieses Typs. Um eine neue Proxyadresse für eine Empfängerrichtlinie zu erhalten, die jetzt für den Benutzer anhand der neuen administrativen Gruppenmitgliedschaft gelten würden, klicken Sie auf jetzt anwenden der Empfängerrichtlinie, und erstellen Sie den Empfängeraktualisierungsdienst neu. Es wird empfohlen, dass Sie dies nicht tun, wenn es erforderlich ist, da dies die Leistung des Netzwerks auswirken kann.

Obwohl Proxyadressen nicht aktualisiert werden, e-Mail-Nachrichten Nachrichtenfluss betroffen sind. Jedoch, wenn Ihr System einige sehr spezielle Einschränkungsüberprüfung durchführt, können ein Problem auftreten, wenn die Adressen nicht aktualisiert werden. Gehen wir beispielsweise von folgendem Szenario aus:

• AG1 akzeptiert e-Mail-Nachrichten für domain1.com.
• AG2 akzeptiert e-Mail-Nachrichten für domain2.com.
• Der Connector, der die beiden administrativen Gruppen verbindet, lässt nicht jeder Benutzer außerhalb der Organisation e-Mail-Nachrichten über ihn zu senden.
• Daher würde die e-Mail-Nachrichten einen UNZUSTELLBARKEITSBERICHT generieren. Die e-Mail-Nachrichten werden nicht über den Connector gesendet werden.

Ausführen der Directory Service/Information Store Konsistenzanpassung ? Rehome eingeben (Option)

Nach der Cross-Standort eines Öffentlichen Ordners zum anderen, es wird empfohlen, dass der Directory Service/Information Store nicht ausgeführt werden (DS / IS) Konsistenzanpassung mit dem Feature synchronisiert mit dem Verzeichnis und Zurücksetzen der Stammserver Wert eingeschaltet, bis alle Verzeichnisreplikation abgeschlossen ist. Es wird empfohlen, nie die DS führen / IS-Konsistenzanpassung, wenn es erforderlich ist. Sie müssen warten, bis für Öffentliche Ordner Cross-Site wechselt abgeschlossen, sind vor dem Ausführen der DS / IS-Konsistenzanpassung.
Wenn Sie die DS starten / IS-Konsistenzanpassung kurz nach Cross-Site für Öffentliche Ordner verschiebt, kann es Ihre Öffentlichen Ordner auf einer Website außer der Zielsite von PFMigrate angegebenen verlagern. Dieses Verhalten kann auftreten, wenn folgende Bedingungen zutreffen:

• Ausführen von PFMigrate Replikate der Öffentlichen Ordner für alle öffentlichen Ordner in einer Website zu einem Ziel-Server an einem neuen Standort hinzufügen.
• Sie führen Sie PFMigrate alle Replikate Öffentlicher Ordner von allen Servern in der Quellwebsite löschen.
• Ein Administrator führt die DS / IS-Konsistenzanpassung bevor verwaltete Attribute wieder aus dem Active Directory in Exchange Server 5.5-Verzeichnis repliziert haben.

Allerdings nach Active Directory mit Exchange Server 5.5 repliziert, besteht kein Risiko bei der Ausführung der DS / IS-Konsistenzanpassung.

Problembehandlung bei Verhalten nach domänenübergreifenden administrative Gruppe Postfach verschiebt

Auswirkungen auf Benutzer von Exchange Server 5.5 und Exchange Server 2003-Benutzer

Es gibt eine Reihe von Nachricht Übermittlung Problemen beim Verschieben zwischen administrativen Gruppen und während der ADC die Exchange Server 5.5-Verzeichnisobjekte Aufräumen ist. Zur Vorbereitung dieses Verhalten wird empfohlen, dass Sie potenzielle Probleme vollständig verstehen.

Nachrichtenflussprobleme

Für kurze Zeit nachdem das Postfach verschoben wurde, können Nachrichten landen für Server in einem anderen Standort als die Server am lokalen Standort sind in der Warteschlange befinden. Dies ist da MTA (Message Transfer Agent) nicht interpretieren kann wie ein Benutzer zwischen Standorten verschoben werden kann. Daher Annahmen der MTA einige falsche nach der Veröffentlichung des PR_IN_TRANSIT-Blocks.

Um die Nachrichten zu übermitteln sind über remote gespeicherte Prozeduren (RPC) versucht. Diese Versuche fehlschlagen, wenn nur ein X 400-Connector eine Verbindung herstellt die Sites und wenn Sie nicht der gleiche Sicherheitskontext (das gleiche Dienstkonto) freigeben. Sie können auch Fehlermeldungen, die auf dem Exchange 5.5-Server die folgenden ähneln:

Ereignistyp: Warnung
Quelle: MSExchangeMTA
Ereigniskategorie: Schnittstelle
Ereignis-ID: 9318
Benutzer: NV
Computer: Exchange5.5ServerName
Beschreibung: Ein RPC-Kommunikationsfehler ist aufgetreten. Kann nicht über RPC gebunden werden. Index (Locality Table): 6 NT-MTA-Fehlercode: 1753. Kommunikationsfehler Fehler 1753, Bindungsfehler 0, Remoteservername ExchangeServerName [MAIN BASE 1 500 % 10] (14)

Abhilfe für dieses Problem besteht darin, ein Standortconnector zwischen den Standorten vorübergehend zu erstellen. Dies ermöglicht eine direkte RPC-Verbindung zum zwischen den Servern fragliche vorgenommen werden. Diese Verbindung ermöglicht e-Mail-Nachrichten übermittelt werden. Nachdem das Verschieben von Cross-Site Postfächern abgeschlossen wurde und der MTA hat korrekt identifiziert das richtige routing für den Benutzer, können dieses Problem nicht auftreten.

Posteingangsregeln

Wenn Sie alle Posteingangsregeln Client oder Server-Seite, auf denen ein Benutzer und Ihre Exchange-LegacyExchangeDN basieren haben, werden die Regeln unterbrochen, wenn Sie Benutzer Cross-administrativen Gruppen, verschieben da der LegacyExchangeDN des Benutzers ändert. Posteingangsregeln werden jedoch nicht unterbrochen, wenn der Benutzer auf einem Exchange Server 2003 Service Pack 1 oder höher-basierten Server befindet. Posteingangsregeln funktionieren in Exchange Server 2003 Service Pack 1, nachdem eine Cross-administrative Gruppe verschieben, da Änderungen an den Postfachspeicher ermöglichen Regeln zu arbeiten, selbst wenn der LegacyExchangeDN des Benutzers ändert. Statt sich auf das LegacyExchangeDN-Attribut zu verlassen, kann die zusätzliche x. 500-Proxyadresse, die während des Verschiebens zwischen administrativen Gruppe hinzugefügt wurde während der Regelverarbeitung auf Exchange 2003 Service Pack 1-Servern verwendet werden.

Wenn der Benutzer nicht auf Exchange Server 2003 Service Pack 1 befindet, verschoben Ihre Posteingangsregeln, die auf eine Cross-administrative Gruppe basieren Person muss neu erstellt.

verschobene Benutzer in der globalen Adressliste

Benutzer, die Cross-administrative Gruppe aus der globalen Adressliste in Exchange verschwinden möglicherweise Server 5.5 für kurze Zeit während das ursprüngliche Exchange Server 5.5-Objekt in der alten Website ausgeblendet ist und vor der neuen Exchange Server 5.5-Objekt wurde an den neuen Standort aus Active Directory repliziert wurde verschoben werden. Zwischen administrativen Gruppen verschoben, Benutzer in Active Directory, Exchange 2000 Server und die Exchange Server 2003 globale Adressliste nicht betroffen sind.

Proxyadressen

Benutzer werden die ursprünglichen Proxyadressen von der alten Website beibehalten. Benutzer werden jedoch nicht erhalten neuen Proxy Adressen verhindert verschoben Cross-administrative Gruppe, auch wenn die Empfängerrichtlinie auf Administrative Gruppenmitgliedschaft basiert.

Der Empfängeraktualisierungsdienst wird nicht aktualisierten Proxys Zeitstempel, wenn der Benutzer bereits über Proxys dieses Typs verfügt. Um eine neue Proxyadresse für eine Empfängerrichtlinie zu erhalten, die jetzt für den Benutzer anhand der neuen administrativen Gruppenmitgliedschaft gelten würden, klicken Sie auf jetzt anwenden der Empfängerrichtlinie, und erstellen Sie den Empfängeraktualisierungsdienst neu. Es wird empfohlen, dass Sie dies nicht tun, wenn es erforderlich ist, da dies die Leistung des Netzwerks auswirken kann.

Obwohl Proxyadressen nicht aktualisiert werden, e-Mail-Nachrichten Nachrichtenfluss betroffen sind. Jedoch, wenn Ihr System einige sehr spezielle Einschränkungsüberprüfung durchführt, können ein Problem auftreten, wenn die Adressen nicht aktualisiert werden. Gehen wir beispielsweise von folgendem Szenario aus:

• AG1 akzeptiert e-Mail-Nachrichten für domain1.com.
• AG2 akzeptiert e-Mail-Nachrichten für domain2.com.
• Der Connector die beiden administrativen Gruppen zulässig nicht jeder Benutzer außerhalb der Organisation zum Senden von E-mail über Sie.
• Daher erstellt die e-Mail-Nachricht einen UNZUSTELLBARKEITSBERICHT. Und die e-Mail-Nachricht wird nicht über den Connector gesendet werden.

Outlook Web Access-Anmeldung

In einer front-end-/ Back-End-Implementierung können Benutzer ihre Postfächer über Outlook Web Access (OWA) zugreifen, indem eine explizite Anmeldung oder eine implizite Anmeldung eingeben. Der URL für eine explizite Anmeldung gibt, den Server und Postfach, dass der Benutzer zugreifen möchte und die Form nimmt: http:// servername Servername/Exchange / username /, wobei servername der Name des entweder OWA-Front-End- oder Back-End Servers, und username ist der Name des Microsoft Windows-Konto des Benutzers. Wenn ein Benutzer ein expliziter Anmeldung auf Anmeldung zu Outlook Web Access (OWA) verwendet, funktioniert möglicherweise nicht die Anmeldung. Dieses Problem auftritt, weil ein Benutzer Cross administrative verschoben wird gruppieren, virtuelle HTTP-Verzeichnis, die der Benutzer für Outlook Web Access (OWA) Änderungen verwendet. Virtuelle HTTP-Verzeichnis, das der Benutzer für Outlook Web Access (OWA) verwendet, ändert, da Exchange Postfach Back-End-Server des Benutzers ändert. Der Anmeldefehler wird auftreten, wenn die SMTP-Adresse auf dem neuen virtuellen HTTP-Verzeichnis nicht SMTP-Adresse ist die der Benutzer verfügt.

Hinweis: Die virtuellen Standardverzeichnisse für Exchange Outlook Web Access sind alle fest codiert die Standard-Empfängerrichtlinie und die SMTP-Adresse in die Richtlinie zu verwenden. Sie können nur andere Empfängerrichtlinien verwenden, die verschiedene SMTP-Adressen, verfügen wenn Sie ein neues virtuelles Verzeichnis erstellen.

Dieses Problem wird wahrscheinlich in den folgenden beiden Szenarien auftreten:

• Szenario 1: Ist der Quellwebsite einer reinen Exchange Server 5.5-Standort, wobei jede Site hat eine andere SMTP-Adresse, und das aktuelle Postfach hat eine SMTP-Adresse in Exchange, Exchange Server 5.5, die nicht die Standardeinstellung entsprechen, virtuelles Verzeichnis SMTP-Adresse auf dem Server Exchange Server 2003 Service Pack 1. Wenn der Benutzer von Exchange Server 5.5 zu Exchange Server 2003, verschoben wird wenn der Benutzer versucht, eine explizite Anmeldung mit Outlook Web Access für die Anmeldung an den Server mit Exchange Server 2003 Service Pack 1 zu verwenden, können Sie nicht anmelden.
• Szenario 2: in einer gemischten reinen Exchange 2000 Server-Exchange Server 2003 Umgebung oder wenn der Benutzer derzeit ein dediziertes virtuelles Verzeichnis verwendet wird, das von einem Administrator erstellt und nicht das standardmäßige virtuelle Verzeichnis für Outlook Web Access. Das dedizierte virtuelle Verzeichnis verwendet eine SMTP-Adresse aus einer Empfängerrichtlinie, die auch SMTP-Adressen bereitstellt, die verwendet werden, von Postfächern in der Exchange-Organisation. Dies bedeutet, dass das SMTP-Übereinstimmung behandelt. Wenn der Benutzer an den neuen Standort verschoben wird, werden Sie an eine neue Exchange-Postfachserver verschoben, die Sie das virtuelle Standardverzeichnis für Exchange Outlook Web Access eingerichtet ist. Diese virtuelle Standardverzeichnis für Exchange verwendet die Standard-Empfängerrichtlinie, und hat eine andere SMTP-Adresse, die der Benutzer nicht verfügt. Wenn der Benutzer von Exchange Server 5.5 zu Exchange Server 2003, verschoben wird wenn der Benutzer versucht, eine explizite Anmeldung in Outlook Web Access für die Anmeldung an den Server mit Exchange Server 2003 Service Pack 1 zu verwenden, können nicht aus diesem Grund Sie anmelden.

Verwenden Sie eine der folgenden Abhilfen, um die Probleme in Szenario 1 und in Szenario 2 zu umgehen:

• Erstellen Sie ein dediziertes virtuelles Verzeichnis am neuen Standort für den neuen Postfachserver, in denen der Benutzer verschoben wird. Zeigen Sie das neue dedizierte virtuelle Verzeichnis, auf eine Empfängerrichtlinie mit die SMTP-Adresse, die der Benutzer hat.
• Fügen Sie in eine gemischte Sites oder reine Exchange Server 2000-Szenario die SMTP-Adresse aus der Standard-Empfängerrichtlinie der Empfängerrichtlinie, die für den verschobenen Benutzer gilt. Nachdem der Empfängeraktualisierungsdienst aktualisiert wurde, wird der Benutzer einen zusätzlichen SMTP-Proxy verfügen, der das virtuelle Standardverzeichnis jetzt entspricht.
• Manuell die richtige SMTP-Adresse für den verschobenen Benutzer hinzuzufügen

Exchange Server 2003 Service Pack 1 enthält ein Update, die es ermöglicht, die SMTP-Adresse in Anmeldungen implizite oder explizite Anmeldungen verwenden, um dieses Problem umgehen. Outlook Web Access funktioniert immer in den folgenden Szenarien, bei Verbindung mit einem Exchange Server 2003 Service Pack 1-basierten Server:

• implizite Anmeldung
  Geben Sie z. B. den URL für OWA-Zugriff in das folgende Format:
  http:// Server / exchange-
• explizite Anmeldung mithilfe der Benutzerprinzipalname (UPN) oder SMTP-Adresse
  Geben Sie z. B. den URL für OWA-Zugriff in das folgende Format:
  http:// server Server/Exchange/Benutzer @ Domain_Name. com

Wenn Sie versuchen, eine explizite Anmeldung mit den Alias des Benutzers und der Benutzer nicht über die SMTP-Adresse des virtuellen HTTP-Verzeichnis verfügt, wird die Anmeldung nicht abgeschlossen. Beispielsweise, wenn Sie den URL für OWA-Zugriff im folgenden Format eingeben: http:// Server Server/Exchange / User, Sie werden nicht auf Exchange Server-Postfach zugreifen. Dieses Problem tritt auf, wenn eine explizite Anmeldung mit dem Alias eines Benutzers für OWA verwendet wird und gilt nicht für Cross-administrative Gruppenszenarien.

Frei/Gebucht-Informationen und Ressourcenpostfächer

Frei / Gebucht-Informationen müssen re-published sein, nach dem Verschieben eines Postfachs Cross-Site. Für Benutzerpostfächer treten diese 15 Minuten nachdem der Benutzer Outlook für die Anmeldung an den Exchange-Server verwendet und der Benutzer eine Kalender-Aktion führt. Wenn der Benutzer genehmigt, entfernt oder eine Besprechungsanfrage erstellt, ist die Kalender Frei / Gebucht-Informationen beispielsweise 15 Minuten später veröffentlicht.

Der Besitzer der ein Ressourcenpostfach, z. B. einen Besprechungsraum muss öffnen Sie das Postfach und ein Kalender Aktion um die freie / Gebucht-Informationen zu re-publish führen.

Dieses Verhalten, weil es eine Frei/Gebucht-Nachricht für den Benutzer ?s neue LegacyExchangeDN -Attribut in der Zielsite nicht werden, aber Outlook ein Update nicht veröffentlichen, wird bis ein Kalender wird geändert, und dem Outlook ? lokalen eingeben Frei/Gebucht-Cache dirtied. Dieses Verhalten tritt auch auf, wenn Sie durch den Prozess GUIDGen System Standortordner zurücksetzen ausführen.

Oder das UpdateFB-Tool zum Automatisieren von diesem Prozess veröffentlichen Frei/Gebucht verwendet werden.

Weitere Informationen über das UpdateFB-Tool finden Sie die folgende KB-Artikelnummer:

Offlineadressbuch

Offline-Adressbuch herunterladen und Remotestandorte

Wenn ein Benutzer Outlook 2003 im zwischengespeicherten Modus an Remotestandorten mit Exchange Server 2003 oder eine frühere Version ausführt, müssen Sie sicherstellen, dass Sie ausreichende Bandbreite, um einen vollständigen Download des Offlineadressbuchs für alle Clients auf die Remotesite unterstützen können.

Remotestandorte über langsame Verbindungen

Wenn Postfächer, die Outlook 2003 im zwischengespeicherten Modus von einem Exchange Server 5.5-Remoteserver an einen zentralen Exchange 2003 SP1-Server, entweder über Standorte oder nicht verschoben werden, müssen eine vollständige Offlineadressbuch gedownloadet werden. Darüber hinaus werden wenn eine bedeutende Änderung in das Verzeichnis vorhanden ist oder wenn eine neue administrative Gruppe hinzugefügt oder entfernt wird, ein vollständiger Download des Offlineadressbuchs für Exchange-Cache-Modus Benutzer generiert. Daher müssen Remotestandorten sicherstellen, dass ausreichende Bandbreite zur Unterstützung einer vollständige Offlineadressbuch für alle Clients am Remotestandort vorhanden ist.

Weitere Informationen über vollständige Offlineadressbuch-downloads

In der Regel, Outlook-Clients werden nur ein Offlineadressbuch Diff download angezeigt. Dies ist eine kleine Teilmenge der vollständigen Download des Offlineadressbuchs, der nur Änderungen anstatt die vollständige globale Adressliste enthält. Es gibt jedoch Fälle, in dem Outlook-Clients das vollständige Offlineadressbuch zu downloaden müssen. Verfügt das Verzeichnis eine große Anzahl von Änderungen, z. B. viele neue Konten, Namensänderungen und vieles mehr oder eine neue Exchange-Administrator-Gruppe hinzugefügt oder entfernt, werden alle Clients, die im Exchange-Cache-Modus mit eine vollständige Offlineadressbuch aktualisiert. Darüber hinaus erhalten Clients, die von Exchange Server 5.5 auf einen neuen Exchange Server 2003-Server verschoben werden auch eine neue vollständige Offlineadressbuch.

Weitere Informationen zum Einschränken des downloads der Auswirkungen der vollständigen OAB in Exchange Server 2003, klicken Sie auf die folgende KB-Artikelnummer:

Verzeichnisaktualisierungen warten

Administratoren müssen Verzeichnisaktualisierungen erfolgen, bevor e-Mail-Nachrichten übertragen können, ohne einen Unzustellbarkeitsbericht (NDR) warten.

Bekannte Probleme: Verhalten nach Objekt Rehome

Nachrichtenübermittlung unter Exchange Server 5.5 und Exchange Server 2003 für Benutzer, die mailing-Listen Kontakt und Verteilung wirkt sich

Wenn Benutzer e-Mail-Nachrichten an Kontakt senden und Verteilerlisten während einer Cross administrativen Gruppe verschieben, während der ADC von Exchange Server 5.5-Verzeichnisobjekten bereinigen, gibt es eine Reihe von Nachrichtenübermittlung behandeln, die auftreten können.

Posteingangsregeln

Wenn die Verteilergruppe/Liste während einer Cross administrativen Gruppe re-homed ist verschieben Sie, Posteingangsregeln, die Nachrichten verarbeiten basierend auf der VERTEILERLISTE als Absender oder Empfänger funktioniert nicht für Postfächer, die gehostet werden auf Exchange-Servern, die älter als Exchange Server 2003 Service Pack 1 sind. Diese Regeln müssen neu erstellt werden, oder die Postfächer für die Regel müssen auf einem Server mit Exchange 2003 SP1 verschoben werden.

verschobene Öffentliche Ordner in der globalen Adressliste

Wenn eine Kontakt-Verteilerliste aufgenommen verlagert wird, kann er aus der globalen Adressliste in Exchange verschwinden Server 5.5 während der Zeit, die das ursprüngliche Exchange Server 5.5-Objekt in der alten Website ausgeblendet ist und bevor die neue Exchange Server 5.5-Objekt auf die neue Website aus dem Active Directory repliziert wurde. Re-Homed-Objekten in Active Directory, Exchange 2000 Server Global Address List oder der Exchange Server 2003 globalen Adressliste sind nicht betroffen.

Proxyadressen

Objekte, die re-homed sind behalten ihre ursprüngliche Proxyadressen von der alten Website. Jedoch werden Sie nicht erhalten neue Proxyadressen beim Cross-administrative Gruppe verschoben, wenn die Empfängerrichtlinie auf Administrative Gruppenmitgliedschaft basiert.

Der Empfängeraktualisierungsdienst wird nicht aktualisierten Proxys für das Objekt Zeitstempel, wenn das re-homed-Objekt bereits die gleiche Art von Proxys hat. Um eine neue Proxyadresse für eine Empfängerrichtlinie zu erhalten, die jetzt für das-Objekt auf Grundlage der neuen administrativen Gruppenmitgliedschaft gelten würden, klicken Sie auf jetzt anwenden der Empfängerrichtlinie, und erstellen Sie den Empfängeraktualisierungsdienst neu. Es wird empfohlen, dass Sie dies nicht tun, wenn es erforderlich ist, da dies die Leistung des Netzwerks auswirken kann.
Obwohl Proxyadressen nicht aktualisiert werden, werden E-mail-Nachrichtenfluss nicht beeinträchtigt. Jedoch, wenn Ihr System einige sehr spezielle Einschränkungsüberprüfung durchführt, können ein Problem auftreten, wenn die Adressen nicht aktualisiert werden. Gehen wir beispielsweise von folgendem Szenario aus:

• AG1 akzeptiert e-Mail-Nachrichten für domain1.com.
• AG2 akzeptiert e-Mail-Nachrichten für domain2.com.
• Der Connector, der die beiden administrativen Gruppen verbindet, lässt nicht jeder außerhalb der Organisation e-Mail-Nachrichten über ihn zu senden.
• Daher würde die e-Mail-Nachricht einen UNZUSTELLBARKEITSBERICHT generieren. Die e-Mail-Nachricht wird nicht über den Connector gesendet.

x. 500-Adressen werden durch überschrieben organisationsübergreifenden ADC in Kontakte, die Cross-Site verschoben

Betrachten Sie dieses Szenario. Eine organisationsübergreifende Verbindungsvereinbarung (CA) erstellt einen Kontakt in einer Organisation. Der Kontakt stellt Postfächer in einer anderen Organisation dar. Wenn der Kontakt verschoben wird Cross-Site, der ursprüngliche Verzeichnisnamen des Kontakts aus der Quellwebsite auf den verschobenen Kontakt in der Form eine x. 500-Adresse versehen. Jedoch, wenn das Postfach, das der Kontakt darstellt geändert wird, die Änderung wird zurück auf das verschobene Kontaktobjekt repliziert und der ADC überschreibt die x. 500-Adresse.

Verwenden Sie um dieses Problem zu umgehen, eine oder mehrere der folgenden Verfahren:

• Neukonfigurieren Sie den ADC Sie eine neue Website, und führen Sie das Tool alle x. 500-Adressen zu verlieren.
• Exportieren Sie die LegacyExchangeDNs von Exchange Server 5.5 vor dem Verschieben Cross-Site und importieren Sie die LegacyExchangeDNs als x. 500-Adressen für die Exchange Server 5.5-Postfächer.
• Wechseln Sie in den einheitlichen Exchange-Modus, und verschoben Sie die Kontakte nicht.

Warten Sie, den ADC zum Abschließen

Sie müssen für Active Directory für Exchange Server 5.5-Replikation, standortinternen Replikation und standortübergreifende Replikation abgeschlossen warten. E-Mail-Nachrichtenfluss und andere Operationen werden beeinflusst werden, bis die Exchange Server 5.5-Verzeichnisse synchronisiert werden, und der ADC ausgeführt wurde, um die Änderungen zu beheben.

Directory Service/Information Store-Konsistenzanpassung ausführen

Nach einer Verteilung Liste, die Zugriff auf einen Öffentlichen Ordner verschoben Cross-Site, führen Sie die Patches Directory Service/Information Store (DS / IS) Konsistenz Sachverständiger Tool, um sicherzustellen, dass die Verteilerliste weiterhin den öffentlichen Ordner zugreifen.