Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 19%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECS%3C/text%3E%3C/svg%3E)
Exchange Server Subscription Edition (Build 15.02.2562.045), ein einzelner Mailbox-/CAS-Server (On-Premises, keine Hybrid-Konfiguration, kein Exchange Online).
Windows Server 2019, zwei Active-Directory-Domänencontroller (einer davon PDC-Emulator).
Die Exchange-Organisation wurde ursprünglich im Juni 2020 installiert/vorbereitet; der Server ist seitdem durchgehend produktiv im Einsatz.
Keine Kind-Domäne.
Zwei voneinander unabhängige, wiederkehrende Probleme, beide zurückgeführt auf Active-Directory-Objekte, denen ein von Exchange benötigtes Attribut fehlt. Beide Objektgruppen wurden während der ursprünglichen Installation 2020 angelegt und seitdem nicht mehr verändert (whenChanged = whenCreated, kein lastKnownParent, also keine gelöschten/wiederhergestellten Objekte).
msExchRecipientTypeDetailsZwei Systempostfächer unter CN=Microsoft Exchange System Objects:
SystemMailbox{58879a96-d823-4a8a-8eb9-09aa320950d5} (erstellt 30.06.2020, homeMDB verweist auf eine gültige, eingehängte Datenbank)
SystemMailbox{7539c2c2-0323-4c67-917c-9b3572baf2fd} (erstellt 30.06.2020, homeMDB verweist auf eine gültige, eingehängte Datenbank)
Beide haben objectClass: msExchSystemMailbox, ein gültiges homeMDB und eine gültige msExchMailboxGuid — aber msExchRecipientTypeDetails und msExchRecipientDisplayType sind nicht gesetzt (NULL), im Gegensatz zu einem normalen Postfach (z. B. zeigt ein reguläres UserMailbox-Objekt msExchRecipientTypeDetails = 1).
Auswirkung:
Get-Mailbox -Identity "SystemMailbox{...}" schlägt fehl mit „Objekt ... wurde nicht auf '<DC>' gefunden" — reproduziert auf beiden Domänencontrollern.
Get-Mailbox -Arbitration liefert gar keine Ausgabe (kein Fehler, leeres Ergebnis), obwohl die Objekte existieren.
Enable-Mailbox -Identity "SystemMailbox{...}" -Arbitration (der laut Microsoft Learn „Recreate missing arbitration mailboxes" dokumentierte, unterstützte Reparaturweg) scheitert mit demselben „nicht gefunden"-Fehler — kann das Objekt also nicht einmal finden, um daran etwas zu ändern.
Wiederkehrendes Ereignis im Windows-Anwendungsprotokoll, Ereignis-ID 5000 (Quelle: MSExchange Management Application, Kategorie AdminAuditLog), ausgelöst durch interne Hintergrunddienste im SYSTEM-Kontext (Microsoft.Exchange.Mitigation.Service, Microsoft.Exchange.Management.Flighting.Service), etwa alle 30–60 Minuten:
Ausnahme während 'AdminLogProvisioningHandler.Validate': Microsoft.Exchange.Data.Storage.ObjectNotFoundException: Das Discoverypostfach ... wurde nicht gefunden ... bei Microsoft.Exchange.Data.Storage.Infoworker.MailboxSearch.MailboxDataProvider.GetDiscoveryMailbox(IRecipientSession session) bei Microsoft.Exchange.Management.SystemConfigurationTasks.AdminAuditLogHelper.CheckArbitrationMailboxStatus(...)
Der interaktive Zugriff auf Postfächer (z. B. Test-MapiConnectivity gegen ein anderes, korrekt provisioniertes Discovery-Postfach) funktioniert einwandfrei — der Fehler betrifft speziell die Empfänger-Lookup-Schicht, die von AdminAuditLogHelper.CheckArbitrationMailboxStatus genutzt wird, und speziell diese beiden Objekte.
homeMDBZwei der 37 integrierten Managed-Availability-Konten HealthMailbox* unter CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects — alle 37 wurden in einem einzigen Zeitfenster zwischen dem 23.06. und 01.07.2020 angelegt, darunter auch diese beiden:
HealthMailbox8a525736a3bb45248b1930b7ef45b42e (erstellt 29.06.2020, 16:57:12 Uhr)
HealthMailboxe16fc72b39ac49d8820951640f4c5f1d (erstellt 29.06.2020, 16:57:34 Uhr)
Auswirkung: Wiederkehrende Ereignisse „MSExchange ADAccess", Ereignis-ID 2160/2161 (Validation, Warnung), Quellprozess MSExchangeHMWorker.exe (ExHMWorker), etwa alle 30 Minuten:
Recipient object CN=HealthMailbox... read from
<DC>failed validation and will be excluded from the result set. Property: 'Database' — 'Database' ist für 'UserMailbox' verbindlich.
Also dasselbe Grundmuster wie bei Problem 1: Ein für den jeweiligen Empfängertyp verbindliches Attribut ist nicht gesetzt, bei einem Objekt, das ansonsten strukturell intakt wirkt und seit 2020 unverändert existiert.
AD-Replikation/-Gesundheit: dcdiag /test:Replications /test:Advertising /test:Services auf beiden Domänencontrollern — alle Tests bestanden, keine Fehler.
Objekt-Duplikate oder Papierkorb-Inkonsistenz: Beide Arbitration-Postfach-Objekte liefern über Get-ADObject -Server <DC> auf beiden DCs identische ObjectGUID und nahezu identisches whenChanged. lastKnownParent ist bei beiden leer — schließt eine Wiederherstellung aus dem AD-Papierkorb als Ursache aus.
Berechtigungen: Get-MailboxPermission beim (unabhängigen, funktionierenden) Discovery-Postfach zeigt eine identische ACL-Struktur wie bei einem normalen Postfach — für dieses Objekt also kein Berechtigungsproblem; bei den Arbitration-Postfächern nicht prüfbar, da Get-Mailbox sie gar nicht erst auflösen kann.
Kein Zusammenhang mit einem aktuellen Vorfall: Diese Objekte sind rund 6 Jahre älter als zwei unabhängige, bereits behobene Vorfälle auf diesem Server im Juni/Juli 2026 (eine versehentliche AD-Objektlöschung im Rahmen eines unabhängigen Cleanups sowie ein OWA-Ausfall durch eine CSP/CNG-Zertifikatsinkompatibilität). Keiner der beiden Vorfälle hat diese Objekte berührt.
Was ist der von Microsoft unterstützte Weg, um msExchRecipientTypeDetails (und msExchRecipientDisplayType) bei einem bereits existierenden Arbitration-Postfach-AD-Objekt zu setzen, wenn selbst Enable-Mailbox -Arbitration das Objekt nicht finden kann (identischer ObjectNotFound-Fehler wie bei Get-Mailbox)? Gibt es einen alternativen Cmdlet-Ansatz (z. B. mit anderem Scope), oder ist dafür setup /PrepareAD nötig — und falls ja: Ist es sicher, das gegen eine Organisation auszuführen, in der diese beiden Objekte bereits mit echten Maildaten existieren (überspringt/repariert das Tool sie, statt Duplikate anzulegen)?
Dieselbe Frage für die beiden HealthMailbox-Objekte ohne homeMDB — gibt es einen unterstützten Cmdlet-basierten Reparaturweg, legt Managed Availability solche Objekte im Lauf der Zeit automatisch neu an, oder ist auch hier setup /PrepareAD die Antwort?
Da beide Objektgruppen seit der ursprünglichen Installation/dem ursprünglichen PrepareAD-Lauf 2020 in diesem unvollständigen Zustand sind: Ist es plausibel, dass der ursprüngliche setup /PrepareAD-Lauf 2020 unterbrochen wurde oder teilweise fehlschlug? Und könnte ein erneuter Lauf von setup /PrepareAD /IAcceptExchangeServerLicenseTerms mit den aktuellen Exchange-SE-Installationsmedien die fehlenden Attribute bei den bestehenden Objekten sicher nachtragen/reparieren, ohne die übrige (gesunde, produktive) Organisation zu beeinträchtigen?
Aktuell keine feststellbar — Mailfluss, OWA, Kalenderfunktion und (soweit erkennbar) Genehmigungs-/Journaling-Workflows über die Arbitration-Postfächer funktionieren normal. Das einzige Symptom ist wiederkehrendes, kosmetisches Log-Rauschen im Anwendungsprotokoll (Ereignis 5000 sowie 2160/2161) etwa alle 30–60 Minuten. Nicht dringend, aber wir würden gerne einen unterstützten Reparaturweg finden, statt das dauerhaft so zu belassen oder eigenmächtig per Set-ADObject/ADSIEdit einzugreifen — wovon die Microsoft-Dokumentation zu einem verwandten Thema (fehlendes Discovery-System-Postfach) ausdrücklich abrät.
Eine leistungsstarke E-Mail-, Kalender- und Kollaborationsplattform, entwickelt von Microsoft für Unternehmenskommunikation und Datenmanagement.Verschiedene Themen, die nicht in bestimmte Kategorien passen.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(51.2, 90%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAL%3C/text%3E%3C/svg%3E)
Diese Antwort wurde automatisch übersetzt. Daher kann sie grammatikalische Fehler oder ungewöhnliche Ausdrücke enthalten.
Hallo,
Basierend auf Ihren bisherigen Recherchen sehe ich keine von Microsoft dokumentierte oder unterstützte Methode, um Attribute wie msExchRecipientTypeDetails, msExchRecipientDisplayType oder homeMDB in bestehenden Exchange-Systempostfachobjekten manuell neu zu befüllen.
Die empfohlene Vorgehensweise lautet generell:
In Ihrem Fall können die Standard-Cmdlets (Get-Mailbox, Get-Mailbox -Arbitration und Enable-Mailbox -Arbitration) die betroffenen Objekte jedoch nicht auflösen. Daher gibt es kein dokumentiertes alternatives Cmdlet, das die Empfängersuche umgeht, um diese Objekte zu reparieren.
Bezüglich Setup.exe /PrepareAD: Die erneute Ausführung mit demselben oder einem neueren unterstützten Exchange SE-Build ist im Allgemeinen unbedenklich. Die erneute Ausführung von /PrepareAD wird auch bei Aktualisierungen von Exchange oder Active Directory unterstützt. Ich konnte jedoch keine Microsoft-Dokumentation finden, die bestätigt, dass dadurch vorhandene Vermittlungs- oder HealthMailbox-Objekte mit fehlenden Empfängerattributen repariert oder diese Attribute ohne Neuerstellung der Objekte nachträglich ergänzt werden. Daher kann ich diese Vorgehensweise nicht als garantierte Lösung für dieses spezifische Problem empfehlen.
Ebenso ist mir kein dokumentierter Mechanismus bekannt, mit dem Managed Availability vorhandene HealthMailbox-Objekte automatisch repariert, die zwar noch vorhanden sind, aber obligatorische Attribute wie homeMDB vermissen. Überwachungspostfächer können unter bestimmten Umständen neu erstellt werden, es gibt jedoch keine Dokumentation, die darauf hinweist, dass teilweise gefüllte AD-Objekte direkt repariert werden.
Da:
und es keine dokumentierte, unterstützte Reparaturprozedur für dieses Szenario gibt,
wäre der nächste sinnvolle Schritt, ein Support-Ticket bei Microsoft zu eröffnen. Der Exchange-Support kann Exchange-Diagnosedaten und Active Directory-Daten erfassen, um festzustellen, ob diese Objekte sicher repariert werden können, ob das Setup erneut ausgeführt werden muss oder ob die betroffenen Systempostfächer mithilfe einer intern unterstützten Prozedur neu erstellt werden müssen.
Basierend auf Ihren Angaben scheint es sich um ein produktspezifisches Reparaturszenario zu handeln, das nicht durch öffentlich dokumentierte Exchange-Administrationsschritte behoben werden kann.