Sometimes you can't see the wood for the trees, in this case the following problem has led me onto the slippery slope.
A user reports that he can create items in a shared calendar of a colleague, but can no longer delete the entries. When trying to delete a calendar entry, Outlook only displays the following error message:
The element cannot be moved. It has either already been moved or deleted, or access has been denied.
Sounds pretty clear: Access denied. So check the rights to the colleague's calendar once, it's quick with the shell (as an example):
Get-MailboxFolderPermission frank:\calendar
The screenshot serves as an example, but at first I looked a little puzzled: An "editor / editor" has the right to delete elements, doesn't he?
This is where my tree/forest problem started... The user obviously has the rights "Delete all items" for the calendar, but Outlook still shows an error message that somehow contains something like "Access denied".
After a certain, somewhat longer period of time, I then noticed that the user has connected an additional mailbox to which he has full access. Something like this:
Here, of course, the deletion works perfectly, without error message, only in the additional calendar from another mailbox the error message is displayed and cannot be deleted.
It takes some time before I finally find my way out of the forest...
Cause in this constellation: In the registry (HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Options\General) of the user, the DWORD "DelegateWastebasketStyle" has been changed to the value "4", which causes items that are deleted in shared mailboxes to be saved in the mailbox owner's folder.
The standard is therefore as follows when a user deletes an item in a shared mailbox:
User "Frank" accesses the shared mailbox of "A" and deletes a mail in the inbox. The mail is then moved to Frank's "Deleted items" folder.
The registry key mentioned above now has the following effect:
User "Frank" accesses the shared mailbox of "A" and deletes a mail in the inbox. The mail is then moved to the "Deleted items" folder of mailbox owner A.
The registry entry "DelegateWastebasketStyle" now also applies to the additionally shared calendar. The item in colleague W's calendar is moved to W's "Deleted items" folder when the user deletes it:
In this case, however, user "Frank" has no rights to the "Deleted items" folder of W, but only editor rights to the calendar:
The item that "Frank" is trying to delete in the calendar of "W" cannot be moved to the "Deleted items" folder of "W" because "Frank" has no rights to it and an error message appears. User "Frank" therefore needs at least "Author" rights to the folder:
Add-MailboxFolderPermission "webmaster:\Deleted items" -User frank -AccessRights Author
Now deleting also works without an error message. I'm out of the woods and I won't tell you how long it took...
The behavior is also documented in Technet and I should have become aware of it much sooner, should I perhaps have read the first part of the error message?
Hands up: Weekend!
Hey franky,
Danke franky!
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