Exchange-Funktionspostfach: Der Zugriffssteuerungseintrag für das Objekt kann nicht entfernt werden, da er nicht vorhanden ist

Ab und an müssen diese Berechtigungen allerdings auch wieder entzogen werden, zum Beispiel bei einem Abteilungs­wechsel oder wenn der Benutzer aus dem Unternehmen ausscheidet. Auch dies lässt sich über das Exchange Admin Center erledigen.

In einigen Fällen kommt es allerdings vor, dass man den Benutzer über die ECP entfernt und das Fenster der Admin-Konsole schießt, ohne dass ein Fehler auftritt. Wenn man die Eigenschaften des Funktions­postfaches jedoch wieder öffnet, dann steht der Benutzer mit allen seinen Berechtigungen dort nach wie vor drin.

Ein naheliegender weiterer Versuch, um den Benutzer zu entfernen, wäre nun, es über die Exchange-PowerShell zu versuchen:

Remove-MailboxPermission <Funktionspostfach> -user <username> -Accessrights FullAccess

Aber auch dieser Befehl funktionierte nicht, es kommt folgende Meldung hoch:

WARNUNG: Der Zugriffs­steuerungs­eintrag für das Objekt <Distinguished Name> kann nicht entfernt werden, da er nicht vorhanden ist.

Mit

Get-MailboxPermission <Funktionspostfach> -user <username>

ist zu sehen, dass der Benutzer inklusive Berechtigung aber da ist.

Im Web finden sich verschiedene Vorschläge, wie man dieses Problem lösen könnte. Diese reichen von der Empfehlung, die Datenbank, auf dem das Postfach liegt, zu reparieren, weil sie angeblich defekt sei, über das Verschieben der Mailbox auf eine andere Datenbank bis zum Ausführen des obigen PowerShell-Befehls mit der SID oder ObjectID. Mag sein, dass diese Tipps in vielen Fällen geholfen haben, nur leider bei meinem Problem nicht.

Am betreffenden Benutzer ist mir aufgefallen, dass es sich hier um ein verknüpftes Postfach handelte, welches Zugriff auf ein normales Benutzer- bzw. Freigabe­postfach hat. Soweit sollte das eigentlich kein Problem sein, bis jetzt hat offenbar alles funktioniert.

Auffällig war zudem, dass mit dem Befehl Add-MailboxPermission sowohl der verknüpfte als auch der Hauptbenutzer für FullAccess erneut eingetragen werden konnten.

Normalerweise sollte bei diesem Versuch folgender Fehler erscheinen, der darauf hinweist, dass der betreffende Zugriffs­steuerungseintrag bereits vorhanden ist:

Dieser erschien allerdings nicht, PowerShell hat anscheinend die Berechtigung gesetzt, allerdings ohne Auswirkungen auf das eigentliche Problem. Ein erneutes Löschen des Benutzers schlug mit der bekannten Meldung fehl.

Die Ursache des Problems bestand darin, dass das Konto anscheinend erst als normaler E-Mail-Benutzer im System angelegt, dann berechtigt und anschließend in ein verknüpftes Postfach konvertiert wurde.

Daher lag es nahe, die verknüpfte Mailbox wieder in eine normale umzuwandeln. Mit PowerShell kann lässt sich diese Aufgabe so erledigen:

Set-User -Identity <Benutzername> -LinkedMasterAccount $null

Nach kurzem Warten (ca. 5 Minuten) sollte der Benutzer dann per PowerShell oder GUI gelöscht werden können. Sollte er nur die Abteilung gewechselt haben, kann man den Account jetzt wieder auf verknüpft zurücksetzen:

set-User -Identity <Benutzername> -LinkedMasterAccount <domäne\benutzername>
-LinkedDomainController <Name des Domänencontrollers>