7
New-Inboxrule läuft in Fehler
Moin,
ich möchte gerne die DMARC-Reports, die an unser freigegebenes Postfach administrator@domain.tld geschickt werden, in einen dafür vorgesehenen Ordner verschieben. Dazu setze ich folgenden PS-Befehl ab:
Aber das läuft in folgenden Fehler:
Nun habe ich Tante Google befragt und die meinte, es handle sich um eine defekte DB. Die Prüfung der DB ergab aber, dass kein Defekt vorliegt.
Der Versuch, die gleiche Regel in einem anderen freigegebenen PF anzulegen, war erfolgreich. Da dieses in einer anderen DB liegt, habe ich das Administrator-PF in diese DB verschoben. Das ging ohne Fehler. Der erneute Versuch, die Regel zu erstellen, brachte den gleichen Fehler. Da aber der Befehl prinzipiell bei PFs, die in dieser DB liegen, funktioniert, schließe ich einen Fehler in der DB aus. Außerdem kann ich ohne Probleme eine Regel anlegen, die z. B. die Mails sofort löscht. Auch das spricht imho gegen einen Fehler in der DB.
Gibt es noch eine andere Ursache für diesen Fehler? Und wie behebe ich den?
Umgebung:
Exchange 2019 on prem CU13
<edit>Der Unterordner exisitiert. Ich habe sowohl Inbox als auch Posteingang probiert.</edit>
Liebe Grüße
Erik
ich möchte gerne die DMARC-Reports, die an unser freigegebenes Postfach administrator@domain.tld geschickt werden, in einen dafür vorgesehenen Ordner verschieben. Dazu setze ich folgenden PS-Befehl ab:
New-InboxRule -name dmarc -mailbox administrator@domain.tld -HeaderContainsWords "DMARC" -MoveToFolder "administrator@domain.tld:\Inbox\DMARC" Aber das läuft in folgenden Fehler:
Das Postfach /o=domain/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Recipients/cn=ef22d2399a574cf69ab58e9a17 kann nicht geöffnet werden.
+ CategoryInfo : NotSpecified: (:) [New-InboxRule], ConnectionFailedTransientException
+ FullyQualifiedErrorId : [Server=SVREXCHANGE,RequestId=ed1b7e90-68b6-408a-93a3-4f26821ec405,TimeStamp=12.08.2024
09:33:06] [FailureCategory=Cmdlet-ConnectionFailedTransientException] 854EBFBB,Microsoft.Exchange.Management.Recip
ientTasks.NewInboxRule
+ PSComputerName : exchange.domain.tldNun habe ich Tante Google befragt und die meinte, es handle sich um eine defekte DB. Die Prüfung der DB ergab aber, dass kein Defekt vorliegt.
Der Versuch, die gleiche Regel in einem anderen freigegebenen PF anzulegen, war erfolgreich. Da dieses in einer anderen DB liegt, habe ich das Administrator-PF in diese DB verschoben. Das ging ohne Fehler. Der erneute Versuch, die Regel zu erstellen, brachte den gleichen Fehler. Da aber der Befehl prinzipiell bei PFs, die in dieser DB liegen, funktioniert, schließe ich einen Fehler in der DB aus. Außerdem kann ich ohne Probleme eine Regel anlegen, die z. B. die Mails sofort löscht. Auch das spricht imho gegen einen Fehler in der DB.
Gibt es noch eine andere Ursache für diesen Fehler? Und wie behebe ich den?
Umgebung:
Exchange 2019 on prem CU13
<edit>Der Unterordner exisitiert. Ich habe sowohl Inbox als auch Posteingang probiert.</edit>
Liebe Grüße
Erik
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 51912731037
Url: https://administrator.de/contentid/51912731037
Ausgedruckt am: 09.11.2024 um 01:11 Uhr
7 Kommentare
Neuester Kommentar
Schon mal testweise versucht die Regel von Hand über OWA anzulegen?
Gruß
Gruß
Zitat von @14135584197:
Schon mal testweise versucht die Regel von Hand über OWA anzulegen?
Gruß
Schon mal testweise versucht die Regel von Hand über OWA anzulegen?
Gruß
Nö, aber in der OWA kann ich das PF noch nicht einmal öffnen:
Diese Informationen können wir momentan nicht abrufen. Bitte versuchen Sie es später noch mal.
X-ClientId: E2C73195FA084758BC46C1BBB827C04A
request-id 66bb08f5-ee5e-4d6f-96e3-21322aaec7bd
X-OWA-Error Microsoft.Exchange.Services.Core.Types.ErrorNonExistentMailboxExceptionMit anderen Freigaben geht es problemlos. Ich habe ja mittlerweile den starken Verdacht, dass es an dem administrator@ liegt. Und ich sag noch zu Jefe: Keine gute Idee. Lass uns was anderes nehmen.
Liebe Grüße
Erikl
Nö, aber in der OWA kann ich das PF noch nicht einmal öffnen:
Das direkte Öffnen über den Login geht nur wenn das keine shared Mailbox ist, für ne SharedMailbox muss man den AD Account ja erst mal temp. aktivieren. Ich habe ja mittlerweile den starken Verdacht, dass es an dem administrator@ liegt. Und ich sag noch zu Jefe: Keine gute Idee. Lass uns was anderes nehmen. face-wink
Ich hoffe ja nicht das das ein umgewandeltes Postfach "des" "Administrator" der Domain ist ...😂Zitat von @14135584197:
Nö, aber in der OWA kann ich das PF noch nicht einmal öffnen:
Das direkte Öffnen über den Login geht nur wenn das keine shared Mailbox ist, für ne SharedMailbox muss man den AD Account ja erst mal temp. aktivieren.Ich weiß schon, wie man eine shared mailbox in der OWA öffnet.
Mit den anderen geht es problemlos. Die Meldung kommt nur bei diesem PF. Ich habe ja mittlerweile den starken Verdacht, dass es an dem administrator@ liegt. Und ich sag noch zu Jefe: Keine gute Idee. Lass uns was anderes nehmen. face-wink
Ich hoffe ja nicht das das ein umgewandeltes Postfach "des" "Administrator" der Domain ist ...😂Nein, es ist ein extra angelegtes freigegebenes Postfach. Aber das war auch nicht einfach. Ich musste rumtricksen, damit das überhaupt geht. Genau erinnere ich mich nicht mehr. Mein Chef wollte das unbedingt so.
So, nun habe ich es geschafft dank eines entscheidenden Hinweises in einer guten Anleitung. Der Hinweis fehlt in allen anderen. In der Anleitung geht es um das massenhafte Setzen einer Regel, um Mails in den Spam-Ordner zu verschieben. Der entscheidende Hinweis ist:
Nachdem ich meinem Domain-Admin-User dieses Recht verpasst habe, geht es. Mann, wie doof ist das denn? Zumal ich schon den Verdacht hatte, dass es daran liegt und nachgeschaut habe, welche Rechte der User hat. Da stand "FullAccess". Aber die sind wohl nur implizit.
$mailboxes = get-mailbox -resultsize unlimited | add-mailboxpermission -user <Account> -accessrights fullaccessNachdem ich meinem Domain-Admin-User dieses Recht verpasst habe, geht es. Mann, wie doof ist das denn? Zumal ich schon den Verdacht hatte, dass es daran liegt und nachgeschaut habe, welche Rechte der User hat. Da stand "FullAccess". Aber die sind wohl nur implizit.
Mann, wie doof ist das denn?
Joa, genau Domain-Admins für die Administration von Mailboxen hernehmen, das ist echt doof ... 🤔
1
Moin,
Wieso? Gut, es lässt sich sicherlich trefflich darüber streiten, ob der Exchange Server Tier 0 oder 1 ist. IMHO gehört er zur Netzinfrastruktur. Außerdem wird direkt auf die AD-Konten geschrieben und ihre Attribute manipuliert bis dahin, dass zum Betrieb des Exchange Änderungen am LDAP-Schema notwendig sind. Also Tier 0.
Liebe Grüße
Erik
Zitat von @14135584197:
Mann, wie doof ist das denn?
Joa, genau Domain-Admins für die Administration von Mailboxen hernehmen, das ist echt doof ... 🤔Wieso? Gut, es lässt sich sicherlich trefflich darüber streiten, ob der Exchange Server Tier 0 oder 1 ist. IMHO gehört er zur Netzinfrastruktur. Außerdem wird direkt auf die AD-Konten geschrieben und ihre Attribute manipuliert bis dahin, dass zum Betrieb des Exchange Änderungen am LDAP-Schema notwendig sind. Also Tier 0.
Liebe Grüße
Erik
