Manchmal sieht man den Wald ja vor lauter Bäumen nicht, in diesem Fall hat mich folgendes Problem auf das Glatteis geführt.
Ein Benutzer berichtet, dass er zwar Elemente in einem freigegebenen Kalender eines Kollegen anlegen, aber die Einträge nicht mehr löschen kann. Beim Versuch einen Kalendereintrag zu löschen, zeigt Outlook nur die folgende Fehlermeldung:
Das Element kann nicht verschoben werden. Es wurde entweder bereits verschoben oder gelöscht, oder der Zugriff wurde verweigert.
Hört sich ja ziemlich eindeutig an: Zugriff verweigert. Also einmal die Rechte auf den Kalender des Kollegen prüfen, geht ja schnell mit der Shell (exemplarisch):
Get-MailboxFolderPermission frank:\kalender
Der Screenshot dient als Beispiel, allerdings hab ich erst einmal etwas verdutzt geguckt: Ein “Editor / Bearbeiter” hat doch das Recht Elemente zu löschen, oder nicht?
Hier hat dann mein Baum/Wald Problem begonnen… Der Benutzer hat also offensichtlich die Rechte “Alle Elemente löschen” für den Kalender, trotzdem zeigt Outlook eine Fehlermeldung die irgendwie was mit “Zugriff verweigert” enthält.
Nach einer gewissen, durchaus etwas längeren, Zeitspanne ist mir dann aufgefallen, dass der Benutzer ein zusätzliches Postfach verbunden hat, auf welches er Vollzugriff hat. Ungefähr so:
Hier klappt das Löschen natürlich einwandfrei, ohne Fehlermeldung, nur in dem zusätzlichen Kalender aus einem anderen Postfach wird die Fehlermeldung angezeigt und kann nicht gelöscht werden.
Bis ich endlich aus dem Wald gefunden habe, vergeht noch einmal etwas Zeit…
Ursache in dieser Konstellation: In der Registry (HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Options\General) des Benutzers wurde das DWORD “DelegateWastebasketStyle” auf den Wert “4” geändert, welches bewirkt, dass Elemente die in freigegeben Postfächern gelöscht werden im Ordner des Postfachbesitzers gespeichert werden.
Der Standard ist also wie folgt, wenn ein Benutzer ein Element in einem freigegeben Postfach löscht:
Benutzer “Frank” greift auf das freigegebene Postfach von “A” zu und löscht im Posteingang eine Mail. Die Mail wird dann in den Ordner “Gelöschte Elemente” von Frank verschoben.
Der oben genannte Registry Schlüssel bewirkt nun folgendes:
Benutzer “Frank” greift auf das freigegebene Postfach von “A” zu und löscht im Posteingang eine Mail. Die Mail wird dann in den Ordner “Gelöschte Elemente” des Postfachbesitzers A verschoben.
Für den zusätzlich freigegebenen Kalender greift nun ebenfalls der Registry Eintrag “DelegateWastebasketStyle”. Das Element in dem Kalender des Kollegen W, wird bei der Löschaktion des Benutzers in den Ordner “Gelöschte Elemente” von W verschoben:
In diesem Fall hat aber Benutzer “Frank” keine Rechte auf den Ordner “Gelöschte Elemente” von W, sondern nur nur Bearbeiter-Rechte auf den Kalender:
Das Element was “Frank” versucht im Kalender von “W” zu löschen, kann also nicht in den Ordner “Gelöschte Elemente” von “W” verschoben werden, da “Frank” keine Rechte darauf besitzt und es kommt zur Fehlermeldung. Benutzer “Frank” benötigt also mindestens “Autor / Author“ Rechte auf den Ordner:
Add-MailboxFolderPermission "webmaster:\Gelöschte Elemente" -User frank -AccessRights Author
Jetzt klappt auch das Löschen ohne Fehlermeldung. Ich bin raus aus dem Wald und ich verrate nicht wie lange es gedauert hat… 
Das Verhalten ist ja auch im Technet dokumentiert und ich hätte darauf deutlich schneller aufmerksam werden sollen, hätte ich vielleicht auch den ersten Teil der Fehlermeldung lesen sollen?
Hoch die Hände: Wochenende!
Hi Franky,
du schreibst „Das Element was “Frank” versucht im Kalender von “W” zu löschen, kann also nicht in den Ordner “Gelöschte Elemente” von “W” verschoben werden, da “Frank” keine Rechte darauf besitzt und es kommt zur Fehlermeldung. Benutzer “Frank” benötigt also mindestens “Autor / Author“ Rechte auf den Ordner“.
Leider funktioniert das bei mir/uns nicht. User A hat Zugriff auf den Kalender von User B und erhält beim Löschversuch eines Kalendereintrags im Kalender von User B die Meldung „Ein Clientvorgang ist fehlgeschlagen“.
Und was macht man, wenn „DelegateWastebasketStyle“ via GPO auf 4 gesetzt ist, die Mails aber weiterhin noch im eigenen Postfach gemüllt werden? Der entsprechende Eintrag im Policy Zweig der HKCU sollte doch eigentlich _alles_ Andere übertrumpfen.
Outlook Client sollte im Cache Modus laufen
Und was macht man, wenn der Registrywert von „DelegateWastebasketStyle“ auf 8 gesetzt ist, also zu löschenden Elemente im eigenen deleted Items-Ordner landen sollen? Das ist nämlich bei mir gerade der Fall. User bekommen den Wert 8 zugewiesen aber bekommen immer noch die Fehlermeldung. Ich kann ja nicht einfach allen das Recht einräumen auf den Ordner „Gelöschte Elemente“ zuzugreifen, wenn der Postfachinhaber das nicht möchte.
Hallo,
hat irgendjemand eine Idee, wie ich das Löschen hinbekomme, wenn wir nur OWA im Einsatz haben.
Die Mail landen immer noch im Anmelder- und nicht in freeigegbenen Postfach, egal was ich probiere …
Dazu habe ich leider keine Lösung, aber bin daran interessiert.
@Paul: Genau, das ist das „normale“ Verhalten bei diesem Registry Eintrag und macht das natürlich nicht einfacher … s. https://support.microsoft.com/de-de/help/2703723/email-remains-in-the-outbox-when-you-use-the-delegatesentitemsstyle-registry-value
Was in dem oben beschriebenen Fall auch geht, ist die Nachricht im freigegebenen Postfach mit SHIFT + DEL zu löschen, das umgeht die Anweisung noch irgendwohin geschrieben zu werden.
Nach meinen Tests funktioniert das nur, wenn man den Exchange-Cache-Modus eingeschaltet hat. Ist man im Online-Mode, landen die gelöschten Emails trotzdem in den eigenen Gelöschten Elementen.
Hi Frank,
Danke für diesen Beitrag. Bringt wirklich Licht ins Dunkel und verkürzt beim nächsten Mal die Fehlersuche (bei mir)
Gruß,
Ralf