Shared Mailbox

Wurden früher öffentliche Ordner als gemeinsame Ablage genutzt, so werden immer mehr "Shared Mailboxen" für Teamadressen etc. genutzt. Der große Vorteil ist, dass diese einfacher bezüglich der Rechte zu verwalten sind, als eigene Mailbox leichter betrieben werden können und vor allem es sich um eine Mailbox mit Platz für Kontakte, Termine und vor allem "Sent Items" hat. Wenn also eine Mail an so ein Postfach ankommt und ein berechtigter Anwender diese beantwortet, dann kann die Mail gleich in "Gesendete Objekte" dieser Mailbox abgelegt werden. Zudem wird die Mailbox per Autodiscover bei Bedarf gleich mit eingebunden.

Update: Sommer 2019: Outlook for Mobile Devices werden Shared Mailboxes unterstützen. Allerdings nur mit Exchange Online, da dabei weder ActiveSync, EWS noch REST sondern die eigene Synchronisierungs-API zum Einsatz kommt.

Shared Mailbox und AD-Benutzer und Lizenz

Exchange 2010 kennt neben den Postfächern, die einem Mensch zugeordnet werden auch verschiedene andere Postfacharten, die generischer Natur sind. Dazu zählen:

  • Räume
  • Ressourcen
  • Gemeinsame Postfächer

Allen gemeinsam ist, dass Exchange für diese Objekte in der Postfachdatenbank natürlich auch ein AD-Konto vom Typ "User" benötigt. Um hier aber keine Hintertür zu öffnen sind diese Benutzer per Default "deaktiviert". Sie können also nicht zur interaktiven Anmeldung genutzt werden. Dies sollte auch so bleiben !

“A shared mailbox is a type of User mailbox that doesn’t have its own User name and password. As a result, Users can’t log into it them directly.”
Quelle: https://technet.microsoft.com/en-us/library/mt577278(v=exchg.160).aspx

A shared mailbox doesn't have its own User name and password like a User mailbox does. You can't sign in to a shared mailbox directly using Outlook, Outlook Web App, Exchange ActiveSync, Exchange Web Services (EWS), or any other Exchange protocol. You must first be granted permissions to the shared mailbox, and then you access (open) it by using Outlook or Outlook Web App”. Furthermore we read : “Shared mailboxes aren't supported on mobile devices.”
Quelle: https://technet.microsoft.com/en-us/library/jj966275(v=exchg.150).aspx

Bezüglich der Lizenz sind diese Postfächer neutral, d.h. Sie kosten nichts extra. In Office 365 müssen Sie diesem Benutzer auch keine Lizenz zuweisen.

Beachten Sie, das Office 365 ein falsch konfiguriertes Postfach nach Ablauf der "Grace-Period" einfach löscht. Aktivieren Sie also eine Shared Mailbox" nicht, um sich mit einem Dienst wie z.B. CRM oder Helpdesk zu verbinden. Dann ist es eine normaler Mailbox, der eine Lizenz zugewiesen sein muss.

Shared Mailbox OnPremises

Die Einrichtung einer solchen "Shared Mailbox" ist recht einfach über die Exchange PowerShell, die Exchange Management Console oder das Exchange Control Panel (Ab Exchange 2013) möglich:

Bei der Anlage werden nur ganz wenige Daten erfragt:

Die Berechtigungen werden per Browser dann in einem zweiten Schritt vergeben.

Shared Mailbox in Office 365

Siehe dazu auch die Seite Remote Shared Mailbox

Auch in Office 365 gibt es einen eigenen Punkt zur Anlage der Shared Mailboxen. Der sieht aber fast genau so aus wie bei Exchange 2013 On-Prem. Wobei bei Office 365 im Februar 2015 schon die berechtigten Personen gleich mit angegeben werden konnten:

Das war On-Premises noch nicht möglich, aber dürfte mit einem Update sicher bald auch so sein. Hier ist aber Anfang 2015 auch das erste mal die Funktion aufgetaucht, ein normales Postfach nachträglich in eine Shared Mailbox per ECP zu konvertieren.

Damit können Sie in Office 365 nun z.B. auch alte Postfächer von ausgeschiedenen Mitarbeitern unter Berücksichtigung einiger Randbedingungen(z.B. DirSync darf das AD-Konto nicht löschen) in eine Shared Mailbox wandeln.

Eine Shared Mailbox benötigt keine Office 365 Lizenz, darf aber maximal 50 GB groß sein (Stand Feb 2017). Früher war das Limit bei 10 GB. Wenn Sie eine Office 365 Lizenz zuweisen, sind auch bis 100 GB erlaubt. Mehr ist nicht supportet.

Sie sollten aber doch ihre Datenhaltung überprüfen, wenn Sie 50/100GB in einer Mailbox ablegen. Lassen Sie uns darüber sprechen:
Net at Work

Umgekehrt geht es natürlich auch wieder:

Shared Mailbox in AutoDiscover und Automapping

Wenn eine Shared Mailbox eingerichtet wird, dann werden in der Regel auch Personen benannt, die diese Mailbox verwenden können. Je nach Konfiguration kann dabei bestimmt werden, dass diese Personen das Postfach automatisch zusätzlich eingebunden bekommen. Outlook "sieht" dann diese "Alternate Mailbox" als weiteren Eintrag im Autodisdover.XML

In der ersten Karteikarte der "Ergebnisse" sind diese Einträge nicht zu sehen. Sie müssen schon in der XML suchen. Der Type "Delegate" zeigt ihnen an, dass es eine Shared Mailbox (Room, Ressource oder Shared) ist. Oben drüber sehen Sie einen ähnlichen Eintrag, der aber der Verweis auf mein Online-Archiv ist.

Ob eine Shared Mailbox bei einem Benutzer automatisch eingebunden wird oder nicht, wird bei der Einrichtung der Berechtigung gesteuert.

Add-MailboxPermission `
   -Identity shared1@msxfaq.de `
   -User User1@msxfaq.de `
   -AccessRights FullAccess `
   -AutoMapping:$false

Wenn der Benutzer schon das Recht hatte, dann entfernen Sie das Recht mit "Remove-Mailboxpermission" und addieren sie es dann wieder. Microsoft hat selbst einen Beispielcode dafür veröffentlicht:

# Quelle: https://technet.microsoft.com/en-us/library/hh529943.aspx
$FixAutoMapping = Get-MailboxPermission sharedmailbox `
   | where {$_.AccessRights -eq "FullAccess" -and $_.IsInherited -eq $false}
$FixAutoMapping `
   | Remove-MailboxPermission
$FixAutoMapping `
   | ForEach { `
        Add-MailboxPermission `
           -Identity $_.Identity `
           -User $_.User `
           -AccessRights:FullAccess  `
           -AutoMapping $false
     }

Das "Automapping" ist genau genommen gar kein Recht, sondern in dem Beispiel wird beim "User1" die Mailbox "shared1" im LDAP-Feld eingetragen. Wie sonst sollte Exchange so schnell ansonsten ermitteln, auf welche Postfächer der Benutzer "User1" noch alles Rechte hat. Genau genommen sind zwei Felder hier interessant:

Feldname  

MSExchDelegateListLink

Wenn Sie per Exchange Management Console oder Shell einem Benutzer "Vollzugriff" geben, dann wird bei der SharedMailbox diesese Feld beschrieben. Das Feld enthält den DN des berechtigten Benutzers.

msExchDelegateListBL

Damit Exchange aber schneller zu einem Benutzer auch die Liste der Postfächer ermitteln kann, sind dieses als "Backlink"-Attribut beim Benutzer der die Rechte erhalten hat, verlinkt. Backlink-Attribute sind "berechnete" Werte und können nicht geändert werden.

PublicDelegates

Diese Feld wird beim Benutzer gepflegt, der einen einem anderen Benutzer z.B. über Outlook zum Stellvertreter hochstuft.

All diese Felder helfen Exchange bei Autodiscover dem Stellvertreter das alternative Postfach mit einzubinden. Es ist aber natürlich kein Ersatz für die erforderlichen Berechtigungen.

Übrigens können diese Felder auch Autodiscover stören, wenn die Inhalte auf nicht mehr existente Postfächer verweisen.

# Anzeige der User, die Stellvertreter sine
Import-Module ActiveDirectory
Get-ADUser <Username> -Properties msExchDelegateListBL

# Liste leeren
Set-ADUser <User> -Clear msExchDelegateListLink

Berechtigung über Gruppen

Normalerweise werden auf eine Shared Mailbox immer nur Personen berechtigt. Wie im vorigen Abschnitt zu sehen ist, hat das auch eine Auswirkung auf die automatische Einbindung der Shared Mailbox in das Profil eines Anwenders. Aus Sicht von Exchange ist eine Shared Mailbox aber auch erst mal nur eine Mailbox mit Berechtigungen und natürlich können Sie auch alle anderen Möglichkeiten nutzen, hier Berechtigungen zu vergeben. Sie können per EWS und Impersonation arbeiten oder auch Berechtigungen an Gruppen vergeben.

Allerdings werden z.B. die Mitglieder der Gruppe dann diese "Shared Mailbox" nicht automatisch in ihrem Profile per "Automapping" eingebunden bekommen, da der entsprechende Eintrag im Feld "msExchDelegateListLink " fehlt. Den könnten Sie dann wieder per Skript nachführen, aber so ein Skript müsste dann immer wieder laufen, wenn jemand in eine Gruppe addiert oder entfernt wird, die in einer Shared Mailbox als Berechtigungsgruppe eingebunden ist.

Je kleiner eine Firma ist, desto weniger Know-How ist für den Betrieb eines solchen Skripts vorhanden. Hier sollten Sie dann doch besser die Personen direkt berechtigen. Größere Firmen mit einem Provisioning können hingegen auf ein regelmäßig gestarteten "Fix-Skript" verzichten, wenn Sie die Mitgliedschaften von Gruppen schon automatisieren und in dem Zuge dann auch die Einträge bezüglich der Shared Mailbox addieren.

"Dynamische Gruppen" funktionieren allerdings gar nicht, da diese keine SID haben und für Berechtigungen nicht taugen. Sie können nur als Mail-Verteiler genutzt werden. Daher habe ich ja mein Skript Tools: Querybased Security Group vor vielen Jahren entwickelt um Mitgliedschaften von Sicherheitsgruppen automatisch zu pflegen. Allerdings wäre da dann auch wieder um das Automapping zu erweitern, wenn Berechtigungsgruppen von Shared Mailboxen verwaltet werden.

Ablage von "Gesendete Objekte"

Wenn ein Benutzer als anderer Anwender sendet, dann ist es erwünscht, dass die versendeten Mails nicht im Postfach des Benutzers sondern in „Gesendete Objekte“ des Funktionspostfachs abgelegt werden. Diese Funktion kann nicht auf dem Server sondern muss in Outlook eingestellt werden. Dazu ist eine Mindestversion von Outlook 2012 (14.0.5126.5000 enthalten in Hotfix  KB2459115 oder neuer) auf dem Client vorhanden sein. Durch folgenden Registrierungsschlüssel wird das Verhalten eingestellt:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Microsoft\Office\14.0\Outlook\Preferences]
"DelegateSentItemsStyle"=dword:1

Voraussetzung ist weiterhin natürlich dass der Benutzer auch das Recht habt, in den Ordner des Funktionspostfachs zu schreiben. Bei einem einfachen "SendAs" reicht dieser Eintrag alleine nicht aus.

Mittlerweile kann aber auch der Exchange Server selbst die Mail gleich in das "richtige" Postfach verschieben. Die Konfiguration erfolgt nun per Powershell und ist der Methode mit dem Registrykey vorzuziehen

#Exchange 2010 ab SP2 RU4
Set-MailboxSentItemsConfiguration "SharedMailbox" `
   -SendAsItemsCopiedTo [Sender|From|SenderAndFrom] `
   -SendOnBehalfOfItemsCopiedTo [Sender|From|SenderAndFrom]
#Exchange 2013 ab CU9 und 2016
Set-Mailbox "SharedMailbox" `
   -MessageCopyForSentAsEnabled $true `
   -MessageCopyForSendOnBehalfEnabled $true

Calendarprocessing: AutoAccept vs AutoUpdate

Eine Shared Mailbox hat natürlich auch einen Kalender. Allerdings wird er, anders als bei Räumen, in der Regen nicht über Einladungen adressiert. Sicher können Anwender in dem Postfach Termine eintragen. Die Standardeinstellung einer Shared Mailbox ist aber ein "AutoUpdate".

PS C:\> Get-CalendarProcessing Shared1 | fl RecipientTypeDetails,AutomateProcessing,DeleteNonCalendarItems
 
Recipient Type         : SharedMailbox
AutomateProcessing     : AutoUpdate
DeleteNonCalendarItems : True

Damit ist sichergestellt, dass Aktualisierungen automatisch angewendet werden. In dem Zuge ist der Parameter "DeleteNonCalendarItems" noch interessant, der bei einer SharedMailbox nicht aktiv wird. Dieser Schalter sorgt aber bei Räumen dafür, dass Terminanfragen verarbeitet werden aber alle anderen Mails, die für einen Raum nicht relevant sind, direkt gelöscht werden. Bei einem Raum sieht das dann so aus

PS C:\> Get-CalendarProcessing Raum1 | fl RecipientTypeDetails,AutomateProcessing,DeleteNonCalendarItems
 
Recipient Type         : RoomMailbox
AutomateProcessing     : AutoAccept
DeleteNonCalendarItems : True

Ein Raum nimmt Termine an aber löscht auch die Einträge.

Achtung
Wenn Sie nachträglich aus einem Raum eine "Shared Mailbox" machen, dann steht das Commandlet nur den Typ um. Es ändert aber nicht den Wert bei "AutomateProcessing". Sie haben dann eine Shared Mailbox, bei der alle eingehenden Mails sofort gelöscht werden

Die Lösung ist einfach durch einen zusätzlichen Aufruf zu schaffen:

Set-CalendarProcessing `
   -identtiy Shared1 `
   -AutomateProcessing AutoUpdate

Eine SharedMailbox sollte immer auf "AutoUpdate" stehen. Wenn Sie tatsächlich auch eine SharedMailbox auf "AutoAccept" stellen wollen, dann sollten Sie das Löschen aller anderen Mails vielleicht unterbinden:

Set-CalendarProcessing `
   -identtiy Shared1 `
   -AutomateProcessing AutoAccept `
   -DeleteNonCalendarItems $false

Cached Mode für Shared Postfächer

Die meisten Firmen nutzen Outlook im Cached Mode. Der CachedMode sorgt dafür, dass der Server durch Regelanfragen entlastet wird, indem Informationen „lokal“ in einer OST-Datei als Cache abgelegt werden. Outlook bedient dann die meisten Anfragen lokal, z.B. die Anzeige in Kontakten und Kalendern, die ansonsten viel Netzwerklast und noch mehr Serverlast bedeuten würden. Besonders für die Niederlassungen über WAN ist der Cached Mode wichtig um die zentrale Funktion bereit zu stellen. Auch mit Office 365 profitieren sowohl der Anwender durch schnellere Antwortzeiten und Microsoft durch geringere Netzwerklast und Serverlast von diesem Mechanismus.

Outlook repliziert im Hintergrund aber per Default nicht nur das eigene Postfach, sondern auch die „Shared Mailboxen“. Das klingt im ersten Moment sinnvoll, da damit auch der Zugriff auf diese Daten beschleunigt wird aber "Shared Mailboxen" werden aber naturgemäß von mehreren Personen verwendet und hier kann die Verzögerung durch die Replikation zu Rückfragen führen.

Wenn zwei Personen in der gleichen Shared Mailbox arbeiten und ein Anwender z.B. einen Ordner löscht oder eine Mail verschiebt, dann „sieht“ der andere Anwender dies nicht sofort, sondern erst nachdem das Outlook des ändernden Benutzers die Daten zum Server hin und der andere diese Änderungen wieder herunter repliziert hat.

Erst mit Outlook 2007SP1 Hotfix Sep2008 wurde es überhaupt möglich, per Registrierung einen CachedMode für andere Mailboxen aktivieren. Bei Outlook 2010 hingegen ist der Cache für andere Postfächer per Default aktiv. Diese Einstellung ist pro Benutzer auf dem Client einstellbar. Insofern kann die Einstellung nach Standort angepasst werden, z.B.:

  • alle Clients mit breitbandiger Verbindung müssen die Shared Mailboxen nicht cachen
  • alle Clients in Niederlassung sollten besser cachen, um die Antwortzeit zu erhalten

Es könnte aber genauso sinnvoll sein, in der Zentrale mit schneller Replikation den Cache zu nutzen und in Niederlassungen zugunsten der Aktualität auf den Cache für weitere Mailboxen zu verzichten. Leider kann dieses Verhalten nicht pro Mailbox oder Ordner sondern nur global für den Client und User konfiguriert werden.

Hinweis: Der Cache für die eigene Mailbox steht nicht zur Diskussion.

Folgende Schlüssel berücksichtigt Outlook:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Microsoft\Office\14.0\Outlook\Cached Mode]
"CacheOthersMail"=dword:00000000

[HKEY_CURRENT_User\Software\Policies\Microsoft\Office\14.0\Outlook\Cached Mode}
"CacheOthersMail"=dword:00000000

Die Einstellung sollte per Gruppenrichtlinie mit der aktuellen ADMX-Vorlage erfolgen:

Shared Mailbox und SMIME

Die Nutzung von Shared Mailboxen bietet sich für eine unpersönliche Kommunikation mit externen Partnern an. Das kann eine "support@" oder "info@" oder auch "security@"-Adresse in einer Firma sein. Damit nun alle legitimen Benutzer der Shared Mailbox natürlich auch signierte Mails empfangen können, müssen Sie nicht nur auf die Shared Mailbox berechtigt sein, sondern auch den privaten Schlüssel vorhanden. Ohne ein passendes SMIME-Gateway zur Entschlüsselung müssen Sie bei allen berechtigten Anwendern den passenden Schlüssel lokal installieren. Es gelten die bekannten Einschränkungen von lokal verteilten Schlüsseln (Siehe auch Verschlüsseln und Signieren auf dem Gateway - Vorteile) Hier wächst aber nun noch das Risiko, dass der private Schlüssel auf vielen Endgeräten vorliegt und nicht an eine Person gebunden ist. Ein "Export" um dann mit dem Konto zu versenden. ist kritisch

Innerhalb von Exchange ist ja geregelt, dass niemand ohne Rechte mit einer fremden Mailadresse senden kann. Berechtigte Anwender können per Outlook aber sehr einfach die "From-Adresse" auswählen.

Outlook kümmerst sich dann schon um die Signatur und Verschlüsselung. Sie müssen eben nur ein passendes Zertifikat für auch diese Absenderadresse vorweisen können.

Shared Mailbox und POP3

Eigentlich ist es eher ein ungewöhnlicher Fall, aber sie können auch per POP3 auf eine Shared Mailbox zugreifen und sogar per SMTP im Namen der Shared Mailbox senden. Wer auf eine Shared Mailbox per POP oder IMAP zugreifen will, muss aber einige Eckpunkte beachten:

  • Shared Mailbox Konto ist deaktiviert
    Das AD-Konto zur Shared Mailbox sollte wie bisher deaktiviert sein
  • Kein POP3-Allow für Shared Mailbox
    Auf dem Postfach der Shared Mailbox muss POP3 oder IMAP nicht per Set-CASMailbox erlaubt werden. Es kann und sollte deaktiviert bleiben.
  • Zugreifende Konto braucht Full-Access auf Shared Mailbox
    Das zugreifende Konto muss natürlich Rechte auf das Postfach haben. Ich habe noch nicht probiert, ob vielleicht auch Autor auf der "Inbox" reicht und wie bei IMAP4 abgestufte Rechte im Postfach sich auswirken. Ich würde aber nicht drauf setzen.
  • zugreifende Konto braucht Postfach und damit eine Lizenz
    Es reicht nicht, wenn Sie ein AD-Konto haben, welches Full-Access auf die Shared Mailbox hat aber selbst kein Postfach hat. Wenn Sie statt POP3 den Zugriff per EWS machen, dann ist für ein Dienstkonto kein Postfach erforderlich.
  • zugreifende Konto braucht POP3-Rechte
    Das zugreifende Konto muss mittels "Set-CASMailbox" für die Verwendung von POP3 bzw. IMAP4 freigeschaltet werden. Der POP3/IMAP4-Service prüft also anhand des angemeldeten Benutzers die Zugriffsberechtigungen zum Protokoll. Es reicht auch nicht einem AD-Konto ohne Postfach über das LDAP-Feld "ProtocolSettings" die POP3-rechte zu geben. Exchange ignoriert diese Einstellung.
  • zugreifende Konto muss sich richtig anmelden
    Und hier gibt es mehrere Schreibweisen:

Die Rechte können Sie also wie folgt zusammenfassen

# Zuweisen der Rechte für Shared Mailbox Access per POP3
Add-Mailboxpermission `
   -identity SharedMailbox `
   -User Domain\DelegateUser `
   -AccessRights FullAccess


# Zuweisen der Rechte, dass sie auch Als Shared Mailbox senden können
Get-mailbox `
   -identity SharedMailbox `
| Add-ADPermission  `
   -User "Domain\DelegateUser " `
   -ExtendedRights "Send As"

Set-CASMailbox `
   -identity "Domain\DelegateUser" `
   -pop3enabled $true

Wenn Sie dann auf dem POP3 sogar noch die "Plaintext"-Authentication aktiviert haben, können Sie per TELNET den POP3-Zugriff durchspielen. Sie sollten sich aber eine der vier möglichen Schreibweisen auswählen:

User domain/delegateUseralias/principalalias 
User domain/delegateUseralias/principalupn 
User delegateUserupn/principalalias 
User delegateUserupn/principalupn

Beachten Sie den "/" und nicht "\" zu nutzen

telnet pop3.msxfaq.de 110
  User DOMAIN/DelegateUser/sharedmailsboxalias
PASS geheim
LIST
RETR 1
QUIT

Besser finde ich natürlich den Zugriff per EWS.

Weitere Links