Freigeben über

Wiederherstellen, wenn ein Postfach sowohl in Exchange Online als auch lokal vorhanden ist

  • Gilt für:: Exchange Online, Exchange Server 2019, Exchange Server 2016, Exchange Server 2013

Beschreibung

In einer Microsoft Exchange Server Hybridbereitstellung kann ein Benutzer sowohl in Exchange Online als auch in einem lokalen Exchange-organization über ein Postfach verfügen. Dies ist kein gewünschter Zustand für eine Hybrid-organization, da dadurch Probleme mit dem Nachrichtenfluss entstehen. In diesem Fall werden Nachrichten an das Postfach übermittelt, das dem Speicherort des Absenders entspricht. Wenn sich der Absender in Ihrem lokalen organization befindet, werden Nachrichten an das lokale Postfach übermittelt. Wenn sich der Absender in Ihrem Exchange Online Mandanten befindet, werden Nachrichten an das Exchange Online Postfach übermittelt.

Wie kann man die Situation verbessern?

Um dieses E-Mail-Flussproblem zu beheben, empfehlen wir Ihnen, auf die in diesem Artikel beschriebenen Methoden zu verweisen. Andere mögliche Optionen verwenden Wiederherstellungsmethoden, die nicht garantiert funktionieren. Da Sich Microsoft 365 weiterentwickelt und neue Features hinzugefügt werden, können zusätzliche Optionen möglich sein. Dieser Artikel wird aktualisiert, um zusätzliche Korrekturmethoden zu berücksichtigen, sobald sie verfügbar sind.

Szenario 1: Beibehalten Exchange Online Postfachs

Dieses Szenario wäre am besten geeignet, wenn das Benutzerpostfach zuvor zu Exchange Online migriert wurde und irgendwie die Verbindung mit dem alten Postfach wiederhergestellt oder ein neues Postfach lokal bereitgestellt wurde. Ein weiteres mögliches Szenario ist, dass eine Exchange Online-Lizenz vorzeitig zugewiesen wird und ein neues reines Cloudpostfach erstellt wird, während der Benutzer bereits über ein vorhandenes Postfach in Exchange lokal verfügt. Lesen Sie unbedingt den wichtigen Hinweis am Ende von Schritt 8.

Führen Sie die folgenden Schritte aus, um diese Methode zu verwenden:

  1. Öffnen Sie die Exchange-Verwaltungsshell, und speichern Sie die Informationen des lokalen Postfachs in einer Datei, z. B. "SMTP-Adressen", "Legacy Exchange DN", "Exchange-Attribute" usw.

  2. Legen Sie den PowerShell-Format-Enumerationsgrenzwert auf "unbegrenzt" fest, um sicherzustellen, dass keine Attributwerte abgeschnitten werden. Beispiel:

    $formatenumerationlimit = -1
Get-Mailbox "mailbox identity" | fl > mailboxinfo.txt

  3. Trennen Sie das lokale Postfach:

    Disable-Mailbox "mailbox identity"

  4. Aktivieren Sie den lokalen Benutzer als Remotepostfach:

    Enable-RemoteMailbox "user identity" -RemoteRoutingAddress "user@contoso.mail.onmicrosoft.com"

  5. Stellen Sie alle benutzerdefinierten Proxyadressen und alle anderen Exchange Server Attribute wieder her, die beim Deaktivieren des Postfachs entfernt wurden (im Vergleich zum Get-Mailbox Cmdlet aus Schritt 2).

  6. Fügen Sie den LegacyExchangeDN Wert des vorherigen lokalen Postfachs der Proxyadresse des neuen Remotepostfachs als x500-Adresse hinzu. Führen Sie dazu das folgenden Cmdlet aus:

    Hinweis

    Der Wert des LegacyExchangeDN Parameters befindet sich in der Datei, die in Schritt 2 gespeichert wurde.

    Set-RemoteMailbox -Identity "user identity" -EmailAddresses @{add="x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=<user identity>"}

  7. Sammeln Sie die GUIDs der Postfächer und Der Datenbank:

    • Verwenden Sie zum Abrufen der GUID des getrennten Postfachs den Wert des ExchangeGUID Parameters aus der Datei, die in Schritt 2 gespeichert wurde.

    • Um die GUID der lokalen Datenbank abzurufen, verwenden Sie den Wert des Database Parameters aus der Datei, die in Schritt 2 gespeichert wurde, und führen Sie dann das folgende Cmdlet aus:

      Get-MailboxDatabase "database identity" | fl *GUID*

    • Führen Sie das folgende Cmdlet mit Exchange Online PowerShell aus, um die GUID des Cloudpostfachs abzurufen:

      Get-Mailbox "user identity" | fl *ExchangeGUID*

  8. (Optional) Stempeln Sie die Exchange Online GUID für das Remotepostfach mithilfe der Exchange-Verwaltungsshell (erforderlich, wenn Sie das Onboarding des Postfachs auf die lokale Umgebung beenden möchten).

    Set-RemoteMailbox "user identity" -ExchangeGuid "Exchange guid value of Exchange Online mailbox"

  9. Stellen Sie den Inhalt des getrennten Postfachs mithilfe von Exchange Online PowerShell in Exchange Online wieder her. Für die Anmeldeinformationen müssen Sie ein lokales Exchange-Administratorkonto angeben. Um eine Remotewiederherstellung durchführen zu können, muss der Administrator über eine der folgenden Bedingungen verfügen:

    • Es muss Mitglied der Gruppe der Domänenadministratoren in Active Directory Domain Services (AD DS) in der lokalen Organisation sein.
    • Das Konto muss Mitglied der Gruppe der Exchange-Empfängeradministratoren in Active Directory in der lokalen Organisation sein.
    • Mitglied der Gruppe Organisationsverwaltung oder Empfängerverwaltung in Exchange Server 2013 oder höher.
    $cred = Get-Credential
New-MailboxRestoreRequest -RemoteHostName "mail.contoso.com" -RemoteCredential $cred -SourceStoreMailbox "exchange guid of disconnected mailbox" -TargetMailbox "exchange guid of cloud mailbox" -RemoteDatabaseGuid "guid of on-premises database" -RemoteRestoreType DisconnectedMailbox

    Hinweis

    Die Remotewiederherstellung wird für Exchange Server 2010 nicht unterstützt. Die unterstützte Mindestversion ist Exchange Server 2013.

Wichtig

Da New-MailboxRestoreRequest für die Arbeit in einem einzelnen Exchange Server organization konzipiert wurde, schlagen die standortübergreifenden Wiederherstellungsaufträge aufgrund eines unvermeidbaren Konflikts zwischen dem ExchangeGuid-Quell- und Zielpostfach fehl. Die Postfachwiederherstellungsanforderung endet mit status "FailedOther", und der Bericht (von Get-MailboxRestoreRequestStatistics -IncludeReport) zeigt die folgende Fehlermeldung im endgültigen Berichtseintrag an:

Get-MailboxRestoreRequest "<mailbox's ID>" | `
Get-MailboxRestoreRequestStatistics -IncludeReport | `
select -ExpandProperty Report | `
select -ExpandProperty Entries | `
select -Last 2 | `
select -Last 1

CreationTime               : mmmm/dddd/yyyy 12:16:36 AM
ServerName                 : YTBPR01MB4016
Type                       : Error
TypeInt                    : 4
Flags                      : Failure, Fatal
FlagsInt                   : 18
Message                    : Fatal error RecipientNotFoundPermanentException has occurred.
MessageData                : {0, 1, 0, 0...}
MessageBytes               : {10, 29, 70, 97...}
Failure                    : RecipientNotFoundPermanentException: Cannot find a recipient that has mailbox
                             GUID '2ed5d0ca-54e2-4226-xxxx-a48848e18c0f'.
BadItem                    :
ConfigObject               :
MailboxSize                :
SessionStatistics          :
ArchiveSessionStatistics   :
MailboxVerificationResults : {}
DivergenceFixupResults     : {}
DebugData                  :
Connectivity               :
SourceThrottleDurations    :
TargetThrottleDurations    :
UnknownElements            :
UnknownAttributes          :
XmlSchemaType              :
LocalizedString            : mmmm/dddd/yyyy 12:16:36 AM [YTBPR01MB4016] Fatal error
                             RecipientNotFoundPermanentException has occurred.
Identity                   :
IsValid                    : True
ObjectState                : New

Dieser Fehler kann ignoriert werden, und der Auftrag wird stattdessen als erfolgreich behandelt, solange der vorletzte Eintrag im Bericht die richtige Anzahl der kopierten Elemente anzeigt (z. B. Kopierfortschritt: 5000/5000 Nachrichten, 2,34 GB/2,34 GB). Beispiel:

Get-MailboxRestoreRequest "<mailbox's ID>" | `
Get-MailboxRestoreRequestStatistics -IncludeReport | `
select -ExpandProperty Report | `
select -ExpandProperty Entries | `
select -Last 2 | `
select -First 1

CreationTime               : mmmm/dddd/yyyy 12:16:36 AM
ServerName                 : YTBPR01MB4016
Type                       : Informational
TypeInt                    : 0
Flags                      : None
FlagsInt                   : 0
Message                    : Copy progress: 799/799 messages, 25 MB (26,215,094 bytes)/25 MB (26,215,094
                             bytes), 0/0 folders completed.
MessageData                : {0, 1, 0, 0...}
MessageBytes               : {10, 68, 67, 111...}
Failure                    :
BadItem                    :
ConfigObject               :
MailboxSize                :
SessionStatistics          :
ArchiveSessionStatistics   :
MailboxVerificationResults : {}
DivergenceFixupResults     : {}
DebugData                  :
Connectivity               :
SourceThrottleDurations    :
TargetThrottleDurations    :
UnknownElements            :
UnknownAttributes          :
XmlSchemaType              :
LocalizedString            : mmmm/dddd/yyyy 12:16:36 AM [YTBPR01MB4016] Copy progress: 799/799 messages, 25 MB
                             (26,215,094 bytes)/25 MB (26,215,094 bytes), 0/0 folders completed.

Alle Elemente, die in den Eigenschaften BadItemsEncountered, LargeItemsEncountered oder MissingItemsEncountered (von Get-MailboxRestoreRequestStatistics) gemeldet werden, sollten normal behandelt werden, da diese gefunden worden wären, unabhängig davon, ob das Postfach über Migrationsbatch/Verschiebungsanforderung oder über New-MailboxRestoreRequest migriert wurde.

Szenario 2: Entfernen Exchange Online Postfachdaten

Die Postfachinformationen in Microsoft 365 werden möglicherweise nicht mehr benötigt. Weitere Informationen zum vollständigen Entfernen der Exchange Online Postfachinformationen finden Sie in diesem Exchange-Teamblogartikel.