Das Verhalten beim Löschen und senden von Mails bei shared Postfächern steuern

Verwendet man eine shared-Mailbox fällt einem auf das wenn jemand eine Mail aus diesem Postfach versendet, diese nicht unter den gesendeten Mails des Postfach zu finden sind, sondern nun in dem des Sendenden. Genauso verhält es sich beim Löschen von Mails aus einer shared-Mailbox, die gelöschte Mail landet in der Mailbox desjenigen der sie gelöscht hat. Wenn mehrere Personen mit so einem Postfach arbeiten, wird es schwierig bestimmte Vorgange nachzuverfolgen.

Das zuvor beschriebene Verhalten ist als Standard zu verstehen und erstmal von seitens Microsoft auch so gewollt. Das ganze lässt sich aber über den Exchange selbst und Outlook steuern.

In der Exchange-Konsole lässt sich mit folgenden Befehlen das Verhalten vom senden so steuern, das gesendete Mails sowohl im gesendete Elemente Ordner der shared-Mailbox sowie in der des Sendenden landet.

Befehl für „Senden im Auftrag..“:
Set-Mailbox <Identity> -MessageCopyForSendOnBehalfEnabled $true

Befehl für „Senden als…“:
Set-Mailbox <Identity> -MessageCopyForSentAsEnabled $true

Das Verhalten beim löschen lässt sich dahingehend nur über Oulook selbst steuern, hierzu muss eine entsprechender Registry-Eintrag am System gesetzt werden:

Registry-Wert:
HKCU\SOFTWARE\Microsoft\Office\16.0\Outlook\Options\General

DelegateWastebasketStyle
REG_DWORD
Wert: 0x4 (4)

Hierbei macht es Sinn diesen Wert über Gruppenrichtlinien zu verteilen.


Posted in Exchange Server and tagged , , , , with comments disabled.

Fehler: RecipientNotFound-PermanentException: Error: Cannot find a recipient that has mailbox GUID „GUID“.

Über den im Titel genannten Fehler bin ich bei einer Migration eines Postfachs zu O365 gestolpert. Man findet hierzu bei Microsoft direkt einen KB-Eintrag, dieser beschäftigt sich aber mit dem „offboarding“, also dem verschieben des Postfachs von O365 zu on-Prem. Die im Beitrag genannten Befehle helfen aber schonmal das Problem weiter einzugrenzen.

Der Befehl Get-Mailbox <Identity> | fl ExchangeGuid in der lokalen Exchange-Console eingegeben zeigt uns die lokale ExchangeGuid an.

Der Befehl Get-MailUser <Identity>| fl ExchangeGuid in der Exchange Online Powershell zeigt uns nach erfolgreicher Verbindung die ExchangeGuid in der Microsoft Cloud an.

Hierbei fällt nun auf das beide Guids identisch sind und sich diese von der Guid aus der Fehlermeldung unterscheiden.

Woher kommt nun diese Guid? Bei dieser handelt es sich um die Guid des „Shared-Postfachs“ das automatisch in der Cloud angelegt wird, sobald das Benutzerkonto dorthin synchronisiert wurde. Dieses Postfach was in der Oberfläche nicht zu sehen ist, dient dem Austausch von Informationen zwischen dem Online- und dem on-Prem-Exchange.

Mithilfe der Exchange Online Powershell lässt sich die Guid sichtbar machen. Der Befehl hierfür lautet Get-MailboxLocation -Identity <SMTP-Adresse> | fl MailboxGuid. Diese ist mit der Guid aus der Fehlermeldung nun auch identisch.

LÖSUNG

Um das Postfach nun erfolgreich zu Migrieren, bin ich wie folgt vorgegangen:

  1. Entfernen der O365 Lizenz vom Benutzer
  2. Löschen des Benutzers im Azure-AD über Powershell*
  3. Entfernen des Benutzers aus dem Papierkorb in Azure-AD**
  4. Sync mit Azure-AD Connect durchgeführt
  5. Anlage des Benutzers im Online Portal geprüft
  6. Lizenz im Office-Portal dem Benutzer wieder zugewiesen
  7. Neuen Batchmigration Task angelegt und gestartet
  8. Fertig! (Migration erfolgreich)

WICHTIG: Im Anschluss ist es notwendig am Client des betroffenen Benutzers die Anmeldedaten (SSO) einmal in der Systemsteuerung zu entfernen. Zusätzlich kann es notwendig sein das Mailprofil neu zu erstellen.

*)Remove-MsolUser -UserPrincipalName <Identity>
**)Remove-MsolUser -UserPrincipalName <IDentity>
-RemoveFromRecycleBin

Links zu weiterführenden Informationen:
Exchange Online Powershell
Azure-AD Connect Powershell


Posted in Microsoft O365 and tagged , , , , with comments disabled.